FP exception, core dump in Python 1.5.2 (Tim's doing <grin>)

Tim Peters tim_one at email.msn.com
Wed Apr 28 01:24:23 EDT 1999


[Tim, suggests some code to generate INFs and NANs]
> ...

[Mark Favas tries it, and...]
> On my platform, (DEC Alpha, Digital Unix 4.0D, Python 1.5.2) I
> get... a core dump! (exclamation because it's one of the few Python
> core dumps I've seen).

Excellent!  Here's one of your problems:

> DEC Alpha

and here's the other <wink>:

> Digital Unix


> [code modified to print i, x, x2]
>
> python ieee.py
> 0 2.0 4.0
> 1 4.0 16.0
> 2 16.0 256.0
> 3 256.0 65536.0
> 4 65536.0 4294967296.0
> 5 4294967296.0 1.84467440737e+19
> 6 1.84467440737e+19 3.40282366921e+38
> 7 3.40282366921e+38 1.15792089237e+77
> 8 1.15792089237e+77 1.34078079299e+154
> Floating exception (core dumped)

Well, the next step is to square 1.3e154, and that will create an infinity
on an IEEE-754 conformant machine (the square is too big to fit in an IEEE
double).  Your platform apparently triggers an unmasked IEEE (not Python)
Overflow exception instead, and your OS decides that's fatal.  That means
your platform violates the 754 std in two ways, and, as advertised, ieee.py
raises an exception to gently inform you of that <wink>.

Presumably if you scrounge around long enough, you'll find the software
incantation you need to make your platform pretend to be 754 conformant.
There's not much use in trying to muck with 754 features so long as it's
not!  Nothing Python can do about it on its own, either, short of simulating
754 arithmetic in software.

> ...
>    9 PyNumber_Multiply(0x1400b2988, 0x1400b13c0, 0x1400b13c0,
> 0x0, 0x3) [0x12006f400]
> (dbx)

Oh ya.

floating-point-is-its-own-reward-ly y'rs  - tim






More information about the Python-list mailing list