I guess it depends on "how" you get the stings in the
first place. In some situations, I'm sure you could
manage to "force" an integer "response" instead;
other times, I guess not. It probably has to do with
your mindset, and how you view the situation.

Joe Wilkins

"Edwards, Waverly" wrote:

> Yes, 99% of the time I know the text will match one
> of the case statements.  I tried a conversion of the
> string to a number but I lost time in the conversion
> before actually comparing to the hashed value.
>
> I either needed to come up with a faster hash so I
> could do a numeric comparison or forego the case
> statements by using a jump table, compensating for
> the computation time.
>
> After quite a bit of experimentation I figured that
> if I (or anyone else) had an idea for a jump table
> I might be able to beat the clock at a cost of code
> ugliness and loss of flexibility.
>
> W.
>
> -----Original Message-----
> From: Joe Lewis Wilkins [mailto:PepeToo@...]
> Sent: Tuesday, April 23, 2002 7:26 PM
> To: futurebasic@...
> Subject: Re: [FB] Fast lookups and jumps
>
> Hi Wave,
>
> Since you "appear" to know what the strings are, why not
> substitute integers for them, or even convert them to ascii
> numbers before you use the SELECT/CASE structure. Seems
> to me that they could become 1,2,3,4, etc.
>
> Or am I being too naive?
>
> Joe Wilkins
>
> "Edwards, Waverly" wrote:
>
> > I have the need for speed.  Does anyone have a
> > better idea for a jump table to replace a SELECT/CASE
> > structure?
> >
> > What I would like to do is to jump to a certain section
> > based on the contents of a string.  The string will be one
> > to four characters in length, all capitals.
> >
> > What I am doing now is easy and flexible but
> > I think there may be a faster, less flexible way to do
> > the same thing.  Ultimately, I want to see if I can gain
> > enough speed to warrant some ugly inflexible code.
> >
> > This is what I do now.
> >
> > SELECT myString$
> > CASE "BD"
> > // do this ...
> > CASE "LI"
> > // do this ...
> > CASE "SIMM"
> > // do this ...
> > CASE "XY"
> > // do this ...
> > CASE "D"
> > // do this ...
> > ....
> > ....
> > ....
> > // THERE ARE ABOUT 40 CASE STATEMENTS
> > // ORDERED BY FREQUENCY FOR SPEED.
> > ....
> > ....
> > END SELECT
> >
> > I get good speed now but I what I would like to do is something like
> > using an array as a lookup table
> >
> > hashVal = FN hashString(myString)
> >  // hash value is the index into array
> >
> > jumpAddr = myAddrLookup(hashVal)
> > // array will need to be large and mostly
> > // empty to support a direct relationship
> > // of hash value to index
> >
> > goto jumpAddr
> >
> > "BD"
> > // do this ...
> > EXIT FN
> > "LI"
> > // do this ...
> > EXIT FN
> > "SIMM"
> > // do this ...
> > EXIT FN
> >
> > The problem here is that it would take longer to compute the hash value
> > than it would to go through the select statements.  Unfortunately I cant
> > do this
> >
> > hashVal = [@myString +1]
> >
> > because the string length is variably one to four characters
> >
> > I cant do this
> >
> > select myString[0]  // string length
> > case 1
> >    hashVal = myString[1]
> > case 2
> >    hashVal = myString.1%
> > case 3
> >    // cant do three at all
> > case 4
> >   hashVal = myString.1&
> > end select
> >
> > because I use up time just testing the string length before I get to the
> > table lookup.
> >
> > I'm willing to sacrifice memory, inflexible and ugly code in order to
> > test the idea of getting nearly instantaneous jumps but none of the
> > ideas I have are fast.
> >
> > Any ideas?
> >
> > W.
> >
> > --
> > To unsubscribe, send ANY message to
> <futurebasic-unsubscribe@...>
>
> --
> To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>
>
> --
> To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>