[fpc-pascal] Loss of precision when using math.Max()

[gtt at wolfgang-ehrhardt.de]

Zitat von Florian Klämpfl <florian at 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.