World: r3wp

find [ "ab" "bc" "bd" ] "b*"

looks like I should try and get a hash for each first letter, first 
and second letter etc so I can at least narrow it down to the first 
3 letters and then do search on everyone after that.

How many strings and what kind of performance do you need?

18,000 strings....  real time.... as each time they type a character 
I am presenting a list of choices

I am emulating this http://rxterms.nlm.nih.gov:8080/

have you thought about using SQLite?

I wonder how that would compare with doing REBOL lookups

I was just thinking that!

The example helps enormously Graham, because you said "first string" 
but now I see you want all matches for a given prefix.

once I get the first string .. then I can easily get the others as 
I sort the 18k strings first

is the existing sqlite driver work over the wire or does it do in 
process calls?

Maybe I need RIF

I've never used sqlite

I wonder if Ashley's rebdb would work ...

He doesn't have a like clause ... but I guess it could be faked

Graham, did you try REFORMing into a single string and using FIND/ANY? 
I did a quick test here and it's instant for me with 18K random "words" 
making a 200K string finding the last word (non-random for testing).

Hmmm, some of the terms aren't single words though.

In effect you've created an index

No, just a list of single-value records. :-)

Actually I wonder why find/any shouldn't work on series like these

Or you can say I created an index and the query system with two function 
calls.

You mean a block containing string values?

sure ..

>> help find
USAGE:

    FIND series value /part range /only /case /any /with wild /skip size 
    /match /tail /last /reverse

Doesn't say blocks are not included

But it's not find/deep, which is what you want.

for the /match refinement

Since it's a read only db, perhaps I could use Cyphre's compiler 
:)

Not sure how /match is going to help you here. It only matches the 
start of the series.

>> find/match ["Aa" "Bb" "Cc"] ["Bb"]
== none
>> find/match ["Aa" "Bb" "Cc"] ["Aa" "Bb"]
== ["Cc"]

ok... find/deep then :)

for 18k strings, it seems overkill to use sqlite though

REFORM + FIND/ANY

Just sayin'. ;-)

I'm sure that it is fast .. but I want real fast so I'm going to 
see if I can create a hash

Perhaps Sunanda's skimp.r may be hiding some gems you could adopt.

Graham -- consider using a Trie

[that is more-or-less what skimp.r does, but the skimp data structures 
are badly disorted as I was struggling to find a deeply-nested block 
structure that did not trigger garbage collection bugs in the then-current 
REBOL core. (those bugs have been fixed)]
   http://en.wikipedia.org/wiki/Trie

is there a port scheme for trie:// ?

Graham, look at the filter function in LIST-VIEW.

filter-list ?

no, FILTER.

sorry, FILTER-ROWS.

I guess it's been split in several parts now, so it may be too hard 
to read.

Graham, I did that recently, where you get choices as you type. I 
had ~1000 strings though, so not sure how much it scales. I just 
indexed by the first two characters.

It seems to be working not too bad for me without a hash .. but I'll 
need to test it on a slower PC ( test inside a VM I guess ) ...

video of my current implementation http://screencast.com/t/ZGI5ZTJkOTct

Very nice Graham! Thanks for posting. 

How did you end up doing the matching?

search each one from the start :)

rebol seems fast enough

Cool. Yeah, there are times we need to use advanced algorithms, and 
times we don't.

Carl has a character by character search in Rebodex.  Not sure if 
that is any better than what you have done.

G raham a suffix tree may be what tou want for trem compleation