On Wed, Nov 01, 2006, Yonik Seeley wrote about "Re: Indexing floating point
number":
> > longer strings than Solr's NumberTools. Moving to base 100 or even 256
> > (as I suggest in the comments) can eliminate this difference.
>
> Or higher, depending on what you are optimizing for.
> If you are going to hold String instances in memory (like the
> FieldCache does) it's probably better to use more of those 16 bit
> chars.
This is a good point. I was thinking byte arrays, but indeed terms are
Strings, not byte arrays.
> >4. My code is probably a bit slower, though I didn't actually check.
>
> It would be nice to get rid of those Math.log() and Math.exp() calls...
> things like mantissa and exponent can be obtained directly from the float
> bits.
Well, it really depends what is your bottleneck. In my application, where
there is barely a handful of numeric fields, this slow encoding is shadowed
by the much slower process of indexing the document itself. Not to mention
that what usually really matters is the speed of the search or sort, not the
speed of the one-time indexing.
--
Nadav Har'El | Thursday, Nov 2 2006, 11 Heshvan 5767
IBM Haifa Research Lab |-----------------------------------------
|Christopher Robin Hood steals from the
http://nadav.harel.org.il |rich and gives to the Pooh.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
