On Mon, Jun 6, 2011 at 2:59 PM, Steven D'Aprano <steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list
