Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!stadler
From: stadler@Apple.COM (Andy Stadler)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Hypercard FIND problems...
Message-ID: <43371@apple.Apple.COM>
Date: 27 Jul 90 00:25:31 GMT
References: <3747.26af01bd@wums2.wustl.edu>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 32

In article <3747.26af01bd@wums2.wustl.edu> thomas_m@wums2.wustl.edu writes:
>
>  [..VERY astute observation that searching for 1 or 2 char strings is
>     substantially slower than searching for 3 or more char strings..]
>
>	My question basically is (are), 1) Why is hypercard doing this, and 2)
>what can be done to get around this problem so that hypercard searchs as fast
>as it does with >2 character strings?

Basically, this behavior was "designed in" to HyperCard from the very earliest
days of its design.  There is a special encoding of the text on all cards,
called the "hint bits".  The "hint bits" are all stored in one place, so in a
search, HyperCard can just load and search a single object instead of skipping
and reading all over the disk, checking every single ascii character.

As with any "hashed" search data, you must make a tradeoff and discard some
percentage of the discrete data.  During the early design phase, Bill & co.
observed that people rarely if ever searched for single or double characters.
So the hint bits encode letters in groups of threes (called trigrams).  Any
word with less than three letters is simply discarded from the hints.

Enough of the internal technical details.  The fact is, HyperCard contains many
tradeoffs and unfortunately you've hit one.  Really, the only solution is to
make sure you search targets are 3 or more characters.

>	The reason that we use "."s in the fields is because we are naming cell
>lines and that is the standard way of terming them.  Any help would be greatly
>appreciated.

Perhaps you could re-encode the data in threes?  Like XXX.XXX.XXX ?

--Andy    stadler@apple.com