Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!cam-cl!news
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.lang.postscript
Subject: Re: BUG
Message-ID: <1991Feb20.214619.13488@cl.cam.ac.uk>
Date: 20 Feb 91 21:46:19 GMT
References: <218@wander.UUCP>
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Organization: U of Cambridge Comp Lab, UK
Lines: 37

In article <218@wander.UUCP> hicham@olsen.UUCP (Hicham Bahi) writes:
>PostScript Bug?
>
>I have noticed a strange behavior of both my Laser printer
>and Ghostscript: I wrote the following programm:
>
>/str 10 string def
>150 280 moveto
>currentpoint 280 eq str cvs show
>
>The display I got from both my Laser printer and
>Ghostscript was FALSE. I printed the stack after the
>currentpoint operator and its top element was 280. So
>can somebody explain to me why the eq operator returns
>FALSE ? Of course, I checked some other values like 4,
>109, 40 but the result was the same, except for values
>like 300 or 400. It seems improbable that it's a bug
>because the behavior of Ghostscript and my Laser
>printer was the same. So what's the problem ??? 
>
Rounding. `moveto' transforms the user coordinates to device coordinates,
`currentpoint' transforms these back to user coordinates. The results are
delivered as `real', which means IEEE754 single-precision reals in most
PostScript implementations. If you do 

150 280 moveto currentpoint 280 sub =

you will find (on a LaserWriter, anyway) that you are 1.5e-5 out (2**-16, 
in fact).

This is made much more confusing by the fact that `cvs' (or things that use
it, like = or pstack) prints PostScript `real's to a ridiculously small  
number of digits, so that values that appear equal are not in fact so.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk