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