[
https://issues.apache.org/jira/browse/LUCENE-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669906#action_12669906
]
Mark Harwood commented on LUCENE-1532:
--
Surely the biggest factor in picking the righ
eks dev wrote:
Thanks for confirming it.
That is good to know and I am sure there are good reasons for it
(performance). Anyhow, sounds like good mouse trap that probably
deserves a few comments in javadoc.
- From the fact that term exists in term dictionary one cannot
conclude that th
[
https://issues.apache.org/jira/browse/LUCENE-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670027#action_12670027
]
Michael McCandless commented on LUCENE-1484:
bq. Is there any chance this patc
[
https://issues.apache.org/jira/browse/LUCENE-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1506.
Resolution: Fixed
Fix Version/s: 2.9
Lucene Fields: [New, Patch Availabl
A simple way to make BitVector faster would be to turn the get method
bounds checking into an assertion. This is similar to
OpenBitSet.fastGet.
I think that makes sense. I'll wait a day or so and then commit it if
there are no objections.
Mike
Jason Rutherglen wrote:
A simple way to make BitVector faster would be to turn the get method
bounds checking into an assertion. This is similar to
OpenBitSet.fastGet.
--
[
https://issues.apache.org/jira/browse/LUCENE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670080#action_12670080
]
Mark Miller commented on LUCENE-1398:
-
I like the idea of adding this, but I almost th
Do you mean the assert statement? That's available since 1.4.
Mike
Andi Vajda wrote:
Isn't that depending on Java 1.5 ?
Andi..
On Feb 3, 2009, at 11:38, Michael McCandless > wrote:
I think that makes sense. I'll wait a day or so and then commit it
if there are no objections.
Mike
I look into it shortly, this is my fault when I updated the test the last
time I think.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent:
I just had this failure happen:
[junit] Testcase:
testRangeSplit_4bit(org.apache.lucene.search.trie.TestTrieRangeQuery):
FAILED
[junit] Returned count of range query must be equal to exclusive
range length expected:<0> but was:<-1>
[junit] junit.framework.AssertionFailedError:
Tell me about it! We gotta get 2.9/3.0 out, so we can switch to 1.5.
The 1.5/1.6 line is less blurry :)
Mike
Andi Vajda wrote:
On Tue, 3 Feb 2009, Michael McCandless wrote:
Do you mean the assert statement? That's available since 1.4.
Yeah, that's what I meant. 1.5 vs 1.4 is gettin
Hi Mike,
I fixed the test. The problem was as you noted because of the both-sides
exclusive range:
assertEquals("Returned count of range query must be equal to exclusive
range length", tTopDocs.totalHits, Math.max(upper-lower-1, 0) );
Your fix was not enough, because the test then would fa
Isn't that depending on Java 1.5 ?
Andi..
On Feb 3, 2009, at 11:38, Michael McCandless
wrote:
I think that makes sense. I'll wait a day or so and then commit it
if there are no objections.
Mike
Jason Rutherglen wrote:
A simple way to make BitVector faster would be to turn the get
On Tue, 3 Feb 2009, Michael McCandless wrote:
Do you mean the assert statement? That's available since 1.4.
Yeah, that's what I meant. 1.5 vs 1.4 is getting blurry :)
Andi..
Mike
Andi Vajda wrote:
Isn't that depending on Java 1.5 ?
Andi..
On Feb 3, 2009, at 11:38, Michael McCandless
We should probably have that discussion (changing default Sim) on java-
dev, not on a particular JIRA issue. I, for one, am interested in
having the discussion.
On Feb 3, 2009, at 3:35 PM, Doug Cutting (JIRA) wrote:
[ https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian
> I agree we should warn about this in the javadocs... can you work up a patch?
I'll give it a try, no promise when, changing job, moving...
> I plan to run some tests to figure out the performance tradeoffs here.
>
> We switched to iterator access for a toplevel filter, as of LUCENE-584, but
I used to favor determinism/repeatability (fixed seed to Random) too,
but I recently changed my mind.
By allowing Random to randomly seed itself, we effectively test a much
much larger space, ie every time we all run the test, it's different.
We can
potentially cast a much larger net than a f
eks dev wrote:
I agree we should warn about this in the javadocs... can you work
up a patch?
I'll give it a try, no promise when, changing job, moving...
I plan to run some tests to figure out the performance tradeoffs
here.
We switched to iterator access for a toplevel filter, as of
: By allowing Random to randomly seed itself, we effectively test a much
: much larger space, ie every time we all run the test, it's different. We can
: potentially cast a much larger net than a fixed seed.
i guess i'm just in favor of less randomness and more iterations.
: Fixing the bug is t
: It's not repeatable, which is fine (because the test has randomness, which we
: should leave in there).
Side note: while i agree that test with randomness (ie: do lots of
iterations over randomly selected data) are good to help find weird edge
casees you might not otherwise think to explicitl
OK, no problem, thanks for fixing so quickly!
Mike
Uwe Schindler wrote:
Hi Mike,
I fixed the test. The problem was as you noted because of the both-
sides
exclusive range:
assertEquals("Returned count of range query must be equal to
exclusive
range length", tTopDocs.totalHits, Mat
Hi Andi,
> Isn't that depending on Java 1.5 ?
Assertions work since Java 1.4 I think. We have a lot of assertions in code.
And it would not compile with -source 1.4, as we do.
> wrote:
>
> >
> > I think that makes sense. I'll wait a day or so and then commit it
> > if there are no objections.
On Feb 3, 2009, at 7:17 PM, Chris Hostetter wrote:
: By allowing Random to randomly seed itself, we effectively test a
much
: much larger space, ie every time we all run the test, it's
different. We can
: potentially cast a much larger net than a fixed seed.
i guess i'm just in favor of
On java-user a question about "term frequency normalization" and changing
Similarity appeared, too.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Grant Ingersoll [mailto:gsing...@apache.org]
> Sent
[
https://issues.apache.org/jira/browse/LUCENE-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670103#action_12670103
]
Doug Cutting commented on LUCENE-1534:
--
Now, on the cusp of 3.0, might be a good time
[
https://issues.apache.org/jira/browse/LUCENE-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670240#action_12670240
]
Karl Wettin commented on LUCENE-1531:
-
Any objections to this patch? If not I'll pop i
26 matches
Mail list logo
