Re: *hash() and binary stuff

• Date: Fri, 23 Feb 1996 13:03:48 PST
• From:
  ThwartedEfforts <abakun@scinc.com>
• Cc: moo-cows@parc.xerox.com
• Content-Type: text/plain; charset="us-ascii"

At 08:24 AM 2/23/96 PST, it was writen:
>ThwartedEfforts writes:
(my ramblings about hex and octal in bfs deleted)
>
>Well, I think of these as different cases, though perhaps I shouldn't.  I
>figured that you might conceivably want to decode the contents of a binary
>string (though you've got decode_binary() to do it for you, so...) whereas
>there's really pretty little point in decoding the output of *_hash().

I had intended to 'decode' the output of *_hash().
Actually, here's my story:
We needed a hash() function on E_MOO to speed the lookups of commands for
the in-database parser.  I was susposed to be provided with a function to do
this, but never was, then beta3 was released with series of hash functions.
Unfortunately, they all return strings, which kind of defeats the purpose of
using a hash function to speed string lookups.
I intended to truncate the returned value, and convert to a decimal value.

Of course, perhaps I'm mistaken... if the 'in' operator is used on a list of
numbers, wouldn't that be faster than a list of strings? (numbers would
definately be less space over 32 digit hex strings also)

4 in {1,2,3,4,5,6,7,8}
"1234DEF232" in {"43239ABFE323", "BF34A81ABF", "1234DEF232", "98FB5F3D45E"}

Right now, I'm looping over a series of lists, using a bf called
verbname_match(), which essentially calls the function elsewhere in the
server that does verb name matching and has the same name, on each string;
thus, doing a string compare.  I was hoping hashing could avoid the 400-800
or so string compares I do.

Perhaps a hex_to_dec() function? (then we'd need oct_to_dec() for
consistancy, and then dec_to_*() also). herf.

Andy

• Re: *hash() and binary stuff
• From: Pavel Curtis <pavel@parc.xerox.com>

• Prev: Re: *hash() and binary stuff
• Next: Re: *hash() and binary stuff
• Index: MOO-cows
• Thread: MOO-cows