Re: PPC floating equality vs. byte compilation
Terry Reedy [EMAIL PROTECTED] writes: Tim Peters [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [Donn Cave] I ran into a phenomenon that seemed odd to me, while testing a build of Python 2.4.1 on BeOS 5.04, on PowerPC 603e. test_builtin.py, for example, fails a couple of tests with errors claiming that apparently identical floating point values aren't equal. But it only does that when imported, and only when the .pyc file already exists. Not if I execute it directly (python test_builtin.py), or if I delete the .pyc file before importing it and running test_main(). This is a known problem with marshalling INFs and/or NANs. I hope you've also read all the bits and pieces where Tim says whatever happens to INFs and NANs is a platform dependent crapshoot. We don't test platform dependent crapshoots in test_builtin (or at least, I hope not!). *This* has supposedly been fixed for 2.5. Actually, it's likely that Donn's failure has been fixed for Python 2.5 as well, at least if Tim's guess is correct, because the C string-float routines aren't invovled in loading .pycs any more. It would be most helpful to open a bug report, with the output from failing tests. And assign to Tim. That's mean! :) In general, this can happen if the platform C string-float routines are so poor that eval(repr(x)) != x ... The ultimate cause is most likely in the platform C library's string-float routines (sprintf, strtod, that kind of thing). It would also be helpful if you could do some tests in plain C (no Python) testing, for instance, the same values that failed. Hardly anyone else can ;-). If you confirm a problem with the C library, you can close the report after opening, leaving it as a note for anyone else working with that platform. I agree with this bit! Cheers, mwh -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html -- http://mail.python.org/mailman/listinfo/python-list
PPC floating equality vs. byte compilation
I ran into a phenomenon that seemed odd to me, while testing a build of Python 2.4.1 on BeOS 5.04, on PowerPC 603e. test_builtin.py, for example, fails a couple of tests with errors claiming that apparently identical floating point values aren't equal. But it only does that when imported, and only when the .pyc file already exists. Not if I execute it directly (python test_builtin.py), or if I delete the .pyc file before importing it and running test_main(). For now, I'm going to just write this off as a flaky build. I would be surprised if 5 people in the world care, and I'm certainly not one of them. I just thought someone might find it interesting. The stalwart few who still use BeOS are mostly using Intel x86 hardware, as far as I know, but the first releases were for PowerPC, at first on their own hardware and then for PPC Macs until Apple got nervous and shut them out of the hardware internals. They use a Metrowerks PPC compiler that of course hasn't seen much development in the last 6 years, probably a lot longer. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: PPC floating equality vs. byte compilation
Donn Cave wrote: I ran into a phenomenon that seemed odd to me, while testing a build of Python 2.4.1 on BeOS 5.04, on PowerPC 603e. test_builtin.py, for example, fails a couple of tests with errors claiming that apparently identical floating point values aren't equal. But it only does that when imported, and only when the .pyc file already exists. Not if I execute it directly (python test_builtin.py), or if I delete the .pyc file before importing it and running test_main(). For now, I'm going to just write this off as a flaky build. I would be surprised if 5 people in the world care, and I'm certainly not one of them. I just thought someone might find it interesting. I have a faint recollection of seeing other references to this on other platforms. That faint recollection also seems to point to it being something to do with the marshalling of floats (.pyc files contain constants in a marshalled form). Don't think I've ever seen it myself... - Andrew I MacIntyre These thoughts are mine alone... E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia -- http://mail.python.org/mailman/listinfo/python-list
Re: PPC floating equality vs. byte compilation
[Donn Cave] I ran into a phenomenon that seemed odd to me, while testing a build of Python 2.4.1 on BeOS 5.04, on PowerPC 603e. test_builtin.py, for example, fails a couple of tests with errors claiming that apparently identical floating point values aren't equal. But it only does that when imported, and only when the .pyc file already exists. Not if I execute it directly (python test_builtin.py), or if I delete the .pyc file before importing it and running test_main(). It would be most helpful to open a bug report, with the output from failing tests. Can't guess much from the above. In general, this can happen if the platform C string-float routines are so poor that eval(repr(x)) != x for some float x, because .pyc files store repr(x) for floats in 2.4.1. The 754 standard requires that eval(repr(x)) == x exactly for all finite float x, and most platform C string-float routines these days meet that requirement. For now, I'm going to just write this off as a flaky build. I would be surprised if 5 people in the world care, and I'm certainly not one of them. I just thought someone might find it interesting. There are more than 5 numeric programmers even in the Python world wink, but I'm not sure there are more than 5 such using BeOS 5.04 on PowerPC 603e. The stalwart few who still use BeOS are mostly using Intel x86 hardware, as far as I know, but the first releases were for PowerPC, at first on their own hardware and then for PPC Macs until Apple got nervous and shut them out of the hardware internals. They use a Metrowerks PPC compiler that of course hasn't seen much development in the last 6 years, probably a lot longer. The ultimate cause is most likely in the platform C library's string-float routines (sprintf, strtod, that kind of thing). -- http://mail.python.org/mailman/listinfo/python-list
Re: PPC floating equality vs. byte compilation
Tim Peters [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [Donn Cave] I ran into a phenomenon that seemed odd to me, while testing a build of Python 2.4.1 on BeOS 5.04, on PowerPC 603e. test_builtin.py, for example, fails a couple of tests with errors claiming that apparently identical floating point values aren't equal. But it only does that when imported, and only when the .pyc file already exists. Not if I execute it directly (python test_builtin.py), or if I delete the .pyc file before importing it and running test_main(). This is a known problem with marshalling INFs and/or NANs. *This* has supposedly been fixed for 2.5. We are assuming that the failure you report is for real floats. It would be most helpful to open a bug report, with the output from failing tests. And assign to Tim. In general, this can happen if the platform C string-float routines are so poor that eval(repr(x)) != x ... The ultimate cause is most likely in the platform C library's string-float routines (sprintf, strtod, that kind of thing). It would also be helpful if you could do some tests in plain C (no Python) testing, for instance, the same values that failed. Hardly anyone else can ;-). If you confirm a problem with the C library, you can close the report after opening, leaving it as a note for anyone else working with that platform. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
