Chris Kaynor writes:
> On Thu, Jul 21, 2016 at 4:54 PM, Ben Bacarisse wrote:
>
>> Steven D'Aprano writes:
>>
>> > Or you might be using a language like Javascript, which intentionally has
>> > only floats for numbers. That's okay, you can still perform exact integer
>> > arithmetic, so long as
On Thu, Jul 21, 2016 at 4:54 PM, Ben Bacarisse wrote:
> Steven D'Aprano writes:
>
> > Or you might be using a language like Javascript, which intentionally has
> > only floats for numbers. That's okay, you can still perform exact integer
> > arithmetic, so long as you stay within the bounds of
Steven D'Aprano writes:
> Or you might be using a language like Javascript, which intentionally has
> only floats for numbers. That's okay, you can still perform exact integer
> arithmetic, so long as you stay within the bounds of ±2**16.
Small point: it's 2**52.
--
Ben.
--
https://mail.pyth
On Thu, 21 Jul 2016 11:14 pm, Rustom Mody wrote:
> On Thursday, July 21, 2016 at 12:04:35 PM UTC+5:30, Steven D'Aprano wrote:
>> On Thursday 21 July 2016 15:28, Rustom Mody wrote:
>> > BTW APL whose main domain of application is scientific chooses to
>> > enshrine this —equality is ε-neighborhood
On Thursday, July 21, 2016 at 12:04:35 PM UTC+5:30, Steven D'Aprano wrote:
> On Thursday 21 July 2016 15:28, Rustom Mody wrote:
> > BTW APL whose main domain of application is scientific chooses to enshrine
> > this —equality is ε-neighborhood checking not exact equality checking — into
> > its bui
Chris Angelico :
> On Thu, Jul 21, 2016 at 5:52 PM, Marko Rauhamaa wrote:
>> A couple of related anecdotes involving integer errors.
>>
>> 1. I worked on a (video) product that had to execute a piece of code
>>every 7 µs or so. A key requirement was that the beat must not drift
>>far apar
On Thu, Jul 21, 2016 at 5:52 PM, Marko Rauhamaa wrote:
> A couple of related anecdotes involving integer errors.
>
> 1. I worked on a (video) product that had to execute a piece of code
>every 7 µs or so. A key requirement was that the beat must not drift
>far apart from the ideal over tim
Rustom Mody :
> The field of numerical analysis came into existence only because this
> fact multiplied by the fact that computers do their (inaccurate ≠
> inexact) computations billions of times faster than we do makes
> significance a very significant problem!
A couple of related anecdotes invol
On Thursday 21 July 2016 15:28, Rustom Mody wrote:
> On Wednesday, July 20, 2016 at 11:13:05 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tuesday 19 July 2016 14:58, Rustom Mody wrote:
>>
>> > So I again ask: You say «"Never compare floats for equality" is a
>> > pernicious myth»
>>
>> It is the wo
On Thursday, July 21, 2016 at 11:05:28 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Jul 21, 2016 at 3:28 PM, Rustom Mody wrote:
> > ε is spelt ⎕ct (Comparison Tolerance)
> > And of course == is spelt =
>
> spelt is spelled spelled. Unless, of course, you mean the wheat variety.
Love it!
Though n
On Wednesday, July 20, 2016 at 8:29:25 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
>
> > On Wed, Jul 20, 2016 at 11:54 PM, Marko Rauhamaa wrote:
> >> 2. Floating-point numbers are *imperfect approximations* of real
> >> numbers. Even when real numbers are derived exactly,
> >>
On Thu, Jul 21, 2016 at 3:28 PM, Rustom Mody wrote:
> ε is spelt ⎕ct (Comparison Tolerance)
> And of course == is spelt =
spelt is spelled spelled. Unless, of course, you mean the wheat variety.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday, July 20, 2016 at 11:13:05 AM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 19 July 2016 14:58, Rustom Mody wrote:
>
> > So I again ask: You say «"Never compare floats for equality" is a pernicious
> > myth»
>
> It is the word *never* which makes it superstition. If people said "Take
On Wed, 20 Jul 2016 11:24 pm, alister wrote:
> One of my biggest questions since the Brexit vote is can we g back to
> using imperial weights & measures (please).
I suppose you might as well -- there's no more empire, no more jobs or
houses, and once the financial traders leave London there'll be
Random832 wrote:
Well, your amp hours will be shittier with a lower voltage.
Define "shittier". An incandescent flashlight (which consumes less power
at lower voltage) will last longer, but won't be as bright. If it's
still acceptably bright, that's not worse.
I think the point is that the ce
Chris Angelico :
> On Wed, Jul 20, 2016 at 11:54 PM, Marko Rauhamaa wrote:
>> 2. Floating-point numbers are *imperfect approximations* of real
>> numbers. Even when real numbers are derived exactly,
>> floating-point operations may introduce "lossy compression
>> artifacts" that have
On Wed, Jul 20, 2016 at 11:54 PM, Marko Rauhamaa wrote:
> 2. Floating-point numbers are *imperfect approximations* of real
> numbers. Even when real numbers are derived exactly, floating-point
> operations may introduce "lossy compression artifacts" that have to
> be compensated for i
On Wed, Jul 20, 2016, at 03:16, Marko Rauhamaa wrote:
> Random832 :
> > Typically their capacity is labeled in amp-hours.
>
> Did you really see that labeled on the (nonrechargeable AA) battery?
Sorry, I must have imagined that. Anyway, my point was that the reality
is too complicated to easily a
Steven D'Aprano :
> I am not a good computer scientist. But Bruce Dawson *is* a good
> computer scientist:
>
> https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-f
> loatsso-test-them-all/
>
> Quote:
>
> Conventional wisdom says that you should never compare two floats
>
On Wed, 20 Jul 2016 02:09:58 +0300, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> Ah, the machinations that users of imperial units have to endure.
>
> Europeans often mistakenly believe that Americans haven't yet adopted
> the SI units. They have:
>
> - the length of a ski is measured in centimete
On Wed, 20 Jul 2016 05:09 pm, Antoon Pardon wrote:
> Op 20-07-16 om 07:42 schreef Steven D'Aprano:
>> Floating point maths is hard, thinking carefully about what you are doing
>> and whether it is appropriate to use == or a fuzzy almost-equal
>> comparison, or if equality is the right way at all.
Antoon Pardon :
> But why perforem integer arithmetics in floats,
Conceptual and practical simplificity.
> isn't that a waste of time too?
Probably not, especially compared with the overhead of boxing.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Random832 :
> On Tue, Jul 19, 2016, at 18:17, Marko Rauhamaa wrote:
>> I'd love it if batteries were priced per joule, or even per
>> kilowatt-hour.
>
> Typically their capacity is labeled in amp-hours.
Did you really see that labeled on the (nonrechargeable AA) battery?
> You have to know your
Op 20-07-16 om 07:42 schreef Steven D'Aprano:
> Floating point maths is hard, thinking carefully about what you are doing and
> whether it is appropriate to use == or a fuzzy almost-equal comparison, or if
> equality is the right way at all.
>
> "But thinking is hard, can't you just tell me the a
On Wed, Jul 20, 2016 at 3:42 PM, Steven D'Aprano
wrote:
> Arithmetic on integer-values (e.g. 1.0) is always exact, up to a limit of
> either 2**53 or approximately 1e53, I forget which. (That's why most
> Javascript
> programmers fail to notice that they don't have an integer type.)
It's 2**53,
On Tuesday 19 July 2016 14:58, Rustom Mody wrote:
> So I again ask: You say «"Never compare floats for equality" is a pernicious
> myth»
It is the word *never* which makes it superstition. If people said "Take care
with using == for floats, its often not what you want" I would have no argument
On Tuesday 19 July 2016 18:27:10 Ian Kelly wrote:
> On Tue, Jul 19, 2016 at 2:35 PM, Gene Heskett
wrote:
> > And I am not familiar with this foot-poundals per second that you
> > question about, but just from the wording I'd say it is a fifty
> > dollar way to say horsepower.
>
> https://en.wiki
On Tue, Jul 19, 2016, at 18:17, Marko Rauhamaa wrote:
> I'd love it if batteries were priced per joule, or even per
> kilowatt-hour.
Typically their capacity is labeled in amp-hours. You have to know your
devices to know if the voltage difference between different battery
types (Which ranges from
On Wednesday, July 20, 2016 at 10:28:04 AM UTC+12, Ian wrote:
> Ah, the machinations that users of imperial units have to endure.
Deep in some people’s hearts, the Mars Climate Orbiter still sails...
--
https://mail.python.org/mailman/listinfo/python-list
Gregory Ewing :
> Physicists realised that nearly a century ago, and no
> longer use the idea of a velocity-dependent mass.
Roche states that about 60% of modern authors just use rest mass and
avoid relativistic mass.
https://en.wikipedia.org/wiki/Mass_in_special_relativity#Controversy>
Ian Kelly :
> Ah, the machinations that users of imperial units have to endure.
Europeans often mistakenly believe that Americans haven't yet adopted
the SI units. They have:
- the length of a ski is measured in centimeters
- the width of film and the diameter of a gun barrel are measured in
Gene Heskett wrote:
The theory of relativity says that the faster you
are going, the more massive you become.
It doesn't, really. The equations only seem to say that
if you insist on keeping the Newtonian definitions of
momentum and kinetic energy in the context of relativity,
which is a silly
On Tue, Jul 19, 2016 at 2:35 PM, Gene Heskett wrote:
> And I am not familiar with this foot-poundals per second that you
> question about, but just from the wording I'd say it is a fifty dollar
> way to say horsepower.
https://en.wikipedia.org/wiki/Foot-poundal
> Which is defined in the area of
Gene Heskett :
> On Tuesday 19 July 2016 13:46:37 Lawrence D’Oliveiro wrote:
>> What is this “watt” of which you speak?
>
> A unit of electrical power, simplified to 1 volt at 1 amp = 1 watt
> when that currant is passed thru a 1 ohm resistor. But since the
> majority of radio frequency stuff is d
On Tuesday 19 July 2016 13:46:37 Lawrence D’Oliveiro wrote:
> On Wednesday, July 20, 2016 at 12:07:25 AM UTC+12, Gene Heskett wrote:
> > This klystron amplifier, a new one of which was north of $125,000 in
> > the 1970's when I learned about them, is a long tube, around 5 feet
> > long with altern
On Wednesday, July 20, 2016 at 12:07:25 AM UTC+12, Gene Heskett wrote:
> This klystron amplifier, a new one of which was north of $125,000 in the
> 1970's when I learned about them, is a long tube, around 5 feet long
> with alternating sections of copper tubeing and ceramic insulators
> separati
On Monday 18 July 2016 23:16:32 Steven D'Aprano wrote:
> On Tue, 19 Jul 2016 10:36 am, Rustom Mody wrote:
> > I recollect — school physics textbook so sorry no link —
> > that in the Newton gravitation law
> > f = -GMm/r²
> >
> > there was a discussion about the exponent of r ie 2
> > And that to
On Tue, Jul 19, 2016 at 2:58 PM, Rustom Mody wrote:
> Analogy:
> Mutable default parameters are a source of problem and confusion.
>
> No A says. One can use them to simulate statics
>
> No B says No problem as long as you make sure there is no mutation to the
> mutable, either inside or outside
On Tue, Jul 19, 2016 at 1:42 PM, Steven D'Aprano wrote:
>> And then you get these sorts of functions:
>>
>> EPSILON = 0.01 # Adjust to control numeric accuracy
>> def is_equal(f1, f2, epsilon=EPSILON):
>> if abs(f1) > abs(f2):
>> f1, f2 = f2, f1
>> return abs(f2-f1) < f1*epsilo
On Tuesday, July 19, 2016 at 9:12:57 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote:
>
> > On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote:
> >> Python programmers (among others) frequently run into issues with
> >> surprising results in floating-poi
On Mon, 18 Jul 2016 08:15 pm, Chris Angelico wrote:
> On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote:
>> Python programmers (among others) frequently run into issues with
>> surprising results in floating-point arithmetics. For better or worse,
>> Scheme has tried to abstract the concept.
On Tuesday, July 19, 2016 at 8:46:44 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 19 Jul 2016 10:36 am, Rustom Mody wrote:
>
> > I recollect — school physics textbook so sorry no link —
> > that in the Newton gravitation law
> > f = -GMm/r²
> >
> > there was a discussion about the exponent of r
On Mon, 18 Jul 2016 11:25 pm, Random832 wrote:
> On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
>> What is “those”? The measurement is imprecise, the observations are
>> inexact.
>>
>> It makes no sense to say that a number is inexact. Exactness is not a
>> property of a number.
>
> There's n
On Tue, 19 Jul 2016 10:36 am, Rustom Mody wrote:
> I recollect — school physics textbook so sorry no link —
> that in the Newton gravitation law
> f = -GMm/r²
>
> there was a discussion about the exponent of r ie 2
> And that to some 6 decimal places it had been verified that it was
> actually 2
On Tue, 19 Jul 2016 01:25 am, Ian Kelly wrote:
> On Mon, Jul 18, 2016 at 3:29 AM, Steven D'Aprano
> wrote:
>> On Monday 18 July 2016 14:16, Rustom Mody wrote:
>>> In short one could think of inexact and exact — in scheme's intended
>>> semantics — as better called scientific (or science-ic) and m
On Tuesday, July 19, 2016 at 12:28:36 AM UTC+5:30, Marko Rauhamaa wrote:
> Ian Kelly :
>
> > Okay, so how is that wavelength defined?
> >
> > If you needed to mark a meter stick, and all you had was the
> > definition of c and the second, how would you do it without measuring
> > anything?
>
> I
Random832 writes:
> On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
> > What is “those”? The measurement is imprecise, the observations are
> > inexact.
> >
> > It makes no sense to say that a number is inexact. Exactness is not
> > a property of a number.
>
> There's no reason it shouldn't be
Ian Kelly :
> Okay, so how is that wavelength defined?
>
> If you needed to mark a meter stick, and all you had was the
> definition of c and the second, how would you do it without measuring
> anything?
I wouldn't be measuring a meter stick. To measure, say, the height of a
desk, I would bring i
On Mon, Jul 18, 2016 at 9:55 AM, Marko Rauhamaa wrote:
> Marko Rauhamaa :
>
>> Ian Kelly :
>>> Off-topic, c being a fundamental constant is actually in the latter
>>> category. Its *exact* value is 299792458 m/s.
>>>
>>> The length of the meter, on the other hand, is defined as the distance
>>> tr
Marko Rauhamaa :
> Ian Kelly :
>> Off-topic, c being a fundamental constant is actually in the latter
>> category. Its *exact* value is 299792458 m/s.
>>
>> The length of the meter, on the other hand, is defined as the distance
>> traveled by light in a vacuum in 1/299792458 seconds and is subject
Ian Kelly :
> Off-topic, c being a fundamental constant is actually in the latter
> category. Its *exact* value is 299792458 m/s.
>
> The length of the meter, on the other hand, is defined as the distance
> traveled by light in a vacuum in 1/299792458 seconds and is subject to
> the precision of m
On Mon, Jul 18, 2016 at 3:29 AM, Steven D'Aprano
wrote:
> On Monday 18 July 2016 14:16, Rustom Mody wrote:
>> In short one could think of inexact and exact — in scheme's intended
>> semantics — as better called scientific (or science-ic) and mathematic
>> numbers.
>
> I don't think so. "Science" u
On Mon, Jul 18, 2016, at 01:37, Rustom Mody wrote:
> The INTENTION is that in addition to capturing the usual number tower
> ℕ ⊂ ℤ ⊂ ℝ (or parts therefore)
Well, ℚ. You hardly ever see representations of numbers that are in ℝ-ℚ.
> scheme also captures ORTHOGONALLY (word in the docs) the (in)exact
On Mon, Jul 18, 2016, at 00:46, Ben Finney wrote:
> What is “those”? The measurement is imprecise, the observations are
> inexact.
>
> It makes no sense to say that a number is inexact. Exactness is not a
> property of a number.
There's no reason it shouldn't be a property of an object of a numer
Marko Rauhamaa wrote:
> Chris Angelico :
>> you don't need an infinite amount of paper, except that they work with
>> binary rather than decimal, so people think "0.1 + 0.2 ought to be
>> exactly 0.3, why isn't it??", and blame floats.
>
> Oh, if we only had eight fingers on our hand...
We alrea
Chris Angelico :
> you don't need an infinite amount of paper, except that they work with
> binary rather than decimal, so people think "0.1 + 0.2 ought to be
> exactly 0.3, why isn't it??", and blame floats.
Oh, if we only had eight fingers on our hand...
Scheme, though doesn't force the impleme
On Mon, Jul 18, 2016 at 8:24 PM, Rustom Mody wrote:
> I dont know what point you are trying to make
> Here is behavior. Should one use == ??
>
> Python 2.7.11+ (default, Apr 17 2016, 14:00:29)
> [GCC 5.3.1 20160413] on linux2
> Type "help", "copyright", "credits" or "license" for more information
On Monday, July 18, 2016 at 3:45:26 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote:
> > Python programmers (among others) frequently run into issues with
> > surprising results in floating-point arithmetics. For better or worse,
> > Scheme has tried to a
On Mon, Jul 18, 2016 at 8:00 PM, Marko Rauhamaa wrote:
> Python programmers (among others) frequently run into issues with
> surprising results in floating-point arithmetics. For better or worse,
> Scheme has tried to abstract the concept. You don't need to explain the
> ideas of IEEE 64-bit float
On Monday, July 18, 2016 at 2:59:56 PM UTC+5:30, Steven D'Aprano wrote:
> On Monday 18 July 2016 14:16, Rustom Mody wrote:
> > AIUI…
> > There are two almost completely unrelated notions of exact
> >
> > 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> > approximations.
> >
Steven D'Aprano :
> I think one could better think of Scheme's semantics as a
> poorly-thought out hybrid between traditional numerics and a vague
> approximation to interval arithmetic.
Python programmers (among others) frequently run into issues with
surprising results in floating-point arithme
On Monday 18 July 2016 14:16, Rustom Mody wrote:
> On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
>> But that's *wrong*. Numbers are never inexact. (You can have interval
>> arithmetic using "fuzzy numbers", but they're ALWAYS inexact.) It is
>> calculations which are e
Chris Angelico :
> Ah. Okay. So in theory, you could have exact float literals and
> inexact integer literals, if you tag them in some way:
>
> 300 ; Exactly 300
> 300! ; Inexact - roughly 300
> 3.0 ; Exactly three
> 3.0! ; Roughly three and zero tenths
In Scheme:
#e300
#i300
#e3.0
On Mon, Jul 18, 2016 at 3:37 PM, Rustom Mody wrote:
> On Monday, July 18, 2016 at 10:06:11 AM UTC+5:30, Chris Angelico wrote:
>> Why does that mean that 3.0 is inexact? In what way is 3.0 "inexact"?
>> It's an exact value representing the integer three.
>
> [Assuming you are asking in good faith a
On Monday, July 18, 2016 at 10:06:11 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Jul 18, 2016 at 2:16 PM, Rustom Mody wrote:
> > On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
> > Here are the first couple of hits it gives (me) for “scheme exact number”
> >
> > | Scheme
On Monday, July 18, 2016 at 10:16:58 AM UTC+5:30, Ben Finney wrote:
> You will be able to express yourself much more clearly on this topic
> when you cease conflating a number with measurements of that number, or
> conflating a number with representations of that number.
>
That more or less sums
Rustom Mody writes:
> AIUI…
> There are two almost completely unrelated notions of exact
>
> 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> approximations. We could call these inexact forms of ⅓
Better would be to use the term already used: 0. is an inexact
*represen
On Mon, Jul 18, 2016 at 2:16 PM, Rustom Mody wrote:
> On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
> Here are the first couple of hits it gives (me) for “scheme exact number”
>
> | Scheme integers can be exact and inexact. For example, a number
> | written as 3.0 with
On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:
>
> > Eliminate both of them. Move to a single abstract numeric type* a la
> > Scheme, with an "inexact" attribute (inexact numbers may or may not be
> > represented by a floa
On Sun, 17 Jul 2016 06:03 pm, Random832 wrote:
> On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
>> > True, although the programmer has control over the feature. If you
>> > *want* the luxury of exact fractions, you pay the price. If you don't,
>> > you make the numbers inexact.
>>
>> Not i
On Sun, Jul 17, 2016 at 6:08 PM, Random832 wrote:
> On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
>> Currently yes, you can choose to use fractions.Fraction and pay the
>> price. How, if you have a single type with different representations,
>> can you make that choice?
>
> Sorry, I forgot
On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
> Currently yes, you can choose to use fractions.Fraction and pay the
> price. How, if you have a single type with different representations,
> can you make that choice?
Sorry, I forgot to answer your question. Though, your implicit claim
that
On Sun, Jul 17, 2016, at 03:51, Chris Angelico wrote:
> > True, although the programmer has control over the feature. If you
> > *want* the luxury of exact fractions, you pay the price. If you don't,
> > you make the numbers inexact.
>
> Not if you have a single "Number" type:
Saying that exact a
On Sun, Jul 17, 2016 at 5:41 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> The trouble is, repeated addition of fractions is *able* to deliver an
>> exact result. It just might result in an incredibly slow program.
>
> True, although the programmer has control over the feature. If you
> *want*
Chris Angelico :
> The trouble is, repeated addition of fractions is *able* to deliver an
> exact result. It just might result in an incredibly slow program.
True, although the programmer has control over the feature. If you
*want* the luxury of exact fractions, you pay the price. If you don't,
y
On Sun, Jul 17, 2016 at 7:27 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> In that case, an 'Exact' non-integer will have appalling performance -
>> fractions.Fraction doesn't really work all that nicely when the
>> numbers start getting huge.
>
> In Scheme, any math operation is allowed to dr
Chris Angelico :
> In that case, an 'Exact' non-integer will have appalling performance -
> fractions.Fraction doesn't really work all that nicely when the
> numbers start getting huge.
In Scheme, any math operation is allowed to drop exactness:
If one of these procedures is unable to deliver
On Sun, Jul 17, 2016 at 4:04 AM, Random832 wrote:
> On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
>> Will an "Exact" non-integer be stored as Decimal or
>> Fraction? How do you know? They have vastly different semantics, and
>> you should be able to choose.
>
> Er, the point is for them to
Random832 :
> On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
>> Will an "Exact" non-integer be stored as Decimal or
>> Fraction? How do you know? They have vastly different semantics, and
>> you should be able to choose.
>
> Er, the point is for them to _not_ have different semantics. A dec
On Sat, Jul 16, 2016, at 03:27, Chris Angelico wrote:
> Will an "Exact" non-integer be stored as Decimal or
> Fraction? How do you know? They have vastly different semantics, and
> you should be able to choose.
Er, the point is for them to _not_ have different semantics. A decimal
storage format w
Oh, and a further thought...
On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
>
On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:
> On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
>> The difference between ints and floats can lead to bugs, too. Which
>> one should we eliminate?
>
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "ine
Chris Angelico :
> With a single abstract numeric type, what exactly does "inexact" mean,
> where does it come from, and how does that affect the expected
> behaviour and performance of numbers?
Not much is said in the standard:
Thus inexactness is a contagious property of a number. If two
On Sat, Jul 16, 2016 at 4:53 PM, Random832 wrote:
> On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
>> The difference between ints and floats can lead to bugs, too. Which
>> one should we eliminate?
>
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "i
On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
> The difference between ints and floats can lead to bugs, too. Which
> one should we eliminate?
Eliminate both of them. Move to a single abstract numeric type* a la
Scheme, with an "inexact" attribute (inexact numbers may or may not be
represe
On Sat, Jul 16, 2016 at 4:19 PM, Lawrence D’Oliveiro
wrote:
> On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote:
>>
>> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>>
>>> Just that suggesting that python's bool notion is straightforward is an
>>> unnecessary lie – especially to new
On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote:
>
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>
>> Just that suggesting that python's bool notion is straightforward is an
>> unnecessary lie – especially to newbies.
>
> Python's boolean concept is as simple as it gets -- what
On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>
> > Just that suggesting that python's bool notion is straightforward is an
> > unnecessary lie – especially to newbies.
>
> Python's boolean concept is as simple as it gets -- wh
On 07/15/2016 09:04 PM, Rustom Mody wrote:
Just that suggesting that python's bool notion is straightforward is an
unnecessary lie – especially to newbies.
Python's boolean concept is as simple as it gets -- what is not straightforward
about it?
--
~Ethan~
--
https://mail.python.org/mailman/
On Thursday, July 14, 2016 at 5:24:50 AM UTC+5:30, Peter Otten wrote:
> Lawrence D’Oliveiro wrote:
> > And there are still those who think that Python’s lax acceptance of
> > non-boolean values as booleans is a good idea...
>
> I don't think this particular problem serves as an argument for strict
On Wed, Jul 13, 2016 at 5:54 PM, Peter Otten <__pete...@web.de> wrote:
> Lawrence D’Oliveiro wrote:
>
>> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
>>
>>> There is a test
>>>
>>> if not object:
>>> raise ImportError('no Python documentation found for %r' % thing)
>>>
>>> i
Lawrence D’Oliveiro wrote:
> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
>
>> There is a test
>>
>> if not object:
>> raise ImportError('no Python documentation found for %r' % thing)
>>
>> in the pydoc module. So all you need is to ensure that your Registry
>> evaluate
On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
> There is a test
>
> if not object:
> raise ImportError('no Python documentation found for %r' % thing)
>
> in the pydoc module. So all you need is to ensure that your Registry
> evaluates to True in a boolean context, e. g.
On 07/08/2016 09:57 AM, Rob Gaddi wrote:
Michael Selik wrote:
On Jul 7, 2016, at 7:46 PM, Rob Gaddi wrote:
I've got a package that contains a global ensmartened dict that allows
all the various parts of my program to share state.
The simplest solution would be to use a module as your singl
Michael Selik wrote:
>
>
>> On Jul 7, 2016, at 7:46 PM, Rob Gaddi
>> wrote:
>>
>> I've got a package that contains a global ensmartened dict that allows
>> all the various parts of my program to share state.
>
> The simplest solution would be to use a module as your singleton. For
> example, "
Steven D'Aprano wrote:
> On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
>
> [...]
>>> Is this a thing that can be fixed with a commensurate amount of effort?
>>
>> There is a test
>>
>> if not object:
>> raise ImportError('no Python documentation found for %r' % thing)
>>
>> in the pydoc m
On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
[...]
>> Is this a thing that can be fixed with a commensurate amount of effort?
>
> There is a test
>
> if not object:
> raise ImportError('no Python documentation found for %r' % thing)
>
> in the pydoc module. So all you need is to ensure t
On Friday, July 8, 2016 at 1:15:04 PM UTC+5:30, Peter Otten wrote [slightly
edited]
> Peter Otten wrote:
>
> > You might also file a bug report asking to replace
> > if not object: ...
> >
> > with
> >
> >if object is None: ...
>
> I take that back; the problem is fixed in Python 3.5.
Hoo boy!
Peter Otten wrote:
> You might also file a bug report asking to replace
I take that back; the problem is fixed in Python 3.5.
--
https://mail.python.org/mailman/listinfo/python-list
Rob Gaddi wrote:
> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state. Things like device
> handles, information about the application environment, etc. that are
> inherantly global (i.e. we're not having that debate).
>
>
1 - 100 of 103 matches
Mail list logo
