Subject: quick way to find an ascii value

From: [email-masked]
Date: Tue, 23 Nov 1993 09:05:15 -0800

I've been writing a little hash table for verb lookup.  One problem I've
encountered is that the whole idea of a hash table depends on a fast way to go
from a character to a number.  MOO doesn't have that as a built in function.

There's an easy hack around it.  You just define a property with the letters
of the alphabet on it and then find the position of the character in that
list.  i.e.:

letter in {"a", "b", "c", ...}

The problem of course is that the whole idea of a hash table is to avoid
looking up things in long lists!  Even using the silly method described,
lookup is sped up by a factor of as much as 8 for the worst case (the thing
not being there at all)-- 224 ticks with the table, 1868 without it.

In any case, there is a question lurking here: Seems like it would be pretty
easy to patch the server to add a new built in to go from a letter to its
ascii value.  How would I do that?

Thanks.

Amy

---

From: [email-masked]
Date: Tue, 23 Nov 1993 20:00:00 -0800

I think that people should not be telling Amy about things like "in" and
"index" which are functionally ok but are computationally too slow.  Even
if faster than what Amy was using before, and hence perhaps an incremental
improvement, these things do search and (ticks aside) search is inherently
slower than direct code access, which the underlying system clearly has
the information to be able to do.  I can't imagine that "index" or "in" is
going to be faster on average than the ascii function she's requesting.

You can't build a hash table that works in anywhere close to usefully
efficient time if you can't build hash table keys efficiently.  Making a
hash table that is only algorithmically fast (i.e., in big-O notation) but
that has a huge `constant' factor attached to the front is not very
exciting except to theorists.  [And even then it's only `constant' if
typical keys are of some bounded size.]

Of course, it wouldn't hurt MOO to have some form of table lookup
primitively.  Perhaps by making generic tables and then optimizing the
cases where keys are densely packed ranges of integers, characters, or
even pointers.  But in the absence of that, which seems like a bigger
thing, providing toascii and tochar and $max_ascii.  [I'd have suggested
modifying tonum instead of making a new function toascii, but apparently
tonum("a") already returns 0 (sigh...).]