hicham@olsen.UUCP (Hicham Bahi) (02/20/91)
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 ??? HICHAM (hicham@olsen.uucp.ch)
cet1@cl.cam.ac.uk (C.E. Thompson) (02/21/91)
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
aas@aase.nr.no (Gisle Aas) (02/21/91)
In article <218@wander.UUCP> hicham@olsen.UUCP (Hicham Bahi) writes: > > /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. The currentpoint operator returns real numbers. You compare it with an integer value, which probably is converted to a real number before the test takes place. Comparing real number for equality is not advisable. In addition you should be aware that you may get a small round-off error because the coordinates are converted to device coordinates after the moveto operator. The currentpoint operator converts them back into user coordinates. -- Gisle Aas | snail: Boks 114 Blindern, N-0314 Oslo, Norway Norsk Regnesentral | X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no voice: +47-2-453561 | inet: Gisle.Aas@nr.no
ileung@libserv1.ic.sunysb.edu (Ivan S Leung) (02/22/91)
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 ??? > I run the above program (verbatim) through a PostScript (Adobe) printer and OpenWindows pageview. Both gave me "true". I don't know much about PostScript but my guess is that round-off error occurred during the conversion from user space coordinate to device coordinate by CTM then back to user space coordinate. Here's a classic example of round-off error: X, Y and Z are floating point numbers Z = X * Y (assume no overflow) X == Z / Y is not always true --- Ivan Leung INTERNET: ileung@libserv1.ic.sunysb.edu Facsimile Marketing, Inc. VOICE: 203-323-4400 FAX: 203-323-4368 3 Landmark Square, Suite 403 Stamford, CT 06901 >>> Send 1000 fax as fast as 1 >>>
tj@gpu.utcs.utoronto.ca (Terry Jones) (02/27/91)
Probably not the first to respond but what I see on the stack when I do the following 15 280 moveto currentpoint pstack is... 280 280.0 15.0 Which means the currentpoint returns a float which could be fixed in your code to work by adding .5 and doing a cvi to convert to integer before the compare tj