Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/18/2016 4:27 AM, Manu via Digitalmars-d wrote:
> The comparison was a 24bit fpu doing runtime work but where some
> constant input data was calculated with a separate 32bit fpu. The
> particulars were not ever intended to be relevant to the conversation,
> except the fact that 2 differently precisioned float units were
> producing output that then had to reconcile.
>
> The analogy was to CTFE doing all its work at 80bits, and then the
> processor doing work with the types explicitly stated by the
> programmer; a runtime calculation compared against the same compile
> time calculate is likely to be quite radically different. I don't care
> about the precision, I just care that they're really different.
> Ideally, CTFE would produce a result that is as similar to the runtime
> result as reasonably possible, and I expect using the stated types to
> do the calculations would get much much closer.
> I don't know if a couple of least-significant bits of difference would
> have caused problems for us, I suspect not, but I know that doing math
> at radically different precisions (ie, 32bits vs 80bits) does lead to
> radically different results, not just a couple of bits. That is my
> concern wrt reproduction of my anecdote from PS2 and Gamecubes 24bit
> fpu's.
>

"radically different results" means you were getting catastrophic loss of 
precision in the runtime results, which is just what doing the CTFE at a higher 
precision is attempting to avoid (and apparently successfully).

I get that the game did not care about the value produced, even if it was total 
garbage. I suspect that games are the only category of FP apps where there is no 
concern for the values computed. I do not understand the tolerance for bad 
results in scientific, engineering, medical, or finance applications.

The only way to *reliably* get the same results at compile time as at runtime, 
regardless of what technology is put into the language/compiler, is to actually 
run the code on the target hardware, save the results, and insert those values 
into the code. It isn't that hard to do, and will save you from endless ghosts 
popping up that waste your debugging time.