float("nan") in set or as key

[Chris Angelico]

On Mon, Jun 6, 2011 at 2:59 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Mon, 06 Jun 2011 14:11:03 +1000, Chris Angelico wrote:
>> So does this mean that:
>> (with signalling NANs) should trap on the second line but not the first?

BTW, by "should" I meant "would if Python's float were 100% IEEE-754 compliant".

> I don't think that there's any way to tell IEEE-754 for operations on
> NANs to return signalling NANs. As I understand it, the idea is:
>
>
> - if you want exceptions to signal, set the appropriate traps;
> - if you want NANs that propagate through your calculation, clear 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 it.

That makes plausible sense, at least. Get traps or propagate NANs.

> I'm lead to believe that signalling NANs were added to satisfy politics,
> but apart from being slightly useful for marking uninitialised memory
> before use, nobody actually uses them in practice.

I'm curious as to what sort of politics led to that.

> Wanna see something cool? You can check for inexact arithmetic:
> Not surprisingly, by default that's turned off :)

Neat. That's going to be off trapping pretty much all the time, but I
can imagine circumstances where you check the status at the end.

ChrisA