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