Changes by Guido van Rossum gu...@python.org:
--
nosy: -gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23229
___
___
Python-bugs-list
Guido van Rossum added the comment:
Should inf and nan be added to cmath too? It has e and pi and isnan() and
isinf()...
Also complex(0, math.nan) a value that is printed as nanj and complex(nanj)
parses and returns such a value, so the point could be made that there should
be a constant
Mark Dickinson added the comment:
Committed. Thanks for all the helpful review comments!
--
resolution: - fixed
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
Roundup Robot added the comment:
New changeset cf4bf577749c by Mark Dickinson in branch 'default':
Issue #23185: add math.inf and math.nan constants.
https://hg.python.org/cpython/rev/cf4bf577749c
--
nosy: +python-dev
___
Python tracker
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +eric.smith, lemburg, rhettinger, stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
___
STINNER Victor added the comment:
2015-01-09 8:16 GMT+01:00 Serhiy Storchaka rep...@bugs.python.org:
May be make math.inf and math.nan special objects so that for all x (except
inf and nan):
What do you mean? Implement a subtype of float and override some methods?
x math.inf
x -math.inf
On Thu, Jan 8, 2015 at 7:07 PM, Chris Angelico ros...@gmail.com wrote:
On Fri, Jan 9, 2015 at 12:46 PM, Steven D'Aprano
The fallback rule I use when float('nan') fails is
INF = 1e3000 # Hopefully, this should overflow to INF.
NAN = INF-INF # And this hopefully will give a NaN
On Fri, Jan 9, 2015 at 1:12 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
Or to never have to worry about it:
INF = 1e400
while not math.isinf(INF):
INF *= INF
With no imports whatsoever:
inf = 1e400
nan = inf-inf
while nan == nan:
inf *= inf
nan = inf-inf
But now we're getting
Chris Angelico wrote:
On Fri, Jan 9, 2015 at 1:50 AM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
0*1e400
nan
Nice, that's shorter than mine.
o_O
Is that really the sort of thing you should be revealing here?
Oh wait, you're talking about code...
I'm not entirely sure
Serhiy Storchaka added the comment:
May be make math.inf and math.nan special objects so that for all x (except inf
and nan):
x math.inf
x -math.inf
not (x math.nan)
not (x math.nan)
--
___
Python tracker rep...@bugs.python.org
http
On Fri, Jan 9, 2015 at 12:46 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Chris Angelico wrote:
On Fri, Jan 9, 2015 at 1:50 AM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
0*1e400
nan
Nice, that's shorter than mine.
I'm not entirely sure, but I suspect
STINNER Victor added the comment:
Except of my small suggestion on the doc (see the review), math_inf_nan4.patch
looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
___
Mark Dickinson added the comment:
I have an updated patch taking into account the most recent review comments
(for which thanks!), but it's at home; I'll upload it this evening (UTC+00:00).
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson added the comment:
New patch, addressing review comments.
--
Added file: http://bugs.python.org/file37647/math_inf_nan4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
I'm running some pandas examples and I canno find in what module NaN is
defined. Does anyone know what module I have to import in order to have
it defined?
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Jan 9, 2015 at 1:15 AM, maurog qualsivog...@dovetipare.nz wrote:
I'm running some pandas examples and I canno find in what module NaN is
defined. Does anyone know what module I have to import in order to have
it defined?
It's simply float(nan). If you want a name, you can give it one
Chris Angelico writes:
On Fri, Jan 9, 2015 at 1:37 AM, Marko Rauhamaa wrote:
True, but that got me thinking: what standard Python math
operation evaluates to NaN?
Subtracting infinity from infinity is one easy way.
1e309
inf
1e309-1e309
nan
I managed to get inf by arithmetic
On Thu, Jan 8, 2015 at 7:15 AM, maurog qualsivog...@dovetipare.nz wrote:
I'm running some pandas examples and I canno find in what module NaN is
defined. Does anyone know what module I have to import in order to have
it defined?
It's not defined anywhere. To get nan as a literal just do
Ian Kelly ian.g.ke...@gmail.com:
To get nan as a literal just do:
nan = float(nan)
True, but that got me thinking: what standard Python math operation
evaluates to NaN?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Jan 9, 2015 at 1:37 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
To get nan as a literal just do:
nan = float(nan)
True, but that got me thinking: what standard Python math operation
evaluates to NaN?
Subtracting infinity from infinity is one
Marko Rauhamaa writes:
Ian Kelly:
To get nan as a literal just do:
nan = float(nan)
True, but that got me thinking: what standard Python math operation
evaluates to NaN?
All manner of arithmetics gives overflow errors (Numerical result out
of range) but a literal with a large
On Fri, Jan 9, 2015 at 1:50 AM, Jussi Piitulainen
jpiit...@ling.helsinki.fi wrote:
0*1e400
nan
Nice, that's shorter than mine.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Mark Dickinson added the comment:
One more patch, fixing a misplaced period.
--
Added file: http://bugs.python.org/file37635/math_inf_nan3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
STINNER Victor added the comment:
History, perhaps? In any case, the sign of a NaN isn't useful information in
the same way that the sign of an infinity is. The IEEE 754 standard explicitly
refuses to attach any meaning to the sign bit of a NaN. And if we were aiming
for a full
Changes by Berker Peksag berker.pek...@gmail.com:
--
components: +Library (Lib)
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
___
Mark Dickinson added the comment:
Sounds good to me.
Do we add a math.neginf
IMO no: -inf should be fine.
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
___
Mark Dickinson added the comment:
float(-inf) and -float(inf) have exactly the same IEEE 754 representation
Indeed: there's only one negative infinity (and only one positive infinity) in
IEEE 754 binary64 format.
--
___
Python tracker
Mark Dickinson added the comment:
Implementation suggestion: if possible, use the _Py_dg_stdnan and
_Py_dg_infinity functions from Python/dtoa.c. These are a little safer than
the Py_NAN and Py_HUGE_VAL macros, and will give results consistent with the
float(inf) and float(nan) constructions
New submission from Ethan Furman:
Proposal:
math.nan = float('nan')
math.inf = float('inf')
Guido's approval:
https://mail.python.org/pipermail/python-ideas/2015-January/030775.html
Followup question:
Do we add a math.neginf, or somesuch, for float('-inf')? Or just use
-math.inf
STINNER Victor added the comment:
Do we add a math.neginf, or somesuch, for float('-inf')? Or just use
-math.inf?
I would prefer to only add inf.
It looks like float(-inf) and -float(inf) have exactly the same IEEE 754
representation (at least on my x86_64 CPU):
struct.pack(d,
Mark Dickinson added the comment:
Why does Python return the same representation for positive and negative NaN?
History, perhaps? In any case, the sign of a NaN isn't useful information in
the same way that the sign of an infinity is. The IEEE 754 standard explicitly
refuses to attach any
Serhiy Storchaka added the comment:
There are several different NaNs.
x = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf8\x7f')[0]
x
nan
x == x
False
struct.pack('d', x)
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'
x = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf9\x7f')[0]
x
nan
x == x
Mark Dickinson added the comment:
but 0*inf and inf-inf return values with the same representation as
float('-nan'), not float('nan')
Right: that's because Intel's default NaN (i.e., the float it produces as a
result of any invalid operation) has its sign bit set
Mark Dickinson added the comment:
By tweaking the grammar we can have math.-inf.
RRGH!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
___
Antoine Pitrou added the comment:
By tweaking the grammar we can have math.-inf.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
___
Mark Dickinson added the comment:
Here's a patch.
--
assignee: - mark.dickinson
keywords: +patch
Added file: http://bugs.python.org/file37633/math_inf_nan.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23185
Mark Dickinson added the comment:
Thanks for the review comments. Here's an updated patch taking the review
comments into account (and fixing the spelling of PY_NAN, which should have
been Py_NAN).
--
Added file: http://bugs.python.org/file37634/math_inf_nan2.patch
STINNER Victor added the comment:
Oh, NaN can be signed?
struct.pack(d, float(nan))
b'\x00\x00\x00\x00\x00\x00\xf8\x7f'
struct.pack(d, float(-nan))
b'\x00\x00\x00\x00\x00\x00\xf8\xff'
struct.pack(d, -float(nan))
b'\x00\x00\x00\x00\x00\x00\xf8\xff'
struct.pack(d, -float(-nan))
b'\x00\x00\x00
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22951
___
___
Python-bugs-list
Terry J. Reedy added the comment:
Enhancements are only possible in 3.5 or beyond. I agree with Mark. There is
no compelling reason to break code with this change. Hence it should be
rejected.
Float is an odd duck. All ints and all non-recursive lists, for instance, have
a literal
Mark Dickinson added the comment:
Previously discussed here: http://bugs.python.org/issue1732212
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22951
___
Mark Dickinson added the comment:
A couple of points against this change:
1. If repr(float('inf')) became float('inf'), we'd lose the invariant that
float(repr(x)) recovers x for all floats (including infinities and nans).
2. Since repr and str are currently identical for floats, this change
Serhiy Storchaka added the comment:
Workaround:
eval('inf', {'inf': float('inf')})
inf
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22951
___
New submission from jaebae17:
The help page for the built-in repr() states ''' For many types, this function
makes an attempt to return a string that would yield an object with the same
value when passed to eval()...'''
This holds true for non-inf/nan values of float():
eval(repr(float('0.0
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22951
___
___
Python-bugs-list
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list
Mark Dickinson added the comment:
Antoine: is it okay to close this as wont fix?
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22590
___
Antoine Pitrou added the comment:
Yep, it's ok.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22590
___
___
Python-bugs-list mailing list
Changes by Mark Dickinson dicki...@gmail.com:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22590
___
New submission from Antoine Pitrou:
Z:\c:\Python27\python.exe
Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import math
math.copysign(0.0, float(nan))
-0.0
^Z
Z:\c:\Python34\python.exe
Mark Dickinson added the comment:
Why do you consider this a bug?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22590
___
___
Python-bugs-list
Mark Dickinson added the comment:
More info: the reason for the difference is that in Python 3.4, float(nan)
and float(inf) create the float directly from the appropriate bit-pattern,
rather than deferring to the platform's definition of nan. This change was
introduced to avoid obscure
Antoine Pitrou added the comment:
Ah, apparently it was already reported as issue14521...
Well, it's bug in as much as it shows different behaviour across platforms...
AFAICT, we try to provide consistent math behaviour despite possible platform
variations.
--
Antoine Pitrou added the comment:
Also, the fact that we support float('nan') and float('-nan') as producing
different bit patterns means we should perhaps produce the right sign bit for
each (it seems that's the problem here).
import struct
struct.pack(d, float(nan))
'\x00\x00\x00\x00\x00
Mark Dickinson added the comment:
we should perhaps produce the right sign bit for each
Perhaps. But given that signs of NaNs are pretty much meaningless anyway (the
IEEE 754 standard explicitly refuses to attach any meaning to NaN sign bits,
and the sign bit of a NaN result
Antoine Pitrou added the comment:
Yes, things are ok under 3.x. We'll probably disable our NaN tests under
Windows anyway, since they aren't very useful as you point out.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22590
and nan. However, I have a feeling an exception would be
a sounder response whenever the arithmetics leaves the solid ground.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Sep 17, 2014 at 3:37 PM, Chris Angelico ros...@gmail.com wrote:
It's not something I've personally worked with, so I'm trying to
dredge stuff up from my brain, but I think there's something along the
lines of stuff shouldn't be a multiple of everything and the Prime
Number Theorem. But
On Thursday, September 18, 2014 6:12:08 AM UTC+3, Steven D'Aprano wrote:
cool-RR wrote:
Chris, why is this invariant `div*y + mod == x` so important? Maybe it's
more important to return a mathematically reasonable result for the the
floor-division result than to maintain this invariant?
Marko Rauhamaa wrote:
Maybe IEEE had some specific numeric algorithms in mind when it
introduced inf and nan. However, I have a feeling an exception would be
a sounder response whenever the arithmetics leaves the solid ground.
I'm afraid that you're missing the essential point of INF
On 2014-09-18, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Marko Rauhamaa wrote:
Maybe IEEE had some specific numeric algorithms in mind when it
introduced inf and nan. However, I have a feeling an exception would be
a sounder response whenever the arithmetics leaves the solid
implementation of the underlying C lib -- it's gotten better over the years
(Inf and NaN used to be really hard to get), but still not quite what it could
be.
-Chris
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Sep 18, 2014 at 10:35 AM, chris.bar...@noaa.gov wrote:
It's be nice if Python's math module did more than simply wrap the default i
implementation of the underlying C lib -- it's gotten better over the years
(Inf and NaN used to be really hard to get), but still not quite what
Terry, that doesn't really answer the question why, it just pushes it back to
the documentation. Is there a real answer why? Why return NaN when Inf would
make mathematical sense?
On Wednesday, September 17, 2014 4:13:38 AM UTC+3, Terry Reedy wrote:
On 9/16/2014 5:40 PM, cool-RR wrote
On Thu, Sep 18, 2014 at 12:55 AM, cool-RR ram.rac...@gmail.com wrote:
Terry, that doesn't really answer the question why, it just pushes it back
to the documentation. Is there a real answer why? Why return NaN when Inf
would make mathematical sense?
To answer that, we have to first look
On Wednesday, September 17, 2014 6:10:35 PM UTC+3, Chris Angelico wrote:
On Thu, Sep 18, 2014 at 12:55 AM, cool-RR ram.rac...@gmail.com wrote:
Terry, that doesn't really answer the question why, it just pushes it
back to the documentation. Is there a real answer why? Why return NaN when
On Thu, Sep 18, 2014 at 1:16 AM, cool-RR ram.rac...@gmail.com wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking about
the floor division.
Invariant: div*y + mod == x.
If mod is NaN, there is no possible value for div that will make the
invariant true, ergo it too
On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico ros...@gmail.com wrote:
On Thu, Sep 18, 2014 at 1:16 AM, cool-RR ram.rac...@gmail.com wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking about
the floor division.
Invariant: div*y + mod == x.
If mod is NaN
'))
OverflowError: cannot convert float infinity to integer
and hence
float('inf') // 1.0
nan
In C, floor(INFINITY) returns infinity (at least in the implementation
I just tested).
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Sep 18, 2014 at 1:34 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico ros...@gmail.com wrote:
On Thu, Sep 18, 2014 at 1:16 AM, cool-RR ram.rac...@gmail.com wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking
about
ask for the modulo, I agree it should remain NaN. I'm talking
about the floor division.
Invariant: div*y + mod == x.
If mod is NaN, there is no possible value for div that will make the
invariant true, ergo it too has to be NaN.
That still doesn't make the invariant true. By this argument
ask for the modulo, I agree it should remain NaN. I'm talking
about the floor division.
Invariant: div*y + mod == x.
If mod is NaN, there is no possible value for div that will make the
invariant true, ergo it too has to be NaN.
That still doesn't make the invariant true. By this argument
On Wednesday, September 17, 2014 6:30:04 PM UTC+3, Chris Angelico wrote:
On Thu, Sep 18, 2014 at 1:16 AM, cool-RR ram.rac...@gmail.com wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking
about the floor division.
Invariant: div*y + mod == x.
If mod is NaN
On Thu, Sep 18, 2014 at 2:33 AM, cool-RR ram.rac...@gmail.com wrote:
On Wednesday, September 17, 2014 6:30:04 PM UTC+3, Chris Angelico wrote:
On Thu, Sep 18, 2014 at 1:16 AM, cool-RR ram.rac...@gmail.com wrote:
I didn't ask for the modulo, I agree it should remain NaN. I'm talking
about
On Wed, Sep 17, 2014 at 9:10 AM, Chris Angelico ros...@gmail.com wrote:
And while it's
conceivable to define that infinity divided by anything is infinity,
and infinity modulo anything is zero, that raises serious issues of
primality and such; I'm not sure that that would really help anything.
On Thu, Sep 18, 2014 at 4:03 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Sep 17, 2014 at 9:10 AM, Chris Angelico ros...@gmail.com wrote:
And while it's
conceivable to define that infinity divided by anything is infinity,
and infinity modulo anything is zero, that raises serious issues
On 9/17/2014 10:55 AM, cool-RR wrote:
Terry, that doesn't really answer the question why, it just pushes
it back to the documentation. Is there a real answer why? Why return
NaN when Inf would make mathematical sense?
IEEE float('inf') and float('nan') are engineering, not math constructs.
I
Chris Angelico wrote:
On Thu, Sep 18, 2014 at 1:34 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Sep 17, 2014 at 9:29 AM, Chris Angelico ros...@gmail.com wrote:
Invariant: div*y + mod == x.
If mod is NaN, there is no possible value for div that will make the
invariant true, ergo
], the result of floor(∞)
isn't clear to me. Floor is supposed to return an integer, how do you know
that ∞ is integer valued? You can do ∞ % 1 to see what the fractional part
is, but that gives NaN, so justify your belief that ∞ is integer-valued.
[1] But *which* mathematical infinity? One
Chris Angelico wrote:
On Thu, Sep 18, 2014 at 4:03 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Sep 17, 2014 at 9:10 AM, Chris Angelico ros...@gmail.com wrote:
And while it's
conceivable to define that infinity divided by anything is infinity,
and infinity modulo anything is zero, that
On Thu, Sep 18, 2014 at 1:29 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Perhaps you are thinking of the Fundamental Theorem of Arithmetic, which
states that every positive integer except 1 can be uniquely factorized into
a product of one or more primes?
While debugging my code I found that the bug was because I assumed that
something like `divmod(float('inf'), 1)` would be equal to `(float('inf'),
float('nan'))`, while Python returns `(float('nan'), float('nan'))`. Why does
Python make the division result be NaN in this case? `float('inf') / 1
On 9/16/2014 5:40 PM, cool-RR wrote:
While debugging my code I found that the bug was because I assumed
that something like `divmod(float('inf'), 1)` would be equal to
`(float('inf'), float('nan'))`, while Python returns `(float('nan'),
float('nan'))`. Why does Python make the division result
Changes by Mark Dickinson dicki...@gmail.com:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22238
___
Mark Dickinson added the comment:
I agreed with Raymond.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22238
___
___
Python-bugs-list mailing
fractions.gcd(16, float('nan'))
Traceback (most recent call last):
File pyshell#2, line 1, in module
fractions.gcd(16, float('nan'))
File C:\Python34-32bit\lib\fractions.py, line 24, in gcd
a, b = b, a%b
KeyboardInterrupt
With the iterative algorithm that is used
a, b = b, a%b
b
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +mark.dickinson, rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22238
___
___
Raymond Hettinger added the comment:
I don't think this is an actual problem in practice and isn't worth mucking up
clear and beautiful code.
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22238
Raymond Hettinger added the comment:
Also note that the fractions module is primarily about rational numbers
(integer ratios). The int type has no concept of NaNs and Infs, so I don't see
any reason why the fractions module should cater to them.
--
Raymond Hettinger added the comment:
Closing for the reasons listed and also because there is another pair of
tracker items 22000 and 22001 pursuing related documentation updates.
--
resolution: - not a bug
status: open - closed
___
Python tracker
owed, and the amount they paid so far.
nan = float(nan)
borrowers = [Alice, Bob, Clem, Dan] amount_owed = [100.0,
nan, 200.0, 300.0] amount_paid = [100.0, nan, nan, 200.0]
who_paid_off = [b for (b, ao, ap) in
zip(borrowers, amount_owed, amount_paid
them ought to be finite, but there's no way to tell what
it should be.
Huh, okay. I thought the definition of NaN was based on the fourth one
(mathematically indeterminate) and then it logically accepted the
subsequent two (sqrt(-1) IMO is better handled by either a complex
number or a thrown
Anders J. Munch 2...@jmunch.dk writes:
So far I received exactly the answer I was expecting. 0 examples of
NaN!=NaN being beneficial.
I wasn't asking for help, I was making a point. Whether that will
lead to improvement of Python, well, I'm not too optimistic, but I
feel the point was worth
On Fri, Jul 18, 2014 at 1:12 AM, Johann Hibschman jhibsch...@gmail.com wrote:
Well, I just spotted this thread. An easy example is, well, pretty much
any case where SQL NULL would be useful. Say I have lists of borrowers,
the amount owed, and the amount they paid so far.
nan = float(nan
Chris Angelico ros...@gmail.com writes:
But you also don't know that he hasn't. NaN doesn't mean unknown, it
means Not a Number. You need a more sophisticated system that allows
for uncertainty in your data.
Regardless of whether this is the right design, it's still an example of
use
On Fri, Jul 18, 2014 at 4:49 AM, Johann Hibschman jhibsch...@gmail.com wrote:
Chris Angelico ros...@gmail.com writes:
But you also don't know that he hasn't. NaN doesn't mean unknown, it
means Not a Number. You need a more sophisticated system that allows
for uncertainty in your data
On Fri, Jul 18, 2014 at 4:49 AM, Johann Hibschman jhibsch...@gmail.com wrote:
In
principle, (NA == 1.0) should be a NA (missing) truth value, as should
(NA == NA), but in practice having it be False is more useful.
This is actually fairly easily implemented, if you ever want it.
class NAType:
Chris Angelico ros...@gmail.com:
numerical calculations might overflow to +inf or -inf, and then
further calculations can result in a nan, etc, etc. Those are the
sorts of examples that you'd find among SciPy users and such.
There is some inconsistency.
Mathematically, there are undefined
the limits being
ambiguous. Also, 1/0 in IEEE 754 is defined as inf.
Why 0/0 results in an exception but inf-inf = nan, I don't see a
justification.
I expect that float division by zero was made to raise an exception
for consistency with integer division by zero, where it might be
considered
Ian Kelly ian.g.ke...@gmail.com:
Well, 0**0 is usually defined as 1, despite the limits being
ambiguous.
URL: https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml
But if it could be defined, what should it be? 0 or 1?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
401 - 500 of 1188 matches
Mail list logo
