On Tue, Jun 7, 2011 at 9:44 AM, Steven D'Aprano
wrote:
> Thank you for your concern about my mental health.
Mental health? You're a programmer. It's far too late to worry about that.
My name is Chris, and I'm a programmer. It started when I was just a
child - my parents thought it would be alrig
On Mon, 06 Jun 2011 23:14:15 +0100, Nobody wrote:
> On Mon, 06 Jun 2011 00:55:18 +, Steven D'Aprano wrote:
>
>> And thus we come back full circle. Hundreds of words, and I'm still no
>> closer to understanding why you think that "NAN == NAN" should be an
>> error.
>
> Well, you could try imp
On Mon, 06 Jun 2011 00:55:18 +, Steven D'Aprano wrote:
> And thus we come back full circle. Hundreds of words, and I'm still no
> closer to understanding why you think that "NAN == NAN" should be an
> error.
Well, you could try improving your reading comprehension. Counselling
might help.
On 2011-06-03, Nobody wrote:
>>> This would produce the same end result as raising an exception
>>> immediately, but would reduce the number of isnan() tests.
>>
>> I've never found the number of isnan() checks in my code to be an
>> issue -- there just arent that many of them, and when they are
On 2011-06-03, Chris Torek wrote:
>>> The definition is entirely arbitrary.
>>
>>I don't agree, but even if was entirely arbitrary, that doesn't make
>>the decision meaningless. IEEE-754 says it's True, and standards
>>compliance is valuable. Each country's decision to drive on the
>>right/left
On Mon, Jun 6, 2011 at 2:59 PM, Steven D'Aprano
wrote:
> On Mon, 06 Jun 2011 14:11:03 +1000, Chris Angelico wrote:
>> So does this mean that:
>> (with signalling NANs) should trap on the second line but not the first?
BTW, by "should" I meant "would if Python's float were 100% IEEE-754 compliant"
On Mon, 06 Jun 2011 14:11:03 +1000, Chris Angelico wrote:
> On Mon, Jun 6, 2011 at 11:21 AM, Steven D'Aprano
> wrote:
>> The intended behaviour is operations on "quiet NANs" should return
>> NANs, but operations on "signalling NANs" should cause a trap, which
>> can either be ignored, and convert
On Mon, Jun 6, 2011 at 11:21 AM, Steven D'Aprano
wrote:
> The intended behaviour is operations on "quiet NANs" should return NANs,
> but operations on "signalling NANs" should cause a trap, which can either
> be ignored, and converted into a quiet NAN, or treated as an exception.
>
> E.g. in Decim
>> On Mon, Jun 6, 2011 at 8:54 AM, Chris Torek wrote:
>>> A signalling NaN traps at (more or less -- details vary depending on
>>> FPU architecture) load time.
>On Mon, 06 Jun 2011 09:13:25 +1000, Chris Angelico wrote:
>> Load. By this you mean the operation of taking a bit-pattern in RAM and
>>
On Mon, 06 Jun 2011 09:13:25 +1000, Chris Angelico wrote:
> On Mon, Jun 6, 2011 at 8:54 AM, Chris Torek wrote:
>> A signalling NaN traps at (more or less -- details vary depending on
>> FPU architecture) load time.
>
> Load. By this you mean the operation of taking a bit-pattern in RAM and
> put
On Sun, 05 Jun 2011 19:15:02 +0100, Nobody wrote:
> On Sun, 05 Jun 2011 07:21:10 +, Steven D'Aprano wrote:
>
>> Returning a sentinel meaning "an exceptional event occurred" is hardly
>> unusual, even in Python. str.find() does is, as does re.search() and
>> re.match().
>
> These are not "exc
On Mon, Jun 6, 2011 at 8:54 AM, Chris Torek wrote:
> A signalling NaN traps at (more or less -- details vary depending
> on FPU architecture) load time.
Load. By this you mean the operation of taking a bit-pattern in RAM
and putting it into a register? So, you can calculate 0/0, get a
signalling
In article
Chris Angelico wrote:
>Uhh, noob question here. I'm way out of my depth with hardware
>floating point.
>
>Isn't a signaling nan basically the same as an exception?
Not exactly, but one could think of them as "very similar".
Elsethread, someone brought up the key distinction, which i
On 6/4/11 9:03 PM, Steven D'Aprano wrote:
On Sat, 04 Jun 2011 16:49:40 -0500, Robert Kern wrote:
Steven is being a little hyperbolic. Python does not fully conform to
all of the details of the IEEE-754 specification, though it does conform
to most of them.
I'm not sure that "most" is correct,
On Sun, 05 Jun 2011 07:21:10 +, Steven D'Aprano wrote:
> Returning a sentinel meaning "an exceptional event occurred" is hardly
> unusual, even in Python. str.find() does is, as does re.search() and
> re.match().
These are not "exceptional" conditions; if they were, an exception would
be us
Gregory Ewing wrote:
Steven D'Aprano wrote:
Fair point. Call it an extension of the Kronecker Delta to the reals
then.
That's called the Dirac delta function, and it's a bit different --
instead of a value of 1, it has an infinitely high spike of zero
width at the origin, whose integral is 1.
On Sat, 04 Jun 2011 00:29:10 +0100, Nobody wrote:
> If you're "fluent" in IEEE-754, then you won't find its behaviour
> unexpected. OTOH, if you are approach the issue without preconceptions,
> you're likely to notice that you effectively have one exception
> mechanism for floating-point and anoth
On Sat, 04 Jun 2011 16:49:40 -0500, Robert Kern wrote:
> Steven is being a little hyperbolic. Python does not fully conform to
> all of the details of the IEEE-754 specification, though it does conform
> to most of them.
I'm not sure that "most" is correct, but that depends on how you count
the
On 6/4/11 4:28 PM, Ethan Furman wrote:
Steven D'Aprano wrote:
On Fri, 03 Jun 2011 23:04:38 -0700, Ethan Furman wrote:
Steven D'Aprano wrote:
NANs are not necessarily errors, they're hardly silent, and if you
don't want NANs, the standard mandates that there be a way to turn them
off.
So how
Steven D'Aprano wrote:
On Fri, 03 Jun 2011 23:04:38 -0700, Ethan Furman wrote:
Steven D'Aprano wrote:
NANs are not necessarily errors, they're hardly silent, and if you
don't want NANs, the standard mandates that there be a way to turn them
off.
So how does one turn them off in standard Pytho
On Sat, 04 Jun 2011 00:52:17 -0700, rusi wrote:
>> If you're "fluent" in IEEE-754, then you won't find its behaviour
>> unexpected. OTOH, if you are approach the issue without preconceptions,
>> you're likely to notice that you effectively have one exception mechanism
>> for floating-point and ano
Steven D'Aprano writes:
> What makes you think that Python supports IEEE-754 for floats?
That would be an easy impression to get from this long rambling thread.
The argument that Python's ‘float’ type is not meant to be anything
*but* an IEEE 754 floating point type has been made several times.
On Fri, 03 Jun 2011 23:04:38 -0700, Ethan Furman wrote:
> Steven D'Aprano wrote:
>> NANs are not necessarily errors, they're hardly silent, and if you
>> don't want NANs, the standard mandates that there be a way to turn them
>> off.
>
> So how does one turn them off in standard Python?
Turn the
On Jun 4, 4:29 am, Nobody wrote:
> On Fri, 03 Jun 2011 14:52:39 +, Grant Edwards wrote:
> >> It's arguable that NaN itself simply shouldn't exist in Python; if
> >> the FPU ever generates a NaN, Python should raise an exception at
> >> that point.
>
>
> If you're "fluent" in IEEE-754, then yo
Steven D'Aprano wrote:
NANs are not necessarily errors, they're hardly silent, and if you don't
want NANs, the standard mandates that there be a way to turn them off.
So how does one turn them off in standard Python?
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 03 Jun 2011 13:27:00 -0700, Carl Banks wrote:
> On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D'Aprano wrote:
[...]
>> On the contrary, it blows it out of the water and stomps its corpse
>> into a stain on the ground.
>
> Really? I am claiming that, even if everyone and their mothe
On Sat, 04 Jun 2011 12:14:03 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> Fair point. Call it an extension of the Kronecker Delta to the reals
>> then.
>
> That's called the Dirac delta function, and it's a bit different
Yes, I'm familiar with the Dirac delta. As you say, it's not re
Steven D'Aprano wrote:
Fair point. Call it an extension of the Kronecker Delta to the reals then.
That's called the Dirac delta function, and it's a bit different --
instead of a value of 1, it has an infinitely high spike of zero
width at the origin, whose integral is 1. (Which means it's not
On Sat, Jun 4, 2011 at 9:29 AM, Nobody wrote:
> Floats are supposed to approximate reals. They're also a Python
> data type, and should make some effort to fit in with the rest of
> the language.
>
That's what I thought a week ago. But that's not really true. Floats
are supposed to hold non-integ
On Fri, 03 Jun 2011 14:52:39 +, Grant Edwards wrote:
>> It's arguable that NaN itself simply shouldn't exist in Python; if
>> the FPU ever generates a NaN, Python should raise an exception at
>> that point.
>
> Sorry, I just don't "get" that argument. I depend on compliance with
> IEEE-754,
On Sat, Jun 4, 2011 at 6:27 AM, Carl Banks wrote:
> Really? I am claiming that, even if everyone and their mother thought
> exceptions were the best thing ever, NaN would have been added to IEEE anyway
> because most hardware didn't support exceptions. Therefore the fact that NaN
> is in IEEE
On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D'Aprano wrote:
> On Tue, 31 May 2011 19:45:01 -0700, Carl Banks wrote:
>
> > On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> >> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
> >>
> >> > Floating point arithmetic evolv
>On 2011-06-02, Nobody wrote:
>> (I note that Python actually raises an exception for "0.0/0.0").
In article
Grant Edwards wrote:
>IMHO, that's a bug. IEEE-754 states explicit that 0.0/0.0 is NaN.
>Pythons claims it implements IEEE-754. Python got it wrong.
Indeed -- or at least, inconsiste
On 2011-06-02, Nobody wrote:
> On Thu, 02 Jun 2011 09:54:30 +, Steven D'Aprano wrote:
>
>>> Exceptions allow you to write more natural code by ignoring the
>>> awkward cases. E.g. writing "x * y + z" rather than first determining
>>> whether "x * y" is even defined then using a conditional.
>>
On Fri, 03 Jun 2011 14:35:52 +1000, Chris Angelico wrote:
> On Fri, Jun 3, 2011 at 2:23 PM, Steven D'Aprano
> wrote:
>>> You can't get a valid result from data produced by an invalid
>>> computation. Garbage in, garbage out.
>>
>> Of course you can. Here's a trivial example:
>>
>> def f(x):
>>
On Fri, Jun 3, 2011 at 2:23 PM, Steven D'Aprano
wrote:
>> You can't get a valid result from data produced by an invalid
>> computation. Garbage in, garbage out.
>
> Of course you can. Here's a trivial example:
>
> def f(x):
> return 1
>
If your incoming x is garbage, your outgoing 1 is also ga
On Fri, 03 Jun 2011 11:17:17 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>
>> def kronecker(x, y):
>> if x == y: return 1
>> return 0
>>
>> This will correctly consume NAN arguments. If either x or y is a NAN,
>> it will return 0.
>
> I'm far from convinced that this result is
Steven D'Aprano wrote:
def kronecker(x, y):
if x == y: return 1
return 0
This will correctly consume NAN arguments. If either x or y is a NAN, it
will return 0.
I'm far from convinced that this result is "correct". For one
thing, the Kronecker delta is defined on integers, not reals,
On Thu, 02 Jun 2011 09:54:30 +, Steven D'Aprano wrote:
>> Exceptions allow you to write more natural code by ignoring the awkward
>> cases. E.g. writing "x * y + z" rather than first determining whether "x
>> * y" is even defined then using a conditional.
>
> You've quoted me out of context.
On 6/2/11 8:05 AM, Grant Edwards wrote:
Two of my perennial complaints about Python's handling of NaNs and
Infs:
1) They weren't handle by pickle et al.
2) The string representations produced by repr() and accepted by
float() weren't standardized across platforms.
I think the latter
On 2011-06-02, Steven D'Aprano wrote:
> But IEEE-754 is not just a "not-very-good" standard. It is an
> extremely good standard.
I get the distinct impression that the people arguing that IEEE-754 is
somehow "wrong" about the value of 'NaN == NaN' are the people who
don't actually use floating p
On Wed, 01 Jun 2011 21:41:06 +0100, Nobody wrote:
> On Sun, 29 May 2011 23:31:19 +, Steven D'Aprano wrote:
>
>>> That's overstating it. There's a good argument to be made for raising
>>> an exception.
>>
>> If so, I've never heard it, and I cannot imagine what such a good
>> argument would b
On 5/31/2011 7:45 PM, Carl Banks wrote:
Fine, it wasn't "unheard of". I'm pretty sure the existence of a few
high end compiler/hardware combinations that supported traps doesn't
invalidate my basic point. NaN was needed because few systems had a
separate path to deal with exceptional situations
On Wed, 01 Jun 2011 13:41:15 -0700, Carl Banks wrote:
> On Wednesday, June 1, 2011 11:10:33 AM UTC-7, Ethan Furman wrote:
>> Carl Banks wrote:
>> > For instance, say you are using an implementation that uses
>> > floating point, and you define a function that uses Newton's method
>> > to find a
On Wed, 01 Jun 2011 14:03:14 +, Grant Edwards wrote:
> On 2011-06-01, Chris Angelico wrote:
>> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks
>> wrote:
>>> On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
Okay, here's a question. The Python 'float' value - is it meant to be
On Tue, 31 May 2011 19:45:01 -0700, Carl Banks wrote:
> On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
>> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
>>
>> > Floating point arithmetic evolved more or less on languages like
>> > Fortran where things like exceptions were
On 2011-05-29, Nobody wrote:
> On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
>
>>> The correct answer to "nan == nan" is to raise an exception, because
>>> you have asked a question for which the answer is nether True nor
>>> False.
>>
>> Wrong.
>
> That's overstating it. There's a g
On Wednesday, June 1, 2011 11:10:33 AM UTC-7, Ethan Furman wrote:
> Carl Banks wrote:
> > For instance, say you are using an implementation that uses
> > floating point, and you define a function that uses Newton's
> > method to find a square root:
> >
> > def square_root(N,x=None):
> > if x
On Sun, 29 May 2011 23:31:19 +, Steven D'Aprano wrote:
>> That's overstating it. There's a good argument to be made for raising an
>> exception.
>
> If so, I've never heard it, and I cannot imagine what such a good
> argument would be. Please give it.
Exceptions allow you to write more nat
On Wednesday, June 1, 2011 10:17:54 AM UTC-7, OKB (not okblacke) wrote:
> Carl Banks wrote:
>
> > On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> >> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
> > Python has several non-integer number types in the standard
> > library. T
>Carl Banks wrote:
>> For instance, say you are using an implementation that uses
> > floating point, and you define a function that uses Newton's
> > method to find a square root:
>>
>> def square_root(N,x=None):
>> if x is None:
>> x = N/2
>> for i in range(100):
>> x = (
Carl Banks wrote:
For instance, say you are using an implementation that uses
> floating point, and you define a function that uses Newton's
> method to find a square root:
def square_root(N,x=None):
if x is None:
x = N/2
for i in range(100):
x = (x + N/x)/2
return
Carl Banks wrote:
> On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
>> > I think you misunderstood what I was saying.
>> >
>> > It's not *possible* to represent a real number abstractly in any
>> > digita
> l computer. Python
On Wed, Jun 1, 2011 at 11:44 PM, Jerry Hill wrote:
>> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
>> True, but why should the "non-integer number" type be floating point
>> rather than (say) rational?
Careful with the attributions, Carl was quoting me when he posted that :)
> You seem to
On 2011-06-01, Roy Smith wrote:
> In article
> Carl Banks wrote:
>
>> pretty much everyone uses IEEE format
>
> Is there *any* hardware in use today which supports floating point using
> a format other than IEEE?
Well, there are probably still some VAXes around in odd corners...
--
Grant Edw
On 2011-06-01, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks wrote:
>> On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
>>> Okay, here's a question. The Python 'float' value - is it meant to be
>>> "a Python representation of an IEEE double-precision floating
> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
> True, but why should the "non-integer number" type be floating point
> rather than (say) rational?
You seem to be implying that python only provides a single non-integer
numeric type. That's not true. Python ships with a bunch of
different n
On Tuesday, May 31, 2011 8:57:57 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks
> wrote:
> > I think you misunderstood what I was saying.
> >
> > It's not *possible* to represent a real number abstractly in any digital
> > computer. Python couldn't have an "abstrac
Chris Angelico writes:
> Right. Obviously a true 'real number' representation can't be done.
> But there are multiple plausible approximations thereof (the best
> being rationals).
Sure. But most of those are not what is most commonly meant by ‘float’
type.
> Not asking for Python to be changed
On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks wrote:
> I think you misunderstood what I was saying.
>
> It's not *possible* to represent a real number abstractly in any digital
> computer. Python couldn't have an "abstract real number" type even it wanted
> to.
True, but why should the "non-integ
In article
Carl Banks wrote:
> pretty much everyone uses IEEE format
Is there *any* hardware in use today which supports floating point using
a format other than IEEE?
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 1, 7:45 am, Carl Banks wrote:
> On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> > On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
>
> > > Floating point arithmetic evolved more or less on languages like Fortran
> > > where things like exceptions were unheard of,
>
>
On Tuesday, May 31, 2011 8:05:43 PM UTC-7, Chris Angelico wrote:
> On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks
> wrote:
> > On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
> >> Okay, here's a question. The Python 'float' value - is it meant to be
> >> "a Python representation of a
On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks wrote:
> On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
>> Okay, here's a question. The Python 'float' value - is it meant to be
>> "a Python representation of an IEEE double-precision floating point
>> value", or "a Python representatio
On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
> Okay, here's a question. The Python 'float' value - is it meant to be
> "a Python representation of an IEEE double-precision floating point
> value", or "a Python representation of a real number"?
The former. Unlike the case with i
On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D'Aprano wrote:
> On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
>
> > Floating point arithmetic evolved more or less on languages like Fortran
> > where things like exceptions were unheard of,
>
> I'm afraid that you are completely mistake
On Mon, 30 May 2011 19:58:35 +, Chris Torek wrote:
> In article <4de3358b$0$29990$c3e8da3$54964...@news.astraweb.com> Steven
> D'Aprano wrote:
>>Better than a float method is a function which takes any number as
>>argument:
>>
> import math, fractions, decimal
> math.isnan(fractions.
In article <4de3358b$0$29990$c3e8da3$54964...@news.astraweb.com>
Steven D'Aprano wrote:
>Better than a float method is a function which takes any number as
>argument:
>
import math, fractions, decimal
math.isnan(fractions.Fraction(2, 3))
>False
math.isnan(decimal.Decimal('nan'))
>
On Mon, 30 May 2011 04:15:11 +, Steven D'Aprano wrote:
> On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:
>
>> So, apart from float("nan"), are there actually any places where real
>> production code has to handle NaN? I was unable to get a nan by any of
>> the above methods, except
On Mon, 30 May 2011 04:29:19 +, Chris Torek wrote:
> In article <4de31635$0$29990$c3e8da3$54964...@news.astraweb.com>, Steven
> D'Aprano wrote:
>>That's also completely wrong. The correct way to test for a NAN is with
>>the IEEE-mandated function isnan(). The NAN != NAN trick is exactly
>>th
In article I wrote, in part:
>_inf = float("inf")
>def isinf(x):
>return x == _inf
>del _inf
Oops, take out the del, or otherwise fix the obvious problem,
e.g., perhaps:
def isinf(x):
return x == isinf._inf
isinf._inf = float("inf")
(Of course, if something l
On May 28, 4:41 pm, MRAB wrote:
> Here's a curiosity. float("nan") can occur multiple times in a set or as
> a key in a dict:
Which is by design.
NaNs intentionally have multiple possible instances (some
implementations even include distinct payload values).
Sets and dicts intentionally recogni
In article <4de31635$0$29990$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
>That's also completely wrong. The correct way to test for a NAN is with
>the IEEE-mandated function isnan(). The NAN != NAN trick is exactly that,
>a trick, used by programmers when their language or compi
On 5/29/2011 9:15 PM, Steven D'Aprano wrote:
On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:
So, apart from float("nan"), are there actually any places where real
production code has to handle NaN?
Yes. I used to write dynamic simulation engines. There were
situations that prod
On Mon, 30 May 2011 12:53:59 +1000, Chris Angelico wrote:
> Okay, here's a question. The Python 'float' value - is it meant to be "a
> Python representation of an IEEE double-precision floating point value",
Yes.
> or "a Python representation of a real number"?
No.
Floats are not real numbers
On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:
> So, apart from float("nan"), are there actually any places where real
> production code has to handle NaN? I was unable to get a nan by any of
> the above methods, except for operations involving inf; for instance,
> float("inf")-float("i
On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
> Floating point arithmetic evolved more or less on languages like Fortran
> where things like exceptions were unheard of,
I'm afraid that you are completely mistaken.
Fortran IV had support for floating point traps, which are "things like
On May 30, 7:53 am, Chris Angelico wrote:
> On Mon, May 30, 2011 at 12:17 PM, Carl Banks wrote:
> > If I were designing a new floating-point standard for hardware, I would
> > consider getting rid of NaN. However, with the floating point standard
> > that exists, that almost all floating point
On Mon, May 30, 2011 at 12:17 PM, Carl Banks wrote:
> If I were designing a new floating-point standard for hardware, I would
> consider getting rid of NaN. However, with the floating point standard that
> exists, that almost all floating point hardware mostly conforms to, there are
> certain
On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote:
> On Mon, May 30, 2011 at 10:55 AM, Carl Banks
> wrote:
> > If exceptions had commonly existed in that environment there's no chance
> > they would have chosen that behavior; comparison against NaN (or any
> > operation with NaN) w
On Mon, May 30, 2011 at 10:55 AM, Carl Banks wrote:
> If exceptions had commonly existed in that environment there's no chance they
> would have chosen that behavior; comparison against NaN (or any operation
> with NaN) would have signaled a floating point exception. That is the
> correct way
On Sunday, May 29, 2011 7:41:13 AM UTC-7, Grant Edwards wrote:
> It treats them as identical (not sure if that's the right word). The
> implementation is checking for ( A is B or A == B ). Presumably, the
> assumpting being that all objects are equal to themselves. That
> assumption is not true
On Sunday, May 29, 2011 4:31:19 PM UTC-7, Steven D'Aprano wrote:
> On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:
>
> > On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
> >
> >>> The correct answer to "nan == nan" is to raise an exception,
> >>> because
> >>> you have asked a
Incidentally, note:
$ python
...
>>> nan = float("nan")
>>> nan
nan
>>> nan is nan
True
>>> nan == nan
False
In article <4de1e3e7$0$2195$742ec...@news.sonic.net>
John Nagle wrote:
>The correct answer to "nan == nan" is to raise an exception, because
>you
On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:
> On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
>
>>> The correct answer to "nan == nan" is to raise an exception,
>>> because
>>> you have asked a question for which the answer is nether True nor
>>> False.
>>
>> Wrong.
>
>
On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
>> The correct answer to "nan == nan" is to raise an exception, because
>> you have asked a question for which the answer is nether True nor False.
>
> Wrong.
That's overstating it. There's a good argument to be made for raising an
e
On Sun, 29 May 2011 20:05:07 +0200, Christian Heimes wrote:
> Am 29.05.2011 19:44, schrieb MRAB:
>> Would there be any advantage to making NaN a singleton? I'm thinking
>> that it could make checking for it cheaper in the implementation of
>> sets and dicts. Or making NaN unhashable?
>
> It can't
On Sun, 29 May 2011 18:44:08 +0100, MRAB wrote:
> Would there be any advantage to making NaN a singleton?
Absolutely not. That would be a step backwards.
NANs can carry payload (a code indicating what sort of NAN it represents
-- log(-1) and 1/INF are not the same). So although Python currently
Am 29.05.2011 19:44, schrieb MRAB:
> Would there be any advantage to making NaN a singleton? I'm thinking
> that it could make checking for it cheaper in the implementation of
> sets and dicts. Or making NaN unhashable?
It can't be a singleton, because IEEE 754 specifies millions of millions
of di
On Mon, May 30, 2011 at 3:44 AM, MRAB wrote:
> Would there be any advantage to making NaN a singleton? I'm thinking
> that it could make checking for it cheaper in the implementation of
> sets and dicts. Or making NaN unhashable?
Doesn't matter. It still wouldn't be equal to itself, even though i
On 29/05/2011 15:41, Grant Edwards wrote:
On 2011-05-29, Wolfgang Rohdewald wrote:
On Sonntag 29 Mai 2011, Tim Delaney wrote:
There's a second part the mystery - sets and dictionaries (and
I think lists) assume that identify implies equality (hence
the second result). This was recently discuss
On 2011-05-29, Wolfgang Rohdewald wrote:
> On Sonntag 29 Mai 2011, Tim Delaney wrote:
>> There's a second part the mystery - sets and dictionaries (and
>> I think lists) assume that identify implies equality (hence
>> the second result). This was recently discussed on
>> python-dev, and the decisi
On Sat, 28 May 2011 23:12:54 -0700, John Nagle wrote:
> The correct answer to "nan == nan" is to raise an exception, because
> you have asked a question for which the answer is nether True nor False.
Wrong.
The correct answer to "nan == nan" is False, they are not equal. Just as
None != "no
On Sun, 29 May 2011 10:32:43 +1000, Chris Angelico wrote:
> On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins
> wrote:
>> This is the same nan, so it is equal to itself.
>>
>>
> Actually, they're not. But it's possible the dictionary uses an 'is'
> check to save computation, and if one thing 'is'
On Sonntag 29 Mai 2011, Tim Delaney wrote:
> There's a second part the mystery - sets and dictionaries (and
> I think lists) assume that identify implies equality (hence
> the second result). This was recently discussed on
> python-dev, and the decision was to leave things as-is.
On Sonntag 29 Mai
On 5/28/2011 6:04 PM, Gregory Ewing wrote:
MRAB wrote:
float("nan") can occur multiple times in a set or as a key in a dict:
>>> {float("nan"), float("nan")}
{nan, nan}
except that sometimes it can't:
>>> nan = float("nan")
>>> {nan, nan}
{nan}
NaNs are weird. They're not equal to themselve
On 2011-05-29, Albert Hopkins wrote:
> On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
>> Here's a curiosity. float("nan") can occur multiple times in a set or as
>> a key in a dict:
>>
>> >>> {float("nan"), float("nan")}
>> {nan, nan}
>>
> These two nans are not equal (they are two different n
MRAB wrote:
float("nan") can occur multiple times in a set or as
a key in a dict:
>>> {float("nan"), float("nan")}
{nan, nan}
except that sometimes it can't:
>>> nan = float("nan")
>>> {nan, nan}
{nan}
NaNs are weird. They're not equal to themselves:
Python 2.7 (r27:82500, Oct 15 2010,
Albert Hopkins wrote:
On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
1.0 == 1.0
True
float("nan") == float("nan")
False
I can't cite this in a spec, but it makes sense (to me) that two things
which are nan are not necessarily the same nan.
It's part of the IEEE standard.
--
Erik Max Franc
On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins wrote:
> This is the same nan, so it is equal to itself.
>
Actually, they're not. But it's possible the dictionary uses an 'is'
check to save computation, and if one thing 'is' another, it is
assumed to equal it. That's true of most well-behaved ob
1 - 100 of 105 matches
Mail list logo
