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

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, (e-mail address removed)

 

[Andrew MacIntyre]

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

 

[Tim Peters]

[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

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

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

 

[Terry Reedy]

[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

 

[Michael Hudson]

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

And assign to Tim.

That's mean!

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