Summary: Real number values incorrectly stored Overview: Some real number values incorrectly stored Steps to Reproduce, Results & Expected Results: Scenario 1) 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 (floating-point) object. If it exceeds the implementation limit for real numbers, a *limitcheck* error occurs. (PostScript® LANGUAGE REFERENCE, third edition, p. 28) Scenario 2) 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): $ gs 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 == 3.14159274 GS> GS>/pi load == 3.14159274 GS> 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). Scenario 3) Even more basic: GS>3.14159265 == 3.14159274 GS>3.14159265 GS<1>stack 3.14159 GS<1>== 3.14159274 GS> Obviously I would expect 3.14159265 returned in all these cases. Scenario 4) 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 == 3.14159274 GS>3.14159265 0 sub == 3.14159274 GS>3.14159265 1 exp == 3.14159274 I would expect 3.14159265 returned in all these cases. But some values do produce correct results: GS>3.14159274 1 mul == 3.14159274 GS>3.14159274 0 sub == 3.14159274 GS>3.14159274 1 exp == 3.14159274 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. Additional Information: In interactive mode, I get the following results. GS>/pi 3.14159632 def GS>pi == 3.14159632 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. GS>3.14159274 == 3.14159274 OK. But: GS>1.23456789 == 1.23456788 I expect 1.23456789. GS>5.23456789 == 5.23456812 I expect 5.23456789.
PostScript only produces limitcheck when the exponent is exceeded. PS should only expect IEEE 32-bit precision, but even that is not guaranteed. No "accuracy" is assured. Use 'dc' (or 'bc') for arbitrary precision calculations.