Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #1626 > unrolled thread

[] [] eq apparently returns true

Back to article view | Back to comp.lang.postscript

Contents

  [] [] eq apparently returns true anavi8r@gmail.com - 2013-09-18 10:16 -0700
    Re: [] [] eq apparently returns true Scott Hemphill <hemphill@hemphills.net> - 2013-09-18 22:50 -0400
      Re: [] [] eq apparently returns true luser- -droog <mijoryx@yahoo.com> - 2013-09-18 22:28 -0700
        Re: [] [] eq apparently returns true luser- -droog <mijoryx@yahoo.com> - 2013-09-18 22:35 -0700
        Re: [] [] eq apparently returns true Mark Carroll <mtbc@bcs.org> - 2013-09-19 08:28 +0100
          Re: [] [] eq apparently returns true luser- -droog <mijoryx@yahoo.com> - 2013-09-19 02:06 -0700
            Re: [] [] eq apparently returns true luser- -droog <mijoryx@yahoo.com> - 2013-09-19 02:25 -0700
          Re: [] [] eq apparently returns true luser- -droog <mijoryx@yahoo.com> - 2013-09-19 02:38 -0700
      Re: [] [] eq apparently returns true anavi8r@gmail.com - 2013-09-21 11:28 -0700
        Re: [] [] eq apparently returns true luser- -droog <mijoryx@yahoo.com> - 2013-09-21 12:30 -0700
          Re: [] [] eq apparently returns true Scott Hemphill <hemphill@hemphills.net> - 2013-09-23 23:24 -0400

#1626 — [] [] eq apparently returns true

Hi all,

I am writing a PostScript interpreter and I just ran into the following strange issue: 

Apparently, a "standard" PostScript interpreter such as Photoshop, when running into the code

[] [] eq

returns true (which is unexpected), while the code

[1] [1] eq 

or

[] [1] eq

return false (which is expected.)

Why would two empty arrays considered equal? Shouldn't they still occupy different areas of the VM?

Thanks in advance.

-- Peter

[toc] | [next] | [standalone]

#1627

anavi8r@gmail.com writes:

> Hi all,
>
> I am writing a PostScript interpreter and I just ran into the following strange issue: 
>
> Apparently, a "standard" PostScript interpreter such as Photoshop, when running into the code
>
> [] [] eq
>
> returns true (which is unexpected), while the code
>
> [1] [1] eq 
>
> or
>
> [] [1] eq
>
> return false (which is expected.)
>
> Why would two empty arrays considered equal? Shouldn't they still occupy different areas of the VM?

Because empty arrays don't use any VM.  The pointer into the VM is null.

Scott
-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear

[toc] | [prev] | [next] | [standalone]

#1628

On Wednesday, September 18, 2013 9:50:59 PM UTC-5, Scott Hemphill wrote:
> anavi8r@gmail.com writes:
> 
> 
> 
> > Hi all,
> 
> >
> 
> > I am writing a PostScript interpreter and I just ran into the following strange issue: 
> 
> >
> 
> > Apparently, a "standard" PostScript interpreter such as Photoshop, when running into the code
> 
> >
> 
> > [] [] eq
> 
> >
> 
> > returns true (which is unexpected), while the code
> 
> >
> 
> > [1] [1] eq 
> 
> >
> 
> > or
> 
> >
> 
> > [] [1] eq
> 
> >
> 
> > return false (which is expected.)
> 
> >
> 
> > Why would two empty arrays considered equal? Shouldn't they still occupy different areas of the VM?
> 
> 
> 
> Because empty arrays don't use any VM.  The pointer into the VM is null.
> 


