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
