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

[Florian Klämpfl]

Am 03.07.2018 um 20:33 schrieb 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.

So you want float constants being evaluated always with full precision (which would be required for consistency) causing 
any floating point expression containing a constant being evaluated with full precision as well? Or how do you want to 
change rules to overcome the mentioned fact? I see only rules which require additional exceptions or causing full 
precision calculations always. The fact that the result type of an operations depends only on the operands, is not 
changeable, doing so will end in devil's kitchen.

> 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).

This was probably changed for consistency. I tried to find the commit which changes this, but I cannot currently find it.

> 
>>
>>> 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.
> 

As said, (very strong) roots in x87.