[fpc-pascal] Order of Precedence: FPC/Delphi vs Java

[gtt at wolfgang-ehrhardt.de]

This is one of the most useless collection of floating point myths I
have seen since a long time.


> I don't know why you want to compare two floats, but you'd better  
> use currency type. Float is for calculus, but comparing  
> float1=float2 (or float1>float2) is rolling the dice. Obviously, the  
> more precision, the less errors. But an accurate, intuitive result,  
> is not guaranteed.

With rolling a dice you mean, that the comparisons are only
randomly correct or what)? Since the floating-point numbers
are well-defined and exact (yes they are, and truncation/rounding
errors are the results from former computations and/or
the rounding of non-representable numbers). All operations
are predictable, so there is no chance for random.

> People who play with maths may use something like
> function equal(const f1,f2:Extended; const Error:extended=1E-6):boolean;
> begin
>  Result:=(abs(f1-f2)<error);
> end;

This function is non-sense and I doubt that 'math people' will use it.
First: it uses only absolute errors, so 1e-7 and 1e-4000 are equal.
Second: A tolerance of 1e-6 is ridiculous, given that the machine epsilon
for 80-bit extended is 1.0842e-19.

> What does java does? I don't know. Perhaps it just rounds the  
> output, try  System.out.println(ans==0.0). Perhaps it uses a high  
> precision that *in this case* gets always 0.

As already said, you can get the same values as Java, if you use the
same data types (double) and the same precision (53-bit) with
Free Pascal (even with the X87 FPU)

  5.1009900000000001E+004
  5.1009900000000001E+004
  5.1009900000000001E+004
---
  0.0000000000000000E+000
  0.0000000000000000E+000
  0.0000000000000000E+000
  0.0000000000000000E+000
  0.0000000000000000E+000

> But the question is that floating point representation can't store  
> accurately many numbers. To begin with,  0.1 in base 10, is periodic  
> number in binary 0.0001...001..001... so it has to truncate it,

No is this only true if you use the truncate rounding mode, which
is not default (default is round-to-nearest/even).

> and when you truncate, the result depends of the order of  
> operations, no matter the language or precision. So, it is matter of  
> probability to get 1.0000 or 1.0001 or 0.9999

Yes, but it is predictable and 	deterministic and no matter of
probability.

To conclude: The reason for the differences is the usage of
intermediate elevated precision (and this can occur also
e.g. for C where it is also allowed to use intermediate
higher precision). For Delphi/Free Pascal this phenomenon
does not occur if you always compute with the precision
appropriate to the data type, as e.g. with 64-bit/SSE.

Regards,
Wolfgang