[fpc-pascal] Floating point question

[Thomas Kurz]

> But, sorry, because we are talking about compile time math, performance 
(nanoseconds) in this case doesn't count, IMO.

That's what i thought at first, too. But then I started thinking about how to deal with it and sumbled upon difficulties very soon:

a) 8427.0 + 33.0 / 1440.0
An easy case: all constants, so do the calculation at highest precision and reduce it afterwards, if possible.

b) var_single + 33.0 / 1440.0
Should also be feasable by evaluating the constant expression first, then reducing it to single (if possible) and adding the variable in the end.

c) 8427.0 + var_double / 1440.0
Because of using the double-type variable here, constants should be treated as double even at the cost of performance due to not knowing whether the result will be assigned to a single or double.

d) 8427.0 + var_single / 1440.0
And this is the one I got to struggle with. And I can imagine this is the reason for the decision about how to handle decimal constants.
My first approach would have been to implicitly use single precision values throughout the expression. This would mean to lose precision if the result will be assigned to a double-precision variable. One could say: "bad luck - if the programmer intended to get better precision, he should have used a double-precision variable as in case c". But this wouldn't be any better than the current state we have now.

Overall, I must admit that the choice ain't easy at all.

In this situation, it might be a good choice to ask "what would other languages do here?". As far as I know about C, it treats constants as double-precision by default. You have to write "1.0f" if you explicitly want single precision.
But I think it's too late for introducing yet another change. Imho, the correct decision at FPC v2.2 would have been to keep the previous behavior and instruct those concering performance to use "{$MINFPCONSTPREC 32}" (or using the "1.0f" notation) instead of requiring everyone to use "{$MINFPCONSTPREC 64}" to keep compatibility with previous releases.

Thomas