[gs-bugs] [Bug 691858] New: Real number values incorrectly stored
bugzilla-daemon at ghostscript.com
bugzilla-daemon at ghostscript.com
Thu Dec 30 00:27:16 UTC 2010
Summary: Real number values incorrectly stored
OS/Version: MacOS X
Component: PS Interpreter
AssignedTo: alex.cherepanov at artifex.com
ReportedBy: starman at frontiernet.net
QAContact: gs-bugs at ghostscript.com
Estimated Hours: 0.0
Real number values incorrectly stored
Some real number values incorrectly stored
Steps to Reproduce, Results & Expected Results:
Create a file on a secondary storage device containing the lines:
/pi 3.14159265 def
(\npi = ) print pi == flush
Interpreting the file, GS 8.61, 8.64 & 9.00 deliver the following to the
standard output file (%stdout):
pi = 3.14159274
Notice the last two digits differ from the definition. I expect the recalled
value to match the defined value. (I would at least expect a limitcheck error
to occur if the implementation limit for real numbers has been exceeded; see
the following reference.)
A real number consists of an optional sign and one or more decimal digits, with
an embedded period (decimal point), a trailing exponent, or both. The exponent,
if present, consists of the letter E or e followed by an optional sign and one
or more decimal digits. The number is interpreted as a real number and is
converted to a real (ﬂoating-point) object. If it exceeds the implementation
limit for real numbers, a *limitcheck* error occurs. (PostScript® LANGUAGE
REFERENCE, third edition, p. 28)
Same incorrect results are produced in interactive mode (tested with GS 9.00
(2010-09-14) running under Mac OS X Terminal 2.0.2 & XQuartz 2.1.6 Terminal):
GPL Ghostscript 9.00 (2010-09-14)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>/pi 3.14159265 def
GS>/pi load ==
Again I expect the recalled value to match the value as defined. I also expect
consistency in results no matter the source of the commands (file stored on a
secondary storage device or the interactive executive).
Even more basic:
Obviously I would expect 3.14159265 returned in all these cases.
Incorrect calculations (tested with GS 9.00 (2010-09-14) running under Mac OS X
Terminal 2.0.2 & XQuartz 2.1.6 Terminal):
GS>3.14159265 1 mul ==
GS>3.14159265 0 sub ==
GS>3.14159265 1 exp ==
I would expect 3.14159265 returned in all these cases.
But some values do produce correct results:
GS>3.14159274 1 mul ==
GS>3.14159274 0 sub ==
GS>3.14159274 1 exp ==
Build Date & Platform:
Some of this was tested with GPL Ghostscript 8.61 & 8.64 (2009-02-03) and some
only after upgrading to 8.64. Both versions were obtained with/installed by
MacPorts and were run on a 1.8 GHz G5 PowerPC iMac under OS X 10.4.11. Version
8.61 was compiled with Xcode Version 2.0 and 8.64 was compiled with Xcode
Version 2.4.1. Also tested with with GPL Ghostscript Version 9.00 (2010-09-14)
running under Mac OS X Version 10.5.8 on the same computer just described. This
version (9.00) was again obtained with/installed by MacPorts, but compiled with
Xcode Version 3.1.4.
Additional Builds and Platforms:
Like results were obtained with gswin32c.exe (GPL Ghostscript 8.64, Build
2009-02-03), pre-compiled, from
http://pages.cs.wisc.edu/~ghost/doc/GPL/gpl864.htm) under Windows XP 2002 SP 2
running on an HP Compac Model dc770p SFF computer featuring an Intel(R)
Core(TM)2 CPU, 6300 @ 1.86GHz, and 1.58 GHz 0.97 GB of RAM.
In interactive mode, I get the following results.
GS>/pi 3.14159632 def
Unlike some values, such as 3.14159265, Ghostscript stores 3.14159632 without
error. (Or at least reports that it has been stored without error in
interactive mode.) I expect *all* values to be returned as defined, 3.14159265
as well as 3.14159632. More examples follow.
I expect 1.23456789.
I expect 5.23456789.
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the gs-bugs