Mail #6262

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: levi@localhost.nc3a.nato.int
Subject: [BUG REPORT] Reading LongReal
Date: 25 Mar 2001, 13:52:11

Hallo,

in order to put some light on the problem, I modified your
program (appended below). It prints in addition the bit pattern
of A and B, and allows to modify the type of values (recompile).

It seems to me that there is really a problem with the LongReal type.
I don't know how many bits/bytes this type is using, may be more
than 64 bits which is the test programs maximum limit. ShortReal
(bits=32) and Real (bits=64) work nearly correct, with sometimes
different low order bits, due to rounding effects. Here some results,
A - B pairs of type Real (64 bits):

 1.030000000000000e+02
0100000001011001110000000000000000000000000000000000000000000000
 1.030000000000000e+02
0100000001011001110000000000000000000000000000000000000000000000
OK

 1.300000000000000e+00
0011111111110100110011001100110011001100110011001100110011001101
 1.300000000000000e+00
0011111111110100110011001100110011001100110011001100110011001101
OK

 3.333333333333333e-01
0011111111010101010101010101010101010101010101010101010101010101
 3.333333333333333e-01
0011111111010101010101010101010101010101010101010101010101010101
OK

Ernst-Ludwig

 On Sun, 25 Mar 2001, f.couperin wrote:
OK
> 
> Frank Heckenbach 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 ?
> 
> 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). And if it reads
> 103000e-03 (103000 IS periodic), the value is slightly wrong...
> (I tested this strange behaviour with the program shown below.)
> 
> 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, but the result was really
> unclear to me and I didn't understand the logic behind those numbers.
> I found and read this web page :
> http://www.infobiogen.fr/docs/info/SUNWspro/pascal/lang_ref/ref_data.doc.htm
> l
> (about another Pascal compiler)
> but it seems the GPC LongReal type is different from what is described
> there.
> 
> Program Bug09;
> Var
>   A,B,C,D,E,F,G,H,I :  LongReal;
>   TextFile : Text;
> Begin
>   Assign(TextFile,'tmp');
>   Rewrite(TextFile);
>   Writeln(TextFile,'1030000e-04');
>   Writeln(TextFile,'103000e-03');
>   Writeln(TextFile,'10300e-02');
>   Writeln(TextFile,'1030e-01');
>   Writeln(TextFile,'103');
>   Writeln(TextFile,'10.3e+01');
>   Writeln(TextFile,'1.03e+02');
>   Writeln(TextFile,'0.103e+03');
>   Writeln(TextFile,'0.0103e+04');
>   Close(TextFile);
>   Reset(TextFile);
>   Readln(TextFile,A);
>   Readln(TextFile,B);
>   Readln(TextFile,C);
>   Readln(TextFile,D);
>   Readln(TextFile,E);
>   Readln(TextFile,F);
>   Readln(TextFile,G);
>   Readln(TextFile,H);
>   Readln(TextFile,I);
>   Close(TextFile);
>   Erase (TextFile);
>   Writeln;
>   Writeln('A = ',A:28); {Inaccurate}
>   Writeln('B = ',B:28); {Inaccurate}
>   Writeln('C = ',C:28); {OK}
>   Writeln('D = ',D:28); {OK}
>   Writeln('E = ',E:28); {OK}
>   Writeln('F = ',F:28); {OK}
>   Writeln('G = ',G:28); {Inaccurate}
>   Writeln('H = ',H:28); {Inaccurate}
>   Writeln('I = ',I:28); {Inaccurate}
> End.
> 
> --
> «Couperin»
> 

Program LRealBug; {-*-Mode: fundamental-mode}
                              { variations of bits & real_type}
const                         { OK          OK         Failed!!}
  bits      = 64;             { bits= 32    bits= 64   bits= 64}
type
  real_type = Real;           { ShortReal   Real       LongReal}
  word_type = word   (bits);
  bit_str   = string (bits);
  T= record
       case integer of
        0: (A, B: real_type); { contains the real value }
        1: (I, J: word_type); { contains the real value as bit pattern }
       end;
Var
  V        : T;
  TextFile : Text;

function bits2str (value: word_type): bit_str; {converts a word into string (binary)}
var w, m: word_type; i: integer; s: bit_str;
begin
  w:= value;  s:='';
  m:= 1 shl (bits-2); m:= m shl 1; {sorry, GPC thinks m to be a signed integer}
  for i:= 1 to bits do             {1 shl (bits-1) is an error at compile time}
     begin if (w and m) = 0 then s:= s + '0' else s:= s + '1'; w:= w shl 1 end;
  bits2str:= s
end;

procedure try (value: real_type);
Begin
  with V do
    begin
      A:= value;
      Assign(TextFile,'tmp'); Rewrite(TextFile); Writeln(TextFile, A);
      Close(TextFile);
      Reset(TextFile); Readln(TextFile,B); Close(TextFile);
      Erase (TextFile);
      writeln (A, ' ', bits2str (I));
      writeln (B, ' ', bits2str (J));
      If A <> B
        Then Writeln('Failed')
        Else Writeln('OK');
    end
End;

Begin
  try (103.0);
  try (10300e-02);
  try (1.3);
  try (1.0/3.0);
  try (1.0/3.1111);
  try (7.0/3.0)
end.

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).