[Python-Dev] VAX NaN evaluations

Mark Janssen dreamingforward at gmail.com
Mon Nov 4 23:45:03 CET 2013


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

Understood.  But when things run millions of times a second,
"extremely unlikely" things can happen more often that you wanted.

> 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.

People incorporate third-party software, often unknowingly, trusting
the process and "system" even though it is almost always *completely*
informal and simply a community of good-hearted individuals.

> 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.

You *could* be right.  I'm just saying what would be safe, legally and
morally speaking.

> If that were even
> possible, open source software would be litigated out of existence and
> everyone would be suing Microsoft for their monumental failures.

End-to-end open source software doesn't (generally) make any
guarantees ("without warrantees of any kind"), so there's little basis
to sue.   As for MSFT, people have been suing Microsoft.  Apparently,
they have good lawyers, and people are smart enough not to use their
software too much in mission-critical applications (although
apparently this has changed over the years).

> 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 right?

That keeps your hands most safe, but again, I suggest you research the
IEEE standard to see if there's already a standard for VAX rather than
spinning your own home-brewed version, or join the IEEE committee and
make one.
-- 
MarkJ
Tacoma, Washington


More information about the Python-Dev mailing list