PPC floating equality vs. byte compilation

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