Re: Dictionary, hashing limitations



Bruce McFarling <agila61@xxxxxxxxxxxx> wrote:
Jonah Thomas <j2tho...@xxxxxxxxxx> wrote:

If it works for 0-255 then you can provide users with associative
arrays that allow absolutely anything for a key (with only the
length limitation). If it works for 33-126 then it still allows
any text string < 32 characters, which isn't shabby.

Of course, if it works for text strings up to 31 characters, then it
works for unsigned uunecoded natural numbers of up to 155 bits.

Sure, that works. But it's an extra step, and it isn't that hard to
build your own binary tree or whatever and solve your problem all on
your own.

And if you want to port your program then you'd like to have the
low-level dictionary words that aren't currently standardised, and you
don't know what kind of associative array you'll get -- you might port
it to a system where it's just a linked list, or it might use a hashing
algorithm that your particular keys work badly with. If a linked list is
acceptable you can make your own linked list easily without jumping
through hoops to use the system's dictionary.

And of course lots of target compilers won't have a dictionary on the
target at all.

I like the idea of making the system internals maximally useful for
applications, and at some point that approach breaks. I'm curious where
that point comes for the dictionary. Clearly you can do anything you
want provided you design your values as Forth words and your keys as
Forth names.

There may not be much value in allowing associative arrays whose values
don't get executed -- to some extent constants, variables, values,
deferred words, create-does> words etc are objects. You usually don't
have to know what type they are; you can execute them and their own code
knows what to do. What you gain from bypassing this little bit of
overhead may not be worth it. But then again, the dictionary does
something clean and simple -- you give it a key and a value and it saves
them. Later you give it the key and it gives you the value. Why should
there be any unnecessary limitations on that? If the key is the contents
of any address/length pair, and the value is a bit-pattern (which might
be an execution token or an address but doesn't have to be), what harm
is done? Providing your particular hashing algorithm allows it.
.



Relevant Pages

  • Re: The Stowe Unitary System
    ... > For the first time I have been able to define all fundamental constants ... > in terms of basic medium parameters, ... fitting into a unified system. ... > Maxwell's aether. ...
    (sci.physics)
  • Re: The Stowe Unitary System
    ... > For the first time I have been able to define all fundamental constants ... > in terms of basic medium parameters, ... fitting into a unified system. ... > Maxwell's aether. ...
    (sci.astro)
  • Re: The Stowe Unitary System
    ... > For the first time I have been able to define all fundamental constants ... > in terms of basic medium parameters, ... fitting into a unified system. ... > Maxwell's aether. ...
    (sci.physics.relativity)
  • Re: Whats this C code?
    ... this type of arrays ... Usually an attacker exploits some unprotected buffers, ... OS to execute arbitrary code. ... This is the cornerstone documentation, ...
    (Security-Basics)
  • Re: Damn you, FEDEX! or Nikon D40 lost in Springfield, MO blackhole.
    ... the 2 mp Mavica he had been using with a Nikon D40. ... After shopping around, he got me to order one for him. ... The shipper had it insured, but from what I have read it could take weeks to sort this crap out. ... You may get your insurance from FedEx and a couple weeks later they find it and deliver it. ...
    (alt.photography)

Loading