Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Well, at least it was an interesting bug report ;-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14028
___
= [choose(c) for dummy in 123456]
File /.../lib/python2.6/random.py, line 261, in choice
return seq[int(self.random() * len(seq))] # raises IndexError if seq is
empty
ValueError: cannot convert float NaN to integer
This is rare and hard to reproduce. The hardware appears to be healthy
Shivam shivam.agar...@aricent.com added the comment:
Hi Terry,
Thanks for your reply.
I am made changes suggested by you but still getting the same error:
Below is the change that have been made:
try:
local_var = (os.fstat(f.fileno()).st_mtime) -- added line
Mark Dickinson dicki...@gmail.com added the comment:
It's going to be tricky for any of the core Python developers to solve this
based on the current level of information---unless anyone has access to a MIPs
machine and can reproduce the error, that is. Can you find a local expert who
knows
Terry J. Reedy tjre...@udel.edu added the comment:
If I believe the error message, os.fstat(f.fileno()).st_mtime is returning a
NaN, which would be a bug in our function or your system. Since os.fstat should
be a thin wrapper over the system call, I would lean to the latter. I do not
know
convert float NaN to integer
make: *** [libinstall] Error 1
Addtionaly:
---
At the time of make below message is flashed as well:
Failed to build these modules:
datetime dbm
--
components: Build
messages: 153039
nosy: shivam_python_issues
priority: normal
severity: normal
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13986
___
___
Python-bugs-list
Shivam shivam.agar...@aricent.com added the comment:
Hi Team,
I am having this issue on mips 64bit machine running debian.
Regards
Shivam Agarwal
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13986
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13986
___
___
On 13 jan, 20:04, Ethan Furman et...@stoneleaf.us wrote:
With NaN, it is possible to get a list that will not properly sort:
-- NaN = float('nan')
-- spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
-- sorted(spam)
[1, 2, nan, 3, nan, 4, 5, 7, nan]
I'm constructing a Null object with the semantics
On Mon, Jan 16, 2012 at 9:22 PM, Eelco hoogendoorn.ee...@gmail.com wrote:
What you want, conceptually, is a
sorted list of the sortable entries, and a seperate list of the
unsorted entries. Translated into code, the most pure solution would
be to filter out the nanas/nulls in their own list
On 1/16/12 10:57 AM, Chris Angelico wrote:
On Mon, Jan 16, 2012 at 9:22 PM, Eelcohoogendoorn.ee...@gmail.com wrote:
What you want, conceptually, is a
sorted list of the sortable entries, and a seperate list of the
unsorted entries. Translated into code, the most pure solution would
be to
With NaN, it is possible to get a list that will not properly sort:
-- NaN = float('nan')
-- spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
-- sorted(spam)
[1, 2, nan, 3, nan, 4, 5, 7, nan]
I'm constructing a Null object with the semantics that if the returned
object is Null, it's actual value
On Sat, Jan 14, 2012 at 6:04 AM, Ethan Furman et...@stoneleaf.us wrote:
So I am strongly leaning towards implementing the comparisons such that Null
objects are less than other objects so they will always sort together.
This is a perfectly plausible view, and is the one adopted by SQL (I'm
On 13/01/2012 19:58, Chris Angelico wrote:
On Sat, Jan 14, 2012 at 6:04 AM, Ethan Furmanet...@stoneleaf.us wrote:
So I am strongly leaning towards implementing the comparisons such that Null
objects are less than other objects so they will always sort together.
This is a perfectly
On Fri, 13 Jan 2012 11:04:48 -0800, Ethan Furman wrote:
With NaN, it is possible to get a list that will not properly sort:
-- NaN = float('nan')
-- spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN] -- sorted(spam)
[1, 2, nan, 3, nan, 4, 5, 7, nan]
I'm constructing a Null object
On 13 jan, 20:04, Ethan Furman et...@stoneleaf.us wrote:
With NaN, it is possible to get a list that will not properly sort:
-- NaN = float('nan')
-- spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN]
-- sorted(spam)
[1, 2, nan, 3, nan, 4, 5, 7, nan]
I'm constructing a Null object with the semantics
Sven Marnach s...@marnach.net added the comment:
The behaviour discussed in this thread does not seem to be reflected in
Python's documentation. The documentation of __eq__() [1] doesn't mention that
objects should compare equal to themselves.
[1]:
Everyone,
I'm pleased to announce a new alpha release of GMPY2.
GMPY2 is a wrapper for GMP and MPFR multiple-precision
arithmetic libraries.
GMPY2 alpha2 introduces context manager support for
MPFR arithmetic. It's now possible to trigger an exception
when comparing against nan (and other
New submission from Johann C. Rocholl jcroch...@google.com:
l = [1.0, 2.0, 3.0, float('nan'), 4.0, 3.0, 2.0, 1.0]
l.sort()
l
[1.0, 2.0, 3.0, nan, 1.0, 2.0, 3.0, 4.0]
The expected result is either of the following:
[nan, 1.0, 1.0, 2.0, 2.0, 3.0, 3.0, 4.0] (similar to None)
[1.0, 1.0, 2.0, 2.0
Ezio Melotti ezio.melo...@gmail.com added the comment:
This is expected. See also #11986 and #11949.
--
nosy: +belopolsky, ezio.melotti, mark.dickinson, rhettinger
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
This is actually a duplicate of issue7915.
I don't think there is nothing we can do to improve the situation. In fact
discussion at #11949 ends with a +0 from Mark Dickinson to issue a warning
whenever nans participate
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
they are there,
it provides an easy to read and easy to maintain way to handle things.
I think that you misunderstood. What I was saying here was that, if you
wanted exception-on-NaN behaviour from Python, the interpreter wouldn't
need to call isnan() on every value received from the FPU
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 -
saying that it's [NAN == NAN] True: they only really
had two choices: either it's True or it's False.
Incorrect. They could have specified that it was an error, like dividing
by zero, but they didn't. Instead, the standard specifies that there are
four mutually exclusive relationships possible
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.
.
E.g. dict supports both d.get(key) and d[key] for lookups. The former
returns a sentinel, the latter raises an exception. The latter makes sense
if you expect the key to be present, the former if you don't.
As for IEEE-754 saying that it's [NAN == NAN] True: they only really
had two choices
and NAN. Many thanks to those who did that work, whoever you are!)
In particular, it raises an exception when you divide
by 0.0 when the IEEE-754 specification states that you ought to issue
the divide by zero or invalid signal depending on the numerator (and
which may be trapped by the user
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 similar
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
)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: substring not found
spam.find(z)
-1
As for IEEE-754 saying that it's [NAN == NAN] True: they only really
had two choices: either it's True or it's False.
Incorrect. They could have specified that it was an error
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
either be ignored, and converted into a quiet NAN, or treated as an
exception.
E.g. in Decimal: [snip]
So does this mean that:
a = 0.0/0.0
b = a + 1
(with signalling NANs) should trap on the second line but not the first?
That's the first operation on a nan.
Sort of.
Firstly, in order
the
traps and you'll get propagating NANs;
- if you need to detect the presence of a NAN in your calculation, you
can inspect the flags at any time and take whatever action you want;
- and if you want a signalling NAN, you have to inject it yourself into
your calculation, and then avoid using
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
, in _raise_error
raise error(explanation)
decimal.DivisionByZero: x / 0
To get INF or NAN semantics is easy for decimal:
decimal.setcontext(decimal.ExtendedContext)
1/decimal.Decimal(0)
Decimal('Infinity')
but impossible for float. The best you can do is subclass float, or
surround each calculation
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
for everything else.
Three actually: None, nan and exceptions
None isn't really an exception; at least, it shouldn't be used like that.
Exceptions are for conditions which are in some sense exceptional. Cases
like dict.get() returning None when the key isn't found are meant for
the situation where
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 the numerator (and which may be trapped by the user, but not
by default) and will return either an inf or a NaN value if not trapped. Thus,
the canonical example of a NaN-returning operation in fully-conforming IEEE-754
arithmetic, 0.0/0.0, raises an exception in Python. You can generate a NaN by
other
the details. Let's just say it has partial support and let's not attempt
to quantify it.
(Which is a big step up from how things were even just a few years ago,
when there wasn't even a consistent way to create special values like INF
and NAN. Many thanks to those who did that work, whoever you
example:
def f(x):
return 1
If your incoming x is garbage, your outgoing 1 is also garbage.
If there were non-garbage input where f(x) would return something other
than 1, then you might argue that well, we can't be sure what value
f(x) should return, so we better return a NAN
.
You've quoted me out of context. I wasn't asking for justification
for exceptions in general. There's no doubt that they're useful. We
were specifically talking about NAN == NAN raising an exception
rather than returning False.
It's arguable that NaN itself simply shouldn't exist in Python
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 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 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 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
you're not really using floats as approximations
of reals, but as some set of discrete values, in which case
it's probably safer to use appropriately-scaled integers.
- from William Kahan, and the C99 standard: hypot(INF, x) is always INF
regardless of the value of x, hence hypot(INF, NAN) returns
relevant to the question on hand.
In any case, my faux Kronecker was just a throw away example. If you
don't like it, throw it away! The specific example doesn't matter, since
the principle applies: functions may throw away NANs if they are not
relevant to the calculation. The presence of a NAN
thought
exceptions were the best thing ever, NaN would have been added to IEEE
anyway because most hardware didn't support exceptions.
You can claim that the Atlantic Ocean is made of strawberry yoghurt too,
if you like, but that doesn't make it true.
The standard was written by people who made
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
. There's no doubt that they're useful. We were
specifically talking about NAN == NAN raising an exception rather than
returning False.
Bear in mind that an exception is not necessarily an error, just an
exceptional condition.
True, but what's your point? Testing two floats for equality
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
has finally been fixed, hasn't it?
And the former!
Python 2.7.1 |EPD 7.0-2 (32-bit)| (r271:86832, Dec 3 2010, 15:41:32)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type help, copyright, credits or license for more information.
inf = 1e300*1e300
nan = inf / inf
import cPickle
cPickle.loads
asking for justification for
exceptions in general. There's no doubt that they're useful. We were
specifically talking about NAN == NAN raising an exception rather than
returning False.
It's arguable that NaN itself simply shouldn't exist in Python; if the FPU
ever generates a NaN, Python
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
, your outgoing 1 is also garbage. Later
on, you can use 'isgarbage(x)' to find out whether anything went
wrong. You can also use 'isinsane(self)', which is defined as follows:
class Programmer:
def isinsane(self):
return True if float(nan)==float(nan) else True
Chris Angelico
--
http
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
for equality is not an
exceptional condition.
NaN itself is an exceptional condition which arises when a result is
undefined or not representable. When an operation normally returns a
number but a specific case cannot do so, it returns not-a-number.
The usual semantics for NaNs are practically identical
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
it can be, then Python should reject IEEE's
obsolete notions, and throw exceptions when operating on NaN.
Python's usefulness for good numeric work is seriously hurt by the fact
that it tries so hard to never generate a NAN, and rarely an INF, and
instead keeps raising annoying exceptions
are far more likely to bite you than the NAN
boogey, that x != x when x is a NAN. But people go into paroxysms of
concern over the violation that they will probably never see, and ignore
the dozens that they trip over day after day.
Compiler optimizations are some of the worst and most egregious
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
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 like producing or operating on something that isn't a
number. When they did
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
.)
You might be able to get away with saying float() merely represents an
abstract floating-point number with provisions for nan and inf, but pretty
much everyone uses IEEE format, so what's the point? And no it doesn't mean
Python has to support every nuance (and it doesn't).
Carl Banks
-1_7040ftnMathSubrs.pdf
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 like
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
(decimal.Decimal('nan'))
True
Ah, apparently someone's been using Larry Wall's time machine. :-)
I should have looked at documentation. In my case, though:
$ python
Python 2.5.1 (r251:54863, Dec 16 2010, 14:12:43)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type help, copyright
math.isnan(fractions.Fraction(2, 3))
False
math.isnan(decimal.Decimal('nan'))
True
Ah, apparently someone's been using Larry Wall's time machine. :-)
He has one too? Just like Guido van Rossum.
I should have looked at documentation. In my case, though:
$ python
Python 2.5.1 (r251
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
2011, Grant Edwards wrote:
Even if they are the same nan, it's still not equal to itself.
if I understand this thread correctly, they are not equal to
itself as specified by IEEE but Python treats them equal in
sets and dictionaries for performance reasons
--
Wolfgang
--
http://mail.python.org
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
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
, and the decision was to leave things as-is.
On Sonntag 29 Mai 2011, Grant Edwards wrote:
Even if they are the same nan, it's still not equal to itself.
if I understand this thread correctly, they are not equal to itself
as specified by IEEE
And Python follows that convention.
but Python
). This was recently discussed on
python-dev, and the decision was to leave things as-is.
On Sonntag 29 Mai 2011, Grant Edwards wrote:
Even if they are the same nan, it's still not equal to itself.
if I understand this thread correctly, they are not equal to itself
as specified by IEEE
And Python
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
701 - 800 of 1188 matches
Mail list logo
