[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657227#action_12657227
]
markrmil...@gmail.com edited comment on LUCENE-1483 at 12/16/08 4:30 PM:
---------------------------------------------------------------
bq. I think you can use an int for the ords? Now that we have subord, when you
get negative index back from binary search, you can set ord to -index-1 which
is the "lower bound", and then as long as subord is at least 1 it should
compare correctly.
Ah, indeed - no need for in the middle if you can fall to the subord. I think I
may have been thinking it would be nice not to fall through the ords so much,
but surly its worth losing double and doing the average. Seems to like -2 not
-1 though, then I start the subords at 1 rather than 0...I'll bring real
thought to it later, but thats generating some good looking results.
*EDIT*
Arg - with -2 one tests fails, with -1 it passes, but reverse sort fails :)
Prob is 1 one then, and I've got a small issue elsewhere.
bq. In your first pass, in the "else" clause (when the value was found in the
next segment) don't you need to set subord to 0?
hmm...I had that commented out as I was playing...let me think - if you don't
set it and multiple numbers don't map to clean new ords and they are the same,
it will fall to subords...so right, you wouldn't want an old subord around.
I'm hoping there is a lot more optimization we can do to the pure ords case,
but frankly I have low hopes for it - it should be a bit more competitive
though.
I'm going to take some time to finish up some other pieces and then come back
again I think. I've polished up the comparators a bit, so once I get some
other work in ill put up another rev.
was (Author: markrmil...@gmail.com):
bq. I think you can use an int for the ords? Now that we have subord, when
you get negative index back from binary search, you can set ord to -index-1
which is the "lower bound", and then as long as subord is at least 1 it should
compare correctly.
Ah, indeed - no need for in the middle if you can fall to the subord. I think I
may have been thinking it would be nice not to fall through the ords so much,
but surly its worth losing double and doing the average. Seems to like -2 not
-1 though, then I start the subords at 1 rather than 0...I'll bring real
thought to it later, but thats generating some good looking results.
bq. In your first pass, in the "else" clause (when the value was found in the
next segment) don't you need to set subord to 0?
hmm...I had that commented out as I was playing...let me think - if you don't
set it and multiple numbers don't map to clean new ords and they are the same,
it will fall to subords...so right, you wouldn't want an old subord around.
I'm hoping there is a lot more optimization we can do to the pure ords case,
but frankly I have low hopes for it - it should be a bit more competitive
though.
I'm going to take some time to finish up some other pieces and then come back
again I think. I've polished up the comparators a bit, so once I get some
other work in ill put up another rev.
> Change IndexSearcher to use MultiSearcher semantics for multiple subreaders
> ---------------------------------------------------------------------------
>
> Key: LUCENE-1483
> URL: https://issues.apache.org/jira/browse/LUCENE-1483
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.9
> Reporter: Mark Miller
> Priority: Minor
> Attachments: LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch
>
>
> FieldCache and Filters are forced down to a single segment reader, allowing
> for individual segment reloading on reopen.
--
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
