--- Doug  Baskins <doug / sourcejudy.com> wrote:
> Mauricio FernŠŌdez <batsman.geo / yahoo.com> wrote in message
> news:<20020902071849.GA20445 / kodos>...
> > On Mon, Sep 02, 2002 at 11:40:43AM +0900, Doug  Baskins wrote:
> > > After a posting I did yesterday, I decided to take a closer
> look
> > > at st_* library code.  Please correct me if I am wrong in the
> > > following discussion:
> > > 
> > >     The st_* library is a collection of "string" to "word"
> mapping
> > >     routines.  BUT, only the POINTER to the string is stored in
> the
> > >     internal st_* structures.  This implies that the comparison
> of the
> > >     pointer is enough to determine if the string is a match. 
> Now we are
> > >     in JudyL's territory (pointer to pointer mapping) instead
> of JudySL
> > >     (string to pointer mapping).  JudyL has been tuned!!!  I
> wrote the
> > >     st_* routines using JudyL and wrote a benchmark to compare
> with the
> > >     ruby-1.6.7 version of "st.c".  Since, JudyL does not have
> > >     collisions, there is no need for a collision structure.
> > [snip]
> > 
> > IMHO the st_* routines are meant to be more general than simple
> string->word
> > mapping :-( The key comparison function might be more complex
> than
> > bit-by-bit...
> 
> Ok, what could a compare routine do besides compare bit-by-bit in a
> hashed
> environment?

In Ruby any object can be the key; it is represented in C as a VALUE*
pointer (this would be the key). I suspect Ruby would call the <=>
method, which might be user-defined. I don't have the source handy so
I can't check this, but it's a reasonable belief IMO.

Plus the user might define strange semantics for its comparison
functions, for example for cache data and the like.

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com