[fpc-pascal] Floating point question

Bernd Oppolzer bernd.oppolzer at t-online.de
Tue Feb 6 23:46:22 CET 2024


I didn't follow all the discussions on this topic and all the details of 
compiler options of FPC
and Delphi compatibility and so on, but I'd like to comment on this result:

program TESTDBL1 ;

Const
    HH = 8427.0229166666666666666666666667;
Var
    AA : Integer;
    BB : Byte;
    CC : Single;
    DD : Single;
    EE : Double;
    FF : Extended;
    GG : Extended;
    

begin
    AA := 8427;
    BB := 33;
    CC := 1440.0;
    DD := AA+BB/CC;
    EE := AA+BB/CC;
    FF := AA+BB/CC;
    GG := 8427+33/1440.0;
    
    WRITELN ( 'DD = ',DD: 20 : 20 ) ;
    WRITELN ( 'EE = ',FF: 20 : 20 ) ;
    WRITELN ( 'FF = ',FF: 20 : 20 ) ;
    WRITELN ( 'GG = ',GG: 20 : 20 ) ;
    WRITELN ( 'HH = ',HH: 20 : 20 ) ;
end.


result:

DD = 8427.02246100000000000000
EE = 8427.02291666666666625000
FF = 8427.02291666666666625000
GG = 8427.02246093750000000000
HH = 8427.02291666666666625000


IMO, the computations of AA+BB/CC (right hand side) should be carried 
out the same way, regardless of the type
on the left hand side of the assignment. So I would expect the values in 
DD, EE and FF being the same.

But as it seems, the left hand side (and the type of the target 
variable) HAS AN INFLUENCE on the computation
on the right hand side, and so we get (for example)

DD = 8427.02246100000000000000

and

EE = 8427.02291666666666625000

which IMHO is plain wrong.

If all computations of AA+BB/CC would be carried out involving only 
single precision,
all results DD, EE, FF (maybe not GG) should be 8427.0224...
only minor differences because of the different precisions of the target 
variables
(but not as large as the difference between DD and EE above).

This would be OK IMHO;
it would be easy to explain to everyone the reduced precision on these 
computations
as a consequence of the types of the operands involved.

Another question, which should be answered separately:

the compiler apparently assigns types to FP constants.
It does so depending on the fact if a certain decimal representation can 
exactly be represented
in the FP format or not.

1440.0 and 1440.5 can be represented as single precision, so the FP type 
single is assigned
1440.1 cannot, because 0.1 is an unlimited sequence of hex digits, so (I 
guess), the biggest available FP type is assigned
1440.25 probably can, so type single is assigned
1440.3: biggest FP type
1440.375: probably single

and so on

Now: who is supposed to know for any given decimal representation of a 
FP constant, if it can or cannot
be represented in a single precision FP variable? This depends on the 
length of the decimal representation,
among other facts ... and the fraction part has to be a multiple of 
negative powers of 2 etc. etc.

That said: wouldn't it make more sense to give EVERY FP CONSTANT the FP 
type with the best available precision?

If the compiler did this, the problems which arise here could be solved, 
I think.

GG in this case would have the same value as HH, because the computation 
involving the constants
(hopefully done by the compiler) would be done with the best available 
precision.

HTH, kind regards

Bernd


Am 06.02.2024 um 16:23 schrieb James Richters via fpc-pascal:
> program TESTDBL1 ;
>
> Const
>     HH = 8427.0229166666666666666666666667;
> Var
>     AA : Integer;
>     BB : Byte;
>     CC : Single;
>     DD : Single;
>     EE : Double;
>     FF : Extended;
>     GG : Extended;
>     
>
> begin
>     AA := 8427;
>     BB := 33;
>     CC := 1440.0;
>     DD := AA+BB/CC;
>     EE := AA+BB/CC;
>     FF := AA+BB/CC;
>     GG := 8427+33/1440.0;
>     
>     WRITELN ( 'DD = ',DD: 20 : 20 ) ;
>     WRITELN ( 'EE = ',FF: 20 : 20 ) ;
>     WRITELN ( 'FF = ',FF: 20 : 20 ) ;
>     WRITELN ( 'GG = ',GG: 20 : 20 ) ;
>     WRITELN ( 'HH = ',HH: 20 : 20 ) ;
> end.
>
> When I do the division of a byte by a single and store it in an extended, I
> get the division carried out as an extended.
> FF, GG, and HH should all be exactly the same if there is not a bug.
> But:
>
> DD = 8427.02246100000000000000
> EE = 8427.02291666666666625000
> FF = 8427.02291666666666625000
> GG = 8427.02246093750000000000
> HH = 8427.02291666666666625000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20240206/3169a439/attachment-0001.htm>


More information about the fpc-pascal mailing list