[
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
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
: 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
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
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
: 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
> 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
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
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
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 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
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
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
[
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
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:
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.
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
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
[
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
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.
--
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-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
[
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
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-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
26 matches
Mail list logo
