[Python-Dev] VAX NaN evaluations
Hi,
The nice Python folks who were at SCALE in Los Angeles last year gave me a
Python t-shirt for showing Python working on m68k and for suggesting that
I'd get it working on VAX. With libffi support for VAX from Miod Vallat,
this is now possible.
However, when compiling Python, it seems that attempts to evaluate NaN are
made in test_complex.py, test_complex_args.py, test_float.py and
test_math.py (at least in 2.7.5 - I'm working on compiling 3.3.2 now).
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. While code which depends on the ability to
evaluate NaNs in some meaninful way will likely break on VAXen, I think
this is better than raising an exception.
Being completely new to Python, I'm not sure what's best to do here. What
would be the best way to find code which handles evaluation of "NaN"? Does
anyone have any recommendations?
Thanks,
John Klos
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
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
right?
Thanks,
John
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VAX NaN evaluations
I'm sorry to hear that - you might have been wasting your time (but
then, perhaps not).
We decided a while ago that the regular Python releases will not support
VAX/VMS any longer. So any code you write has zero chance of being
integrated into Python (the same holds for m68k code, BTW).
That said, you are free to maintain your own branch of Python. In that
branch, you can make whatever changes you consider necessary, but you
will be on your own.
Oh, it's definitely not wasting time. I seriously doubt I'd be asking
Python people to maintain patches upstream, because I seriously doubt we'd
have any to maintain - this is for NetBSD/VAX, not VMS. Running NetBSD on
VAX points out many instances where programmers make assumptions, so
everyone is helped when we address those assumptions.
From Steven D'Aprano:
Just to be clear, rather than dump core (which you suggested in a later
email), if you cannot support NANs on VAXen, you should modify float to
raise a ValueError exception. Pure Python code like float('nan') should
never dump core, it should raise:
ValueError: could not convert string to float: 'nan'
What Steven recommends makes a lot of sense, and if the Python folks don't
think it's worth adding a few lines to make NaN assignments optionally
raise an exception, we can keep the patches in NetBSD's pkgsrc.
So the next time I have a little time, I'll look through the code and see
if I can't find where that would be. And while I'm at it, I'll try to
learn a little Python ;)
Thanks,
John
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
