[Python-Dev] VAX NaN evaluations

John Klos john at ziaspace.com
Mon Nov 4 23:28:09 CET 2013

>> The short answer is to skip those tests on VAXen. The better answer is to
>> patch any isnan functions to always return false on VAXen and patch any code
>> which tries to parse, for instance, float("NaN") to use something uncommon,
>> such as the largest representable number (const union __double_u __infinity
>> = { { 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff } };) or something else
>> equally rare.
> I think you are asking for trouble here.  As VAX floating point does
> not appear to have hardware support for NaN, attempts to "emulate"
> such could be potentially dangerous.  If such software were running
> life-support systems, for example, your decision to emulate it would
> put you at fault for criminal negligence, whereas a failure simply due
> to lack of implementation would be more benign incompetence.  Probably
> better for an exception to be thrown or other hard error.

We'd have to have one uncommor and two extremely unlikely events all 
happen simultaneously for your example to be of concern:

One, someone would have to care that NaN representations are done using an 
arbitrary value rather than an actual NaN representation in IEEE 754. I 
can imagine instances where this could cause an issue, but people who 
write proper math code would tend to write correct code anyway.

Two, someone would have to decide to use Python with NaN testing / 
comparison code to run some sort of life-support system. I can't imagine 
anyone who isn't already horribly incompetent doing anything like this.

Three, that someone would have to want to run that code and that 
life-support system on a VAX (or other system which doesn't handle NaNs.

While you make a point worth making, nobody is ever going to be at fault 
for criminal negligence for having implementation side-cases. If that were 
even possible, open source software would be litigated out of existence 
and everyone would be suing Microsoft for their monumental failures.

So you indirectly say that you think it'd be best to just skip the tests 
and leave it so tha any attempts to handle NaNs would dump core. Is that 


More information about the Python-Dev mailing list