Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!sbcs!libserv1.ic.sunysb.edu!ileung
From: ileung@libserv1.ic.sunysb.edu (Ivan S Leung)
Newsgroups: comp.lang.postscript
Subject: Re: BUG
Message-ID: <1991Feb21.161700.950@sbcs.sunysb.edu>
Date: 21 Feb 91 16:17:00 GMT
References: <218@wander.UUCP>
Sender: usenet@sbcs.sunysb.edu (Usenet poster)
Organization: State University of New York at Stony Brook
Lines: 39

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 >>>