Zitat von Florian Klämpfl <flor...@freepascal.org>:
In pascal, the rule applies that *the resulting type of an operation
does not depend on the type a value is assigned too*. So: 1.0 fits
perfectly into a single, 3.0 as well, they are single constants (you
didn't tell the compiler otherwise). Nobody wants that unnecessarily
larger types are used. So for the compiler this is a single division
and later on the result is converted into extended. The result for
integer is indeed a little bit strange, here probably the default
rule applies that any /-operand is converted to the best available
real type if it is not a real type, thus the result differs.
Question is, if the compiler should look the operand types and
choose more carefully the types, but I tend more to say no.
In any case there two facts.
1. The constants are evaluated at compile time, so there is no
speed penalty.
2. This is a regression from 3.0.4 (here the 32-bit version works as
expected for both double and extended, and same for 64-bit except that
here extended=double) and to 3.1.1 (both under Win7/64).
Is there a definite statement, that is will remain so.
Insert type casts for the constants to get proper results on all
archs, see below.
This is problematic because for portable code because not all compilers
support type casts here.
(Delphi works as expected).
The reason why delphi behaves different is probably due to it's
roots in being x87 only: x87 does all calculations with extended
precision.
This is also as expected for 64-Bit Delphis using SSE.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
