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

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

Re: best dictionary algorithm?

Started byThomasW <zupftom@googlemail.com>
First post2011-01-30 07:44 -0800
Last post2011-02-03 00:46 -0800
Articles 5 — 3 participants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: best dictionary algorithm? ThomasW <zupftom@googlemail.com> - 2011-01-30 07:44 -0800
    Re: best dictionary algorithm? luser- -droog <mijoryx@yahoo.com> - 2011-02-03 00:32 -0800
      Re: best dictionary algorithm? ken <ken@spamcop.net> - 2011-02-03 10:01 +0000
      Re: best dictionary algorithm? ken <ken@spamcop.net> - 2011-02-03 09:57 +0000
      Re: best dictionary algorithm? luser- -droog <mijoryx@yahoo.com> - 2011-02-03 00:46 -0800

#1675 — Re: best dictionary algorithm?

FromThomasW <zupftom@googlemail.com>
Date2011-01-30 07:44 -0800
SubjectRe: best dictionary algorithm?
Message-ID<e8e27cac-b69f-4d6f-bd8b-c13d06fadf73@d28g2000yqc.googlegroups.com>
On 21 Jan., 08:13, ThomasW <zupf...@googlemail.com> wrote:
>
> I've not dealt with this in depth and I don't know how you're
> representing objects, so maybe I'm talking nonsense.  Anyway, I'd
> imagine you have a struct where, say, one byte stores the type of the
> object and, say, four bytes store the value of the object (which would
> be an integer/float/boolean etc. for simple types and a VM address for
> composite objects).  [...] Those five bytes would uniquely identify the key,
> wouldn't they?

I've not taken into account integer and floating point objects.  As
they are regarded as the same key if they have the same value, the raw
bytes can't be used for lookup.

[toc] | [next] | [standalone]

#1694

Fromluser- -droog <mijoryx@yahoo.com>
Date2011-02-03 00:32 -0800
Message-ID<da49c190-2511-4cd5-9137-da7f14fabaed@s11g2000yqh.googlegroups.com>
In reply to#1675
On Jan 30, 9:44 am, ThomasW <zupf...@googlemail.com> wrote:
> On 21 Jan., 08:13, ThomasW <zupf...@googlemail.com> wrote:
>
>
>
> > I've not dealt with this in depth and I don't know how you're
> > representing objects, so maybe I'm talking nonsense.  Anyway, I'd
> > imagine you have a struct where, say, one byte stores the type of the
> > object and, say, four bytes store the value of the object (which would
> > be an integer/float/boolean etc. for simple types and a VM address for
> > composite objects).  [...] Those five bytes would uniquely identify the key,
> > wouldn't they?
>
> I've not taken into account integer and floating point objects.  As
> they are regarded as the same key if they have the same value, the raw
> bytes can't be used for lookup.

That's not true is it?
That was one of Goswell's assumptions and it seems reasonable
to hold distinct types as distinct keys.

Let's see. What does ghostscript do?
GPL Ghostscript 8.62 (2008-02-29)
Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>1 42 def
GS>1.0 load
GS<1>=
42
GS>

Well, I'll be damned! Look at that!
That's got to be some evil voodoo.

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

#1698

Fromken <ken@spamcop.net>
Date2011-02-03 10:01 +0000
Message-ID<MPG.27b48d54adf27d0989814@usenet.plus.net>
In reply to#1694
In article <b3570de8-babe-4b91-b19b-
8d9a5c0bbece@r16g2000yql.googlegroups.com>, mijoryx@yahoo.com says...
> But the bad news is it chokes on an integer that
> exceeds the precision of a real.
> 
> GS>16#7ffffff0 42 def
> GS>16#7ffffff0 cvr load
> Error: /undefined in --execute--
> Operand stack:
>    2.14748e+09

And the Distiller result:

%%[ Error: undefined; OffendingCommand: load ]%%

