# *hash() and binary stuff

ThwartedEfforts (abakun@scinc.com)
Fri, 23 Feb 1996 13:03:48 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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