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