Stack:
2.14748e+09

 
> But using the integer still works:
> 
> GS>16#7ffffff0 load
> GS<1>=
> 42

Again, Acrobat Distiller has the same result.


			Ken

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

#1702

Fromken <ken@spamcop.net>
Date2011-02-03 09:57 +0000
Message-ID<MPG.27b48c6bbe1c3dc6989813@usenet.plus.net>
In reply to#1694
In article <da49c190-2511-4cd5-9137-
da7f14fabaed@s11g2000yqh.googlegroups.com>, mijoryx@yahoo.com says...

> That's not true is it?
> That was one of Goswell's assumptions and it seems reasonable
> to hold distinct types as distinct keys.
> 
> Let's see. What does ghostscript do?
> GPL Ghostscript 8.62 (2008-02-29)
> Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> GS>1 42 def
> GS>1.0 load
> GS<1>=
> 42
> GS>
> 
> Well, I'll be damned! Look at that!
> That's got to be some evil voodoo.

Adobe Acrobat Distiller does exactly the same. Not conclusive but 
indicative that this is intended behaviour.


		Ken

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

#1705

Fromluser- -droog <mijoryx@yahoo.com>
Date2011-02-03 00:46 -0800
Message-ID<b3570de8-babe-4b91-b19b-8d9a5c0bbece@r16g2000yql.googlegroups.com>
In reply to#1694
On Feb 3, 2:32 am, luser- -droog <mijo...@yahoo.com> wrote:
> On Jan 30, 9:44 am, ThomasW <zupf...@googlemail.com> wrote:
>
> > On 21 Jan., 08:13, ThomasW <zupf...@googlemail.com> wrote:
>
> > > I've not dealt with this in depth and I don't know how you're
> > > representing objects, so maybe I'm talking nonsense.  Anyway, I'd
> > > imagine you have a struct where, say, one byte stores the type of the
> > > object and, say, four bytes store the value of the object (which would
> > > be an integer/float/boolean etc. for simple types and a VM address for
> > > composite objects).  [...] Those five bytes would uniquely identify the key,
> > > wouldn't they?
>
> > I've not taken into account integer and floating point objects.  As
> > they are regarded as the same key if they have the same value, the raw
> > bytes can't be used for lookup.
>
> That's not true is it?
> That was one of Goswell's assumptions and it seems reasonable
> to hold distinct types as distinct keys.
>
> Let's see. What does ghostscript do?
> GPL Ghostscript 8.62 (2008-02-29)
> Copyright (C) 2008 Artifex Software, Inc.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> GS>1 42 def
> GS>1.0 load
> GS<1>=
> 42
> GS>
>
> Well, I'll be damned! Look at that!
> That's got to be some evil voodoo.

But the bad news is it chokes on an integer that
exceeds the precision of a real.

GS>16#7ffffff0 42 def
GS>16#7ffffff0 cvr load
Error: /undefined in --execute--
Operand stack:
   2.14748e+09
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--   --
nostringval--   %loop_continue   1785   2   3   %oparray_pop   --
nostringval--   --nostringval--   false   1
%stopped_push   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1152/1684(ro)(G)--   --dict:0/20(G)--   --dict:94/200(L)--
Current allocation mode is local
Last OS error: 2
Current file position is 21

But using the integer still works:

GS>16#7ffffff0 load
GS<1>=
42

But I also get a rangecheck converting back and forth
so the undefined above isn't so terrible.

GS>16#7ffffff0 cvr cvi
Error: /rangecheck in --execute--
Operand stack:
   2.14748e+09
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--   --
nostringval--   %loop_continue   1785   2   3   %oparray_pop   --
nostringval--   --nostringval--   false   1
%stopped_push   .runexec2   --nostringval--   --nostringval--   --
nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1152/1684(ro)(G)--   --dict:0/20(G)--   --dict:94/200(L)--
Current allocation mode is local
Current file position is 20
GS<1>

[toc] | [prev] | [standalone]

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

csiph-web