[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4