Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6947

Re: float("nan") in set or as key

Show all headers | View raw

On 2011-06-02, Nobody <nobody@nowhere.com> wrote:
> On Thu, 02 Jun 2011 09:54:30 +0000, 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 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 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 the current NaN behavior very useful, and
labor-saving.

> But given that NaNs propagate in almost the same manner as
> exceptions, you could "optimise" this by treating a NaN as a
> special-case implementation of exceptions, and turn it into a real
> exception at the point where you can no longer use a NaN (e.g. when
> using a comparison operator).
>
> 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 they are there,
it provides an easy to read and easy to maintain way to handle things.

> I mean undefined, in the sense that 0/0 is undefined

But 0.0/0.0 _is_ defined.  It's NaN.  ;)

> (I note that Python actually raises an exception for "0.0/0.0").

IMHO, that's a bug.  IEEE-754 states explicit that 0.0/0.0 is NaN.
Pythons claims it implements IEEE-754.  Python got it wrong.

> Also, note that the "convenience" of NaN (e.g. not propagating from
> the untaken branch of a conditional) is only available for
> floating-point types. If it's such a good idea, why don't we have it
> for other types?

> 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
right/left side of the road is entire arbitrary, but once decided
there's a huge benefit to everybody following the rule.

> You could just as easily define that (NaN == NaN) is True. You could
> just as easily define that "1 + NaN" is 27.

I don't think that would be "just as easy" to use.

> Actually, "NaN == NaN" makes more sense than "NaN != NaN", as the
> former upholds the equivalence axioms

You seem to be talking about reals.  We're talking about floats.

> If you're going to argue that "NaN == NaN" should be False on the
> basis that the values are sentinels for unrepresentable values (which
> may be *different* unrepresentable values), it follows that "NaN !=
> NaN" should also be False for the same reason.

Mostly I just want Python to follow the IEEE-754 standard [which I
happen to find to be very well thought out and almost always behaves
in a practical, useful manner].

> If you want to argue that "NaN == NaN" should be False, then do so.
> Simply asserting that it should be False won't suffice (nor will
> citing the IEEE FP standard *unless* you're arguing that "because the
> standard says so" is the only reason required).

For those of us who have to accomplish real work and interface with
real devices "because the standard says so" is actaully a darned good
reason.  Years of experience has also shown to me that it's a very
practical decision.

> If anything, it has proven to be a major nuisance. It takes a lot of
> effort to create (or even specify) code which does the right thing in
> the presence of NaNs.

That's not been my experience.  NaNs save a _huge_ amount of effort
compared to having to pass value+status info around throughout complex
caclulations.

> I'm not aware that they made any conclusions about Python.

They made some very informed (and IMO valid) conclusions about
scientific computing using binary floating point arithmatic.  Those
conclusions apply largly to Python.

-- 
Grant

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

float("nan") in set or as key MRAB <python@mrabarnett.plus.com> - 2011-05-29 00:41 +0100
  Re: float("nan") in set or as key Erik Max Francis <max@alcyone.com> - 2011-05-28 17:16 -0700
  Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-29 00:26 +0000
  Re: float("nan") in set or as key Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-29 13:04 +1200
    Re: float("nan") in set or as key John Nagle <nagle@animats.com> - 2011-05-28 23:12 -0700
      Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-29 10:29 +0000
        Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-05-29 22:19 +0100
          Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-29 23:31 +0000
            Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-06-01 21:41 +0100
              Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-02 09:54 +0000
                Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-02 13:05 +0000
                Re: float("nan") in set or as key Robert Kern <robert.kern@gmail.com> - 2011-06-02 12:04 -0500
                Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-06-02 21:47 +0100
                Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-03 14:52 +0000
                Re: float("nan") in set or as key Chris Torek <nospam@torek.net> - 2011-06-03 17:52 +0000
                Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-06 13:54 +0000
                Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-06-04 00:29 +0100
                Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-04 09:51 +1000
                Re: float("nan") in set or as key rusi <rustompmody@gmail.com> - 2011-06-04 00:52 -0700
                Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-06-04 20:29 +0100
                Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-05 07:21 +0000
                Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-06-05 19:15 +0100
                Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-06 00:55 +0000
                Re: float("nan") in set or as key Nobody <nobody@nowhere.com> - 2011-06-06 23:14 +0100
                Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-06 23:44 +0000
                Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-07 11:00 +1000
                Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-06 14:03 +0000
                Re: float("nan") in set or as key Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-06-03 11:17 +1200
                Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-03 04:23 +0000
                Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-03 14:35 +1000
                Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-03 05:59 +0000
                Re: float("nan") in set or as key Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-06-04 12:14 +1200
                Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-04 02:21 +0000
                Re: float("nan") in set or as key Erik Max Francis <max@alcyone.com> - 2011-06-05 00:27 -0700
          Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-01 21:01 +0000
      Re: float("nan") in set or as key Chris Torek <nospam@torek.net> - 2011-05-30 00:02 +0000
  Re: float("nan") in set or as key Raymond Hettinger <python@rcn.com> - 2011-05-29 21:49 -0700

csiph-web