On 5/1/2011 7:27 AM, Nick Coghlan wrote:
However, I did find Terry's suggestion of using the warnings module to
report some of the floating point corner cases that currently silently
produce unexpected results to be an interesting one. If those
operations issued a FloatWarning, then users could
On Sat, Apr 30, 2011 at 3:11 AM, Guido van Rossum wrote:
> Decimal, for that reason, has a context that lets one specify
> different behaviors when a NaN is produced. Would it make sense to add
> a float context that also lets one specify what should happen? That
> could include returning Inf for
[Greg Ewing]
>> Taking a step back from all this, why does Python allow
>> NaNs to arise from computations *at all*?
[Mark Dickinson]
> History, I think. There's a c.l.p. message from Tim Peters somewhere
> saying something along the lines that he'd love to make (e.g.,) 1e300
> * 1e300 raise an e
On Sat, 30 Apr 2011 08:02:33 +0100
Mark Dickinson wrote:
> On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing
> wrote:
> > Taking a step back from all this, why does Python allow
> > NaNs to arise from computations *at all*?
>
> History, I think. There's a c.l.p. message from Tim Peters somewhere
> s
On Fri, Apr 29, 2011 at 2:18 AM, Greg Ewing wrote:
> Taking a step back from all this, why does Python allow
> NaNs to arise from computations *at all*?
History, I think. There's a c.l.p. message from Tim Peters somewhere
saying something along the lines that he'd love to make (e.g.,) 1e300
* 1e
Steven D'Aprano wrote:
If I do x = 0.0/0 I get an exception instead of a NAN.
But the exception you get is ZeroDivisionError, so I think
Python is catching this before you get to the stage of
producing a NaN.
--
Greg
___
Python-Dev mailing list
Pyth
On Fri, Apr 29, 2011 at 11:35, Alexander Belopolsky
wrote:
> On Fri, Apr 29, 2011 at 11:31 AM, Robert Kern wrote:
> ..
>> And in fact, 0.0/0.0 is covered by the more general rule that x/0.0 raises
>> ZeroDivisionError, not a rule that converts IEEE-754 INVALID exceptions into
>> Python exceptions
On Fri, Apr 29, 2011 at 1:11 PM, Guido van Rossum wrote:
> … Would it make sense to add
> a float context that also lets one specify what should happen? That
> could include returning Inf for 1.0/0.0 (for experts), or raising
> exceptions when NaNs are produced (for the numerically naive like
> my
On Fri, Apr 29, 2011 at 12:10 AM, Stephen J. Turnbull
wrote:
> Other aspects of NaN behavior may be a mistake. But it's not clear to
> me, even after all the discussion in this thread.
ISTM that the current behavior of NaN (never mind the identity issue)
helps numeric experts write better code.
On Fri, Apr 29, 2011 at 11:31 AM, Robert Kern wrote:
..
> And in fact, 0.0/0.0 is covered by the more general rule that x/0.0 raises
> ZeroDivisionError, not a rule that converts IEEE-754 INVALID exceptions into
> Python exceptions.
It is unfortunate that official text of IEEE-754 is not freely
a
On 4/29/11 1:35 AM, Nick Coghlan wrote:
On Fri, Apr 29, 2011 at 3:28 PM, Steven D'Aprano wrote:
Robert Kern wrote:
Actually, Python treats all NaNs as quiet NaNs and never signalling NaNs.
Sorry, did I get that backwards? I thought it was signalling NANs that cause
a signal (in Python terms,
Steven D'Aprano writes:
> I'm sorry for my lack of clarity. I'm referring to functions which
> potentially produce NANs, not the exceptions themselves. A calculation
> which might have produced a (quiet) NAN as the result instead raises
> an exception (which I'm treating as equivalent to a signal
Terry Reedy writes:
> > Python treats it as if it were a number:
>
> As I said, so did the committee, and that was its mistake that we are
> more or less stuck with.
The committee didn't really have a choice. You could ask that they
call NaNs something else, but some bit pattern is going t
Ben Finney wrote:
Steven D'Aprano writes:
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps
anyone.
Actually, Python treats all NaNs as quiet NaNs and
On Fri, Apr 29, 2011 at 3:28 PM, Steven D'Aprano wrote:
> Robert Kern wrote:
>> Actually, Python treats all NaNs as quiet NaNs and never signalling NaNs.
>
> Sorry, did I get that backwards? I thought it was signalling NANs that cause
> a signal (in Python terms, an exception)?
>
> If I do x = 0.0
Steven D'Aprano writes:
> Robert Kern wrote:
> > On 4/28/11 8:44 PM, Steven D'Aprano wrote:
> >> The real question should be, why does Python treat all NANs as
> >> signalling NANs instead of quiet NANs? I don't believe this helps
> >> anyone.
> >
> > Actually, Python treats all NaNs as quiet NaN
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs
instead of quiet NANs? I don't bel
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as signalling NANs
instead of quiet NANs? I don't believe this helps anyone
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps anyone.
+Inf and -Inf are arguably useful elem
On Fri, Apr 29, 2011 at 11:11 AM, Ben Finney wrote:
> Would it make sense for ‘NaN’ to be another instance of ‘NoneType’?
This is fine IHMO as I (personally) find myself doing things like:
if x is None:
...
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
_
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
+Inf and -Inf are arguably useful elements of the algebra,
yet Python insists on raising an exception for 1.0./0.0
instead of returning an infinity.
Why do this but not raise an exception for any op
Terry Reedy writes:
> On 4/28/2011 4:40 AM, Mark Shannon wrote:
> > NaN does not have to be a float or a Decimal.
> > Perhaps it should have its own class.
>
> Like None
Would it make sense for ‘NaN’ to be another instance of ‘NoneType’?
--
\ “I am too firm in my consciousness of the mar
Terry Reedy wrote:
I think the committee goofed -- badly. Statisticians used missing value
indicators long before the committee existed. They has no problem
thinking that the indicator, as an object, equaled itself. So one could
write (and I often did through the 1980s) the equivalent of
for
On 4/28/2011 4:40 AM, Mark Shannon wrote:
NaN is *not* a number (the clue is in the name).
The problem is that the committee itself did not believe or stay
consistent with that. In the text of the draft, they apparently refer to
Nan as an indefinite, unspecified *number*. Sort of like a rand
Mark Shannon wrote:
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few
things that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than
types and values so may not be entirely appr
On 28/04/2011 15:58, Steven D'Aprano wrote:
Fundamentally, the problem is that some containers bypass equality
tests for identity tests. There may be good reasons for that shortcut,
but it leads to problems with *any* object that does not define
equality to be reflexive, not just NANs.
I say y
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-leve
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-level language
like Python.
On Thu, Apr 28, 2011 at 7:17 PM, Greg Ewing wrote:
> Mark Shannon wrote:
>
>> NaN does not have to be a float or a Decimal.
>> Perhaps it should have its own class.
>
> Perhaps, but that wouldn't solve anything on its own. If
> this new class compares reflexively, then it still violates
> IEE754.
Mark Shannon wrote:
NaN does not have to be a float or a Decimal.
Perhaps it should have its own class.
Perhaps, but that wouldn't solve anything on its own. If
this new class compares reflexively, then it still violates
IEE754. Conversely, existing NaNs could be made to compare
reflexively wi
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-level language
like Python.
NaN is *not* a numb
31 matches
Mail list logo
