f.couperin wrote:
[...]
So, why is B slighly inaccurate? Well, if you look at the file, it contains the text:
1.030000000000000e+02
And that's exactly what ReadLn sees. I.e., first the number 1.03 which cannot be represented exactly since floating point numbers (at least IEEE and most other popular formats) are binary, not decimal, and 1.03 in binary is periodic.
Afterwards, it finds `e+02' and multiplies the result by 100 which can be done exactly, but the error was already made.
[...]
Is this really computer dependent or does it depend of the program ? I think that reading 1.030000000000000e+02 as 1030000000000000 * 10^(-15+2) would suppress the problem. Wouldn't it be better ?
In this case yes. But if the number was written as 1.03<thousands of 0s>, this would overflow while the number is perfectly valid.
Sure, things can be improved, but it's not as trivial as it might seem. I don't have the time do think about it now, but if you like to try -- the code is _p_read_longreal in rts/file.c (that's in C, but if you write a better version in Pascal, that's also fine; sooner or later the code will be translated to Pascal, anyway).
What I don't understand is that there is no problem if Readln reads 10.3e+01 in the file (10.3 isn't periodic in binary).
Yes, it is (1001.0period1001). But it doesn't mean there *has* to be an error. Depending on where the binary representation is cut-off, the result (probably rounded to the last valid digit internally) may happen to be right or wrong.
And if it reads 103000e-03 (103000 IS periodic), the value is slightly wrong...
103000 is a whole number (not periodic, or with a period of 0 if you like) and can be represented exactly. But `e-03', i.e. 10**(-3) is not.
OK, we could do 103000 / 10**3 rather than 103000 * 10**(-3)... I'm changing this now (will be uploaded soon), and then this test works indeed...
I'm wondering if there's a way to write a binary (or hexadecimal) representation of the LongReal type in a text file, a clear and understandable representation that could be read back by the program without any difference with the original number. I wrote LongReal numbers to a File Of LongReal, and I translated this file into an hexadecimal representation,
Yes, that's a way to do it. (You could achieve the same within the program, by type casting to an array of bytes or something -- if you need to have a text file. Normally, a file of LongReal would be most appropriate.)
Ernst-Ludwig Bohnen wrote:
I don't know how many bits/bytes this type is using,
BitSizeOf (LongReal) and SizeOf (LongReal). The numbers depend on the platform.
George Shapovalov wrote:
If longReal corresponds to 'extended' on x86, then it is represented by 10 bytes (80bits). This held since the days of i80387 as I remember.
Yes.
The details of the representation are available in many places, I suppose. They're printed in the BP manual AFAIR, and they're probably also available on the Net.
Frank