> 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
_______________________________________________
fpc-pascal maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
