Actually, I think we can totally do away with "variants" of 2,4,8 bits and make it completely generic, able to support any slice size from 1 to 63 bits.
I'll work up some prototype code and post it in the original TrieUtils JIRA issue. -Yonik On Sat, Feb 7, 2009 at 9:58 AM, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Sat, Feb 7, 2009 at 6:04 AM, Uwe Schindler <u...@thetaphi.de> wrote: >>> I understand how it works and how one would need to configure it such >>> that it be sortable if needed - but my point was really much more >>> about allowing people to do things differently if needed. >> >> Propose an API to generate the document fields, which should be simple for >> beginners (like now), but flexible! > > Simplicity for beginners can always be layered on top if enough power > and flexibility is exposed (my bias). > > // the first entry is full precision, the remaining entries have less > String[] trieCode(long sortableBits) > > long getSortableBits(long value) > long getSortableBits(double value) > long getSortableBits(Date date) > > // example usage: > String[] terms = trieCode(getSortableBits(1.4142135d)) > > This API concentrates on bit manipulation and term generation > (Strings) w/o getting into things like Fields and Documents. > > -Yonik > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
