[ https://issues.apache.org/jira/browse/LUCENE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671630#action_12671630 ]
Yonik Seeley commented on LUCENE-1470: -------------------------------------- I *think* the range splitting code I wrote is generic enough to also automatically handle 32 bits too. I think it's just a matter of starting with a different shift? So for longs we have: {code} public static Object buildRange(RangeBuilder builder, long ll, long uu, int precisionStep) { // figure out where to start shift at int shift = ((64-1)/precisionStep) * precisionStep; return buildRange(builder, ll, uu, shift, precisionStep); } {code} And for ints, it would simply (hopefully) be: {code} public static Object buildRange(RangeBuilder builder, int ll, int uu, int precisionStep) { // figure out where to start shift at int shift = ((32-1)/precisionStep) * precisionStep; return buildRange(builder, (long)ll, (long)uu, shift, precisionStep); } {code} Does that sound right? > Add TrieRangeQuery to contrib > ----------------------------- > > Key: LUCENE-1470 > URL: https://issues.apache.org/jira/browse/LUCENE-1470 > Project: Lucene - Java > Issue Type: New Feature > Components: contrib/* > Affects Versions: 2.4 > Reporter: Uwe Schindler > Assignee: Uwe Schindler > Fix For: 2.9 > > Attachments: fixbuild-LUCENE-1470.patch, fixbuild-LUCENE-1470.patch, > LUCENE-1470-readme.patch, LUCENE-1470.patch, LUCENE-1470.patch, > LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch, LUCENE-1470.patch, > LUCENE-1470.patch, TrieRangeFilter.java, TrieUtils.java, TrieUtils.java, > TrieUtils.java, TrieUtils.java, TrieUtils.java > > > According to the thread in java-dev > (http://www.gossamer-threads.com/lists/lucene/java-dev/67807 and > http://www.gossamer-threads.com/lists/lucene/java-dev/67839), I want to > include my fast numerical range query implementation into lucene > contrib-queries. > I implemented (based on RangeFilter) another approach for faster > RangeQueries, based on longs stored in index in a special format. > The idea behind this is to store the longs in different precision in index > and partition the query range in such a way, that the outer boundaries are > search using terms from the highest precision, but the center of the search > Range with lower precision. The implementation stores the longs in 8 > different precisions (using a class called TrieUtils). It also has support > for Doubles, using the IEEE 754 floating-point "double format" bit layout > with some bit mappings to make them binary sortable. The approach is used in > rather big indexes, query times are even on low performance desktop > computers <<100 ms (!) for very big ranges on indexes with 500000 docs. > I called this RangeQuery variant and format "TrieRangeRange" query because > the idea looks like the well-known Trie structures (but it is not identical > to real tries, but algorithms are related to it). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org