[Python-Dev] RE: stupid floating point question...

[Tim Peters]

[Tim]
> A *good* compiler won't collapse *any* fp expressions at
> compile-time ...

[Martin von Loewis]
> Of course, that doesn't say anything about what *most* compilers do.

Doesn't matter in this case; I told /F not to worry about it having taken
that all into account.  Almost all C compilers do a piss-poor job of taking
floating-point seriously, but it doesn't really matter for the purpose /F
has in mind.

[an example of gcc precomputing the best possible result]
> 	return (double)1/6;
> ...
> 	.long 0x55555555,0x3fc55555

No problem.  If you set the HW rounding mode to +infinity during
compilation, the first chunk there would end with a 6 instead.  Would affect
the tail end of the repr(), but not the str().

> ...
> when compiling with -fomit-frame-pointer -O2. That still doesn't say
> anything about what most compilers do - if there is interest, we could
> perform a comparative study on the subject :-)

No need.

> The "would break 754" argument is pretty weak, IMO - gcc, for example,
> doesn't claim to comply to that standard.

/F's question was about fp.  754 is the only hope he has for any x-platform
consistency (C89 alone gives no hope at all, and no basis for answering his
question).  To the extent that a C compiler ignores 754, it makes x-platform
fp consistency impossible (which, btw, Python inherits from C:  we can't
even manage to get string<->float working consistently across 100%
754-conforming platforms!).  Whether that's a weak argument or not depends
entirely on how important x-platform consistency is to a given app.  In /F's
specific case, a sloppy compiler is "good enough".

i'm-the-only-compiler-writer-i-ever-met-who-understood-fp<0.5-wink>-ly
    y'rs  - tim