Dammit! Mine prints 'false'. :(

[toc] | [prev] | [next] | [standalone]

#1629

On Thursday, September 19, 2013 12:28:54 AM UTC-5, luser- -droog wrote:
> On Wednesday, September 18, 2013 9:50:59 PM UTC-5, Scott Hemphill wrote:
> 
> > anavi8r@gmail.com writes:
> > > Hi all,
> > >
> > > I am writing a PostScript interpreter and I just ran into the following strange issue: 
> > >
> > > Apparently, a "standard" PostScript interpreter such as Photoshop, when running into the code
> > >
> > > [] [] eq
> > >
> > > returns true (which is unexpected), while the code
> > >
[snip]
> > > Why would two empty arrays considered equal? Shouldn't they still occupy different areas of the VM?
> > 
> > 
> > 
> > Because empty arrays don't use any VM.  The pointer into the VM is null.
> > 
> 
> 
> Dammit! Mine prints 'false'. :(

fixed. zero-length arrays have a null "pointer".

$ ./itp

^test itp.c
loading init.ps...
loading err.ps...
$error
Xpost3 version 0.0
PS>[] [] eq =
true
PS><operator 1 exch 0x407c71>bye!

[toc] | [prev] | [next] | [standalone]

#1630

luser- -droog <mijoryx@yahoo.com> writes:

> On Wednesday, September 18, 2013 9:50:59 PM UTC-5, Scott Hemphill wrote:
(snip)
>> Because empty arrays don't use any VM.  The pointer into the VM is null.
>
> Dammit! Mine prints 'false'. :(

I wonder if the language spec make a guarantee either way. Have you run
into any other interpreter issues where you were surprised to get some
latitude on which way to jump?

-- Mark

[toc] | [prev] | [next] | [standalone]

#1633

On Thursday, September 19, 2013 2:28:21 AM UTC-5, Mark Carroll wrote:
> luser- -droog <mijoryx@yahoo.com> writes:
> 
> 
> 
> > On Wednesday, September 18, 2013 9:50:59 PM UTC-5, Scott Hemphill wrote:
> 
> (snip)
> 
> >> Because empty arrays don't use any VM.  The pointer into the VM is null.
> 
> >
> 
> > Dammit! Mine prints 'false'. :(
> 
> 
> 
> I wonder if the language spec make a guarantee either way. Have you run
> 
> into any other interpreter issues where you were surprised to get some
> 
> latitude on which way to jump?
> 

Yes, indeed. This program is all the little examples verbatim
from the first edition Red Book (PLRM 1ed, checking that each
command produces the correct output from the manual.

http://code.google.com/p/xpost/source/browse/test.ps

There were lots of surprises for me. Particularly in the behavior
of simple things like `round`, where the obvious library function
was not the correct result. And names and strings comparing equal.

And a big one was making integer and reals equivalent as dictionary keys.
That one I haven't found in the manual, but ghostscript does it. :)

[toc] | [prev] | [next] | [standalone]

#1634

On Thursday, September 19, 2013 4:06:30 AM UTC-5, luser- -droog wrote:
> On Thursday, September 19, 2013 2:28:21 AM UTC-5, Mark Carroll wrote:
> 
> > luser- -droog <mijoryx@yahoo.com> writes:
> 
> > 
> > > On Wednesday, September 18, 2013 9:50:59 PM UTC-5, Scott Hemphill wrote:
> > (snip)
> > >> Because empty arrays don't use any VM.  The pointer into the VM is null.
> > >
> > > Dammit! Mine prints 'false'. :(
> > 
> > I wonder if the language spec make a guarantee either way. Have you run
> > into any other interpreter issues where you were surprised to get some
> > latitude on which way to jump?
> 
> 
> Yes, indeed. This program is all the little examples verbatim
> from the first edition Red Book (PLRM 1ed, checking that each
> command produces the correct output from the manual.
> 
> http://code.google.com/p/xpost/source/browse/test.ps
> 
> There were lots of surprises for me. Particularly in the behavior
> of simple things like `round`, where the obvious library function
> was not the correct result. And names and strings comparing equal.

I think this is actually the opposite of what you were asking.
Until this part:

> And a big one was making integer and reals equivalent as dictionary keys.
> That one I haven't found in the manual, but ghostscript does it. :)

There were other issues that arose during the testing of xpost2, where
I tried to make it run the Bar Code Writer In Pure Postscript. 
In particular, you cannot predict what people are going to do with the stack.
Just because *you* wouldn't try to build a 40000 element array with 
bracket notation doesn't mean somebody else won't try.

So, the Appendices in the manual are very important. 
The Typical Implementation Limits tell you what sizes of
things user code is going to expect.

[toc] | [prev] | [next] | [standalone]

#1635

On Thursday, September 19, 2013 2:28:21 AM UTC-5, Mark Carroll wrote:
> luser- -droog <mijoryx@yahoo.com> writes:
> 
> 
> 
> > On Wednesday, September 18, 2013 9:50:59 PM UTC-5, Scott Hemphill wrote:
> (snip)
> >> Because empty arrays don't use any VM.  The pointer into the VM is null.
> >
> > Dammit! Mine prints 'false'. :(
> 
> I wonder if the language spec make a guarantee either way. Have you run
> into any other interpreter issues where you were surprised to get some
> latitude on which way to jump?
> 

In this case I think it's a side-effect of a memory-size optimization.
For mine, I had to add extra code to check the special case of a zero size
in the array allocator. Previously it would go ahead an allocate a pointer
to a zero-length portion of memory. Everything's bounds-checked so it's not
overlapping anything. But it had an address. So two of them would compare 
unequal.

[toc] | [prev] | [next] | [standalone]

#1640

How about empty dictionaries? Do they not use VM either? The reason I ask is that <<>><<>> eq returns false, not true.

-- Peter

On Wednesday, September 18, 2013 10:50:59 PM UTC-4, Scott Hemphill wrote:

> 
> 
> 
> > Hi all,
> 
> >
> 
> > I am writing a PostScript interpreter and I just ran into the following strange issue: 
> 
> >
> 
> > Apparently, a "standard" PostScript interpreter such as Photoshop, when running into the code
> 
> >
> 
> > [] [] eq
> 
> >
> 
> > returns true (which is unexpected), while the code
> 
> >
> 
> > [1] [1] eq 
> 
> >
> 
> > or
> 
> >
> 
> > [] [1] eq
> 
> >
> 
> > return false (which is expected.)
> 
> >
> 
> > Why would two empty arrays considered equal? Shouldn't they still occupy different areas of the VM?
> 
> 
> 
> Because empty arrays don't use any VM.  The pointer into the VM is null.
> 
> 
> 
> Scott
> 
> -- 
> 

> 
> "This isn't flying.  This is falling, with style."  -- Buzz Lightyear

[toc] | [prev] | [next] | [standalone]

#1641

On Saturday, September 21, 2013 1:28:30 PM UTC-5, ana...@gmail.com wrote:
> How about empty dictionaries? Do they not use VM either? The reason I ask is that <<>><<>> eq returns false, not true.
> 

[OT: typically, you should avoid "top-posting" on usenet as it
harms the structure of the thread.]

Empty dictionaries /do/ have a size. Even though no slots are
filled, it still needs a size to perform the hashing function.
Even though it may grow to a new size when filled, it will
have a definite (non-zero) size at any point.

The difference may owe something to dialects of Lisp where the
empty list is used like a null token. But there's (to my
knowledge) little common use for lots of empty dictionaries.
So there'd be little savings in space to expect from the extra
code to handle the special case.

[toc] | [prev] | [next] | [standalone]

#1643

luser- -droog <mijoryx@yahoo.com> writes:

> On Saturday, September 21, 2013 1:28:30 PM UTC-5, ana...@gmail.com wrote:
>> How about empty dictionaries? Do they not use VM either? The reason I ask is that <<>><<>> eq returns false, not true.
>> 
>
> [OT: typically, you should avoid "top-posting" on usenet as it
> harms the structure of the thread.]
>
> Empty dictionaries /do/ have a size. Even though no slots are
> filled, it still needs a size to perform the hashing function.
> Even though it may grow to a new size when filled, it will
> have a definite (non-zero) size at any point.

[snip]

I have a vague memory that PostScript level 1 as implemented in the
original Apple LaserWriter allocated 25% more slots for the dictionary
than the user asked for, for efficiency in the hashing algorithm.  The
minimum number of slots allocated was ten.  I don't recall if there is
anything in the standard.

Scott
-- 
Scott Hemphill	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web