[
http://issues.apache.org/jira/browse/LUCENE-129?page=comments#action_12357858 ]
Esmond Pitt commented on LUCENE-129:
Apparently I haven't made myself clear. It is essential that any finalizer
calls super.finalize() regardless of any exceptions it may
Hi
Lately committed
class *DisjunctionMaxQuery *
implements missing from svn *Iterable* interface
--
regards,
Volodymyr Bychkoviak
Iterable is in java.lang since the collection classes where added (in
jdk 1.4 I believe).
Lucene trunk also depends on 1.4 so there should be no problem.
Luc
-Original Message-
From: Volodymyr Bychkoviak [mailto:[EMAIL PROTECTED]
Sent: donderdag 17 november 2005 10:55
To: java-dev@lucene
I found problem.
Iterable is part of 1.5 jdk
but AFAIK lucene is compatible with 1.4.
Vanlerberghe, Luc wrote:
Iterable is in java.lang since the collection classes where added (in
jdk 1.4 I believe).
Lucene trunk also depends on 1.4 so there should be no problem.
Luc
-Original Message
Iterable was first added in jdk 1.5.
Liam
Vanlerberghe, Luc wrote:
Iterable is in java.lang since the collection classes where added (in
jdk 1.4 I believe).
Lucene trunk also depends on 1.4 so there should be no problem.
Luc
-Original Message-
From: Volodymyr Bychkoviak [mailto:[EMAIL
Negative, java.lang.Iterable was added in JDK 1.5. I sure hope that the
next version of Lucene will not depend on JDK5...
/Ronnie
Vanlerberghe, Luc wrote:
Iterable is in java.lang since the collection classes where added (in
jdk 1.4 I believe).
Lucene trunk also depends on 1.4 so there should
Oops. Iterator exists since 1.4 but Iterable was indeed only added in
1.5
So the Iterator iterator() method can be left in, but the 'implements
Iterable' should be remove for now.
Luc
-Original Message-
From: Volodymyr Bychkoviak [mailto:[EMAIL PROTECTED]
Sent: donderdag 17 november 2
There two more places where Iterable is used.
I think this class should be refactored by author ;)
Vanlerberghe, Luc wrote:
Oops. Iterator exists since 1.4 but Iterable was indeed only added in
1.5
So the Iterator iterator() method can be left in, but the 'implements
Iterable' should be remo
[
http://issues.apache.org/jira/browse/LUCENE-415?page=comments#action_12357882 ]
Andy Hind commented on LUCENE-415:
--
And I can reproduce it .on 1.4.3
When FSDirectory.createFile creates a FSOutputStream the random access file may
already exist and co
[
http://issues.apache.org/jira/browse/LUCENE-467?page=comments#action_12357911 ]
Yonik Seeley commented on LUCENE-467:
-
Here is a new version that's faster by keeping the mantissa and exponent
together. It's fast-path does a single shift and a single a
[
http://issues.apache.org/jira/browse/LUCENE-467?page=comments#action_12357917 ]
Doug Cutting commented on LUCENE-467:
-
How fast can you make:
public byte floatToByte(float f, int numMantissaBits);
?
That would be more reusable, and shouldn't be much
[
http://issues.apache.org/jira/browse/LUCENE-467?page=comments#action_12357920 ]
Yonik Seeley commented on LUCENE-467:
-
> How fast can you make: public byte floatToByte(float f, int numMantissaBits);
With Java5 and -server -Xbatch, just as fast as the
[
http://issues.apache.org/jira/browse/LUCENE-467?page=comments#action_12357925 ]
Paul Smith commented on LUCENE-467:
---
If you can create a patch against 1.4.3 there is a reasonable possibility that
I could create a 1.4.3 Lucene+ThisPatch jar and re-index
[
http://issues.apache.org/jira/browse/LUCENE-467?page=comments#action_12357926 ]
Yonik Seeley commented on LUCENE-467:
-
Here's a version that further generalizes the exponent zero point (below are
negative exponents, above are positive), and includes t
> The float epsilon should ideally be greater than the minimum score
> increment,
I'm not sure I understand why this is. epsilon is based on 1,
(smallest number such that 1-epsilon != 1, right?). What's special
about 1?
I'm worried about the impact of things like this:
smallfloat(10) + smallfl
Yonik Seeley wrote:
I'm not sure I understand why this is. epsilon is based on 1,
(smallest number such that 1-epsilon != 1, right?). What's special
about 1?
1 is special for multiplication, but, you're right, not so special for
addition, the operation in question. The thing that makes addi
Here are some alternatives with a bias toward positive exponents (am I
right in thinking we need more positive than negative exponents?)
It looks like something with 4 mantissa bits might be better for
scoring calculations
Thoughts?
mantissa_bits=4, zeroExp=4:
1) 0.0021972656
2) 0.0024414062
Yonik Seeley wrote:
mantissa_bits=4, zeroExp=4:
1) 0.0021972656
2) 0.0024414062
70) 0.875
71) 0.9375
72) 1.0
73) 1.125
74) 1.25
75) 1.375
76) 1.5
254) 7340032.0
255) 7864320.0
This would be a good choice. I think the following is also a contender:
mantissa_bits=5, zeroExp=2:
1) 0.033203125
2)
Heh. Mid air collision...
On 11/17/05, Doug Cutting <[EMAIL PROTECTED]> wrote:
> Yonik Seeley wrote:
> > I'm worried about the impact of things like this:
> > smallfloat(10) + smallfloat(1) + smallfloat(1) + smallfloat(1) -> 10
> >
> > And it makes things very order dependent:
> > smallfloat(1)
Yonik Seeley wrote:
Hmmm, is .03->2000 really enough range?
Seems like the choice is between that and .0005->200 will one less
mantissa bit.
Consider the failure modes:
With the .0005->200 range we'll fail to distinguish close-scoring
matches in more commmon score ranges, while more c
Do you think that underflow should map to the smallest representable
number (like norm encoding does) or 0?
The bit vector will keep track of matches, so we don't need a non-zero
score for that (and a field boost of 0 is valid anyway AFAIK),
but on the other hand, higher level scoring routines som
Yonik Seeley wrote:
Do you think that underflow should map to the smallest representable
number (like norm encoding does) or 0?
The smallest representable, I think.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project lucene-java has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project lucene-java has an issue affecting its community integration.
This issue affects
Gack!
I specifically checked the Iterable interface, and I could have sworn
it said since Java 1.2!
My eyes must be playing tricks on me. I'll fix it.
> cannot resolve symbol
> [javac] symbol : class Iterable
> [javac] location: class org.apache.lucene.search.DisjunctionMaxQuery
-Yonik
It's fixed now.
Sorry bout that... I've already set up a test script to switch my JDK
to 14 before running "ant test".
On 11/18/05, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Gack!
> I specifically checked the Iterable interface, and I could have sworn
> it said since Java 1.2!
> My eyes must be pl
: It's fixed now.
: Sorry bout that... I've already set up a test script to switch my JDK
: to 14 before running "ant test".
I don't remember the specifics, but isn't there an attribute for the and
taks that you can use to tell it wether you want it to compile as
1.4 code or 1.5 code? ... I thou
27 matches
Mail list logo
