From: Marius Gedminas mgedmin@pub.osf.lt To: gpc@hut.fi Cc: Bcc: Subject: LongestReal problems Reply-To:
Hi, developers!
DJGPP version of GPC-980511 complains when I try to use ArcTan function on LongestReals (in fact is is `ld', not `gpc', which complains). The error message is as follows:
c:/djgpp/lib/gcc-lib/djgpp/2.81/libgpc.a(pp_ARCTAN.o)(.text+0xd):rts-emath.c: undefined reference to `tanl' c:/djgpp/lib/gcc-lib/djgpp/2.81/libgpc.a(pp_ARCTAN.o)(.text+0x29):rts-emath.c: undefined reference to `tanl'
Another (unrelated) problem: let's say we have a source like this:
program StrangeLongReals; { This compiles both under GPC and Borland Pascal } {$IFNDEF __GPC__} {$N+,E+} {$ENDIF} var R: {$IFDEF __GPC} LongestReal {$ELSE} Extended {$ENDIF}; begin R := 0.123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } R := 0.1234512345123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } end.
When compiled with Borland Pascal I get the following output: 1.23451234512345E-0001 0.123451234512345000 1.23451234512345E-0001 0.123451234512345123
And GPC version gives: 1.234512345123450e-01 0.1234512345123449999978669759571270816137668263830656896932817737042602 1.234512345123451e-01 0.1234512345123451234478368405878757685782057823543386991840842994341343
I don't know if this is a bug or a feature, but I would prefer the behavior of BP.
Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin@pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86
According to Marius Gedminas:
DJGPP version of GPC-980511 complains when I try to use ArcTan function on LongestReals (in fact is is `ld', not `gpc', which complains).
This will be corrected in the next release. Thanks.
program StrangeLongReals; { This compiles both under GPC and Borland Pascal } {$IFNDEF __GPC__} {$N+,E+} {$ENDIF} var R: {$IFDEF __GPC} LongestReal {$ELSE} Extended {$ENDIF};
GPC has `Extended' (same as `LongestReal'), too.
begin R := 0.123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } R := 0.1234512345123451234512345; WriteLn(R); {--- Correct } WriteLn(R:0:70); {--- Prints lots of random digits } end.
When compiled with Borland Pascal I get the following output: 1.23451234512345E-0001 0.123451234512345000 1.23451234512345E-0001 0.123451234512345123
And GPC version gives: 1.234512345123450e-01 0.1234512345123449999978669759571270816137668263830656896932817737042602 1.234512345123451e-01 0.1234512345123451234478368405878757685782057823543386991840842994341343
Hmm ... you are requesting more digits than the precision of the data provides. The additional digits are not random but a result of the limited precision. They are correct in the sense that they represent the number the machine is acutally calculating with.
I don't know if this is a bug or a feature, but I would prefer the behavior of BP.
I think that BP's behaviour is the wrong one. Just think, for instance, of a machine with `LongestReal's of 128 or more bits. With `WriteLn(R:0:70)' I expect 70 digits of output after the decimal point; whether they are valid or not depends on the machine the program is running on.
I may be wrong (= not compliant to the (ISO-) standards).
Does somebody know?
Peter