COAET" • r

Based on the above discussion, we would expect something
like the following output:
0.12345600
1.23456000
12.34560000
123.45600000
1234.56000000
12345.60000000
123456.00000000
1234560.00000000
12345600.00000000
123456000.00000000
Instead, when we run the program, we get:
0.123456M
1.23456
12.3456
123.456
1234.56
12345.6
123456.
1.23456E6
1.23456E7
1.23456E8
What's the problem here? Not only does Pascal fail to
print the eight digits we requested after the decimal point, it
also switches over to scientific notation after a certain point.
And the extraneous "M" that appears after the first number
is certainly a strange - er, "feature.'' I don't know what else
to say about it. It seems that the output routines will display a
maximum of six significant digits in a real number, presumably
to protect the user from misinterpretinr the results of
his/her program. The programmers who decided to implement
real number formatting in this way no doubt had
good reasons (in their own minds) for their decision, but the
problem is that such behavior contradicts the documentation
and most Pascal texts.
So here's one possible solution to the problem; Listing 3
is a simple routine to convert a real number to a formatted
string, using the same parameters for minimum field width
and digits after the decimal point:
LISTING 3
procedure rtos(var s: string; r: real;
len, ndigits:integer);
(* Convert real number (r) to a string (s) *)
(* len = minimum field width *)
(* ndigs = no. of digits after decimal pt. *)
var
negnum: boolean;
sl: string[!];
e, expo, i: integer;
plO: real;
begin
s := I I ,
' sl ! = I I;
negnum := (r < 0.0);
r := abs(r) + 0.5/pwroften(ndigits);
expo := O;
e := 32;
while e > 0 do begin
plO := pwroften(e);
while r >= plO do begin
r := r/plO;
expo := expo + e
end;
e := e div 2
end;
for i := expo downto 0 do begin
sl[l] := chr(trunc(r) + 48);
s := concat(s, sl);
r := 10.0 * (r - trunc(r))
end;
if ndigits > 0 then begin
s : = conca t ( s, ' • ' ) ;
for i := 1 to ndigits do begin
sl[l] := chr(trunc(r) + 48);
s := concat(s, sl);
r := 10.0 * (r - trunc(r))
end
end;
if negnum then
s := concat('-', s);
while length(s) < len do
s := concat(' ', s)
end;
The routine could, for example, replace the statement:
WRITELN(X: W: D);
with the two statements:
RTOS(S, X. W, D);
WRITELN(S)
Disclaimer: Listing 3 isn't meant to be a general-purpose
real-to-string routine, just an indication of a possible solution.
It doesn't take too much care in checking its input
parameters, and it returns "noise" digits in the output string
if one attempts to obtain more digits than Pascal can
represent accurately. But enhancements to correct these
features are easy to add; they are left to the interested
reader.
Conclusion
I've tried to demonstrate three problems in Apple's
implementation of Pascal. I don't want to make more out of
it than is necessary; seen in the context of the whole Pascal
system, they are relatively minor surprises that the majority
of programmers will perhaps never come across. Apple
Pascal, in my opinion, is still an excellent choice for software
development.
On the other hand, I don't want to minimize the seriousness
of such language quirks. They are undocumented
pitfalls that the programmer must discover and avoid, so
they do make one's programming effort more difficult.
They also damage one of Pascal's nicest benefits: its portability.
A Pascal program written on the Apple can be moved
(in theory) to another computer and run with relatively little
modification, and vice versa. But deviations and -er, "features"
like these can make such modifications much more
difficult.
58 Apple Orchard