On 2011-06-03, Chris Torek nos...@torek.net 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
On 2011-06-03, Nobody nob...@nowhere.com 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
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 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 improving your
On Tue, Jun 7, 2011 at 9:44 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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 -
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 another
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 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 used.
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,
In article mailman.2438.1307133316.9059.python-l...@python.org
Chris Angelico ros...@gmail.com 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
On Mon, Jun 6, 2011 at 8:54 AM, Chris Torek nos...@torek.net 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,
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 exceptional
On Mon, 06 Jun 2011 09:13:25 +1000, Chris Angelico wrote:
On Mon, Jun 6, 2011 at 8:54 AM, Chris Torek nos...@torek.net 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
On Mon, Jun 6, 2011 at 8:54 AM, Chris Torek nos...@torek.net 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
On Mon, Jun 6, 2011 at 11:21 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Mon, 06 Jun 2011 14:11:03 +1000, Chris Angelico wrote:
On Mon, Jun 6, 2011 at 11:21 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
The intended behaviour is operations on quiet NANs should return
NANs, but operations on signalling NANs should cause a trap, which
can
On Mon, Jun 6, 2011 at 2:59 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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 Jun 4, 4:29 am, Nobody nob...@nowhere.com 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,
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 them off?
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 another for
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
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
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 Fri, 03 Jun 2011 14:35:52 +1000, Chris Angelico wrote:
On Fri, Jun 3, 2011 at 2:23 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On 2011-06-02, Nobody nob...@nowhere.com 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
On 2011-06-02, Nobody nob...@nowhere.com wrote:
(I note that Python actually raises an exception for 0.0/0.0).
In article isasfm$inl$1...@reader1.panix.com
Grant Edwards invalid@invalid.invalid wrote:
IMHO, that's a bug. IEEE-754 states explicit that 0.0/0.0 is NaN.
Pythons claims it
On Wednesday, June 1, 2011 5:53:26 PM UTC-7, Steven D#39;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#39;Aprano wrote:
On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote:
Floating point arithmetic evolved more
On Sat, Jun 4, 2011 at 6:27 AM, Carl Banks pavlovevide...@gmail.com 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
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, and I find
On Sat, Jun 4, 2011 at 9:29 AM, Nobody nob...@nowhere.com 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
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, 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 really
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#39;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 mother
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 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 be. Please
On 2011-06-02, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 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. I wasn't
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 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 correct. For
On Fri, Jun 3, 2011 at 2:23 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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,
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 abstract real
On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks pavlovevide...@gmail.com 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
On 2011-06-01, Chris Angelico ros...@gmail.com wrote:
On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks pavlovevide...@gmail.com 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
On 2011-06-01, Roy Smith r...@panix.com wrote:
In article
Carl Banks pavlovevide...@gmail.com 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
On Wed, Jun 1, 2011 at 11:44 PM, Jerry Hill malaclyp...@gmail.com wrote:
On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks pavlovevide...@gmail.com 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
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 couldn't have
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 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
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. The one we
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 natural
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 is None:
On 2011-05-29, Nobody nob...@nowhere.com 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
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#39;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 Wed, 01 Jun 2011 14:03:14 +, Grant Edwards wrote:
On 2011-06-01, Chris Angelico ros...@gmail.com wrote:
On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks pavlovevide...@gmail.com
wrote:
On Sunday, May 29, 2011 7:53:59 PM UTC-7, Chris Angelico wrote:
Okay, here's a question. The Python
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 square
On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D#39;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 mistaken.
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
On Wed, Jun 1, 2011 at 12:59 PM, Carl Banks pavlovevide...@gmail.com 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
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 an IEEE
On Jun 1, 7:45 am, Carl Banks pavlovevide...@gmail.com wrote:
On Sunday, May 29, 2011 8:59:49 PM UTC-7, Steven D#39;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
In article
Carl Banks pavlovevide...@gmail.com 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 Wed, Jun 1, 2011 at 1:30 PM, Carl Banks pavlovevide...@gmail.com 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
Chris Angelico ros...@gmail.com 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
On Mon, 30 May 2011 04:29:19 +, Chris Torek wrote:
In article 4de31635$0$29990$c3e8da3$54964...@news.astraweb.com, Steven
D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
That's also completely wrong. The correct way to test for a NAN is with
the IEEE-mandated function isnan(). The 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 for
In article 4de3358b$0$29990$c3e8da3$54964...@news.astraweb.com
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On Mon, 30 May 2011 19:58:35 +, Chris Torek wrote:
In article 4de3358b$0$29990$c3e8da3$54964...@news.astraweb.com Steven
D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Better than a float method is a function which takes any number as
argument:
import math, fractions, decimal
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 themselves:
Python 2.7
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 Sun, 29 May 2011 10:32:43 +1000, Chris Angelico wrote:
On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins
mar...@letterboxes.org 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
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 != none,
On 2011-05-29, Wolfgang Rohdewald wolfg...@rohdewald.de 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,
On 29/05/2011 15:41, Grant Edwards wrote:
On 2011-05-29, Wolfgang Rohdewaldwolfg...@rohdewald.de 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).
On Mon, May 30, 2011 at 3:44 AM, MRAB pyt...@mrabarnett.plus.com 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
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
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
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 be a
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
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.
That's overstating
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 na...@animats.com wrote:
The correct answer to nan == nan is to raise an exception, because
you
On Sunday, May 29, 2011 4:31:19 PM UTC-7, Steven D#39;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 question for
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 for
On Mon, May 30, 2011 at 10:55 AM, Carl Banks pavlovevide...@gmail.com 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
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) would
On Mon, May 30, 2011 at 12:17 PM, Carl Banks pavlovevide...@gmail.com 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,
On May 30, 7:53 am, Chris Angelico ros...@gmail.com wrote:
On Mon, May 30, 2011 at 12:17 PM, Carl Banks pavlovevide...@gmail.com 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
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 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(inf) ==
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. Many
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
In article 4de31635$0$29990$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On May 28, 4:41 pm, MRAB pyt...@mrabarnett.plus.com 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
In article irv6ev01...@news1.newsguy.com 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
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}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
--
http://mail.python.org/mailman/listinfo/python-list
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}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
It's fundamentally because NaN is not equal to itself, by design.
Dictionaries
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 nans)
except that sometimes it can't:
nan = float(nan)
On 29 May 2011 10:16, Erik Max Francis m...@alcyone.com wrote:
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}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
It's
1 - 100 of 105 matches
Mail list logo
