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
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.
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
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
14 matches
Mail list logo
