Re: svn commit: r332747 - in /lucene/java/trunk: ./ src/java/org/apache/lucene/search/regex/ src/test/org/apache/lucene/search/regex/

On Tuesday 15 November 2005 00:04, Doug Cutting wrote: > [EMAIL PROTECTED] wrote: > > +23. Added regular expression queries, RegexQuery and SpanRegexQuery. > > +Note the same term enumeration caveats apply with these queries as > > +apply to WildcardQuery and other term expanding queries. >

[jira] Commented: (LUCENE-383) ConstantScoreRangeQuery - fixes "too many clauses" exception

[ http://issues.apache.org/jira/browse/LUCENE-383?page=comments#action_12357666 ] Yonik Seeley commented on LUCENE-383: - I have committed these classes. Unless I hear objections, I'll change the QueryParser to use ConstantScoreRangeQuery, and allow the

Re: svn commit: r332747 - in /lucene/java/trunk: ./ src/java/org/apache/lucene/search/regex/ src/test/org/apache/lucene/search/regex/

Erik Hatcher wrote: The downside is scoring closer matches (in say the WildcardQuery) would no longer be possible, right? Right. We could implement a scorer that keeps a byte array of scores instead of a bit vector, using Similarity.java's 8-bit float format. That would use more memory, but

Re: svn commit: r332747 - in /lucene/java/trunk: ./ src/java/org/apache/lucene/search/regex/ src/test/org/apache/lucene/search/regex/

On 14 Nov 2005, at 18:04, Doug Cutting wrote: [EMAIL PROTECTED] wrote: +23. Added regular expression queries, RegexQuery and SpanRegexQuery. +Note the same term enumeration caveats apply with these queries as +apply to WildcardQuery and other term expanding queries. +(Erik Hatc

Re: svn commit: r332747 - in /lucene/java/trunk: ./ src/java/org/apache/lucene/search/regex/ src/test/org/apache/lucene/search/regex/

I'm in favor of that... I think it's fine to eliminate most of the relevancy factors (like idf(), tf(), etc) from range and wildcard type queries. The biggest drawback is that index time boosts are disabled, but I think having queries that can work 100% of the time is more important. I'll work on

Lucene and Latent Semantic Indexing

I'm currently experimenting with latent semantic indexing techniques and Lucene. I need to extract term frequencies from a Lucene index and construct a document/term matrix, then subsequently perform some mathematical algorithms on this matrix which produces float and potentially negative term freq

Re: svn commit: r332747 - in /lucene/java/trunk: ./ src/java/org/apache/lucene/search/regex/ src/test/org/apache/lucene/search/regex/

[EMAIL PROTECTED] wrote: +23. Added regular expression queries, RegexQuery and SpanRegexQuery. +Note the same term enumeration caveats apply with these queries as +apply to WildcardQuery and other term expanding queries. +(Erik Hatcher) I don't like adding more error-prone stuff lik

[jira] Commented: (LUCENE-323) [PATCH] MultiFieldQueryParser and BooleanQuery do not provide adequate support for queries across multiple fields

[ http://issues.apache.org/jira/browse/LUCENE-323?page=comments#action_12357635 ] Chuck Williams commented on LUCENE-323: --- The code only uses bubble sort for the incremental resorting of an already-sorted list. The initial sort is done with Arrays.so

[jira] Updated: (LUCENE-353) Locking bug

[ http://issues.apache.org/jira/browse/LUCENE-353?page=all ] [EMAIL PROTECTED] updated LUCENE-353: -- Attachment: LockTest.java Did not realize it was fixed already. Just in case if someone wants to check it in: this is a unit test that shows origina

[jira] Commented: (LUCENE-323) [PATCH] MultiFieldQueryParser and BooleanQuery do not provide adequate support for queries across multiple fields

[ http://issues.apache.org/jira/browse/LUCENE-323?page=comments#action_12357618 ] Yonik Seeley commented on LUCENE-323: - I'd rather have something right now that worked well for a small number clauses, even if it didn't scale to a large number of claus

[jira] Updated: (LUCENE-323) [PATCH] MultiFieldQueryParser and BooleanQuery do not provide adequate support for queries across multiple fields

[ http://issues.apache.org/jira/browse/LUCENE-323?page=all ] Yonik Seeley updated LUCENE-323: Attachment: DisjunctionMaxQuery.java DisjunctionMaxScorer.java TestDisjunctionMaxQuery.java Changes: - renamed MaxDisjunction* t

[jira] Updated: (LUCENE-465) surround test code is incompatible with *Test pattern in test target.

[ http://issues.apache.org/jira/browse/LUCENE-465?page=all ] paul.elschot updated LUCENE-465: Attachment: BooleanQueryTst.java ExceptionQueryTst.java SrndRenameTestPatch1.txt Renamed files, patch to use the new class names

[jira] Created: (LUCENE-465) surround test code is incompatible with *Test pattern in test target.

surround test code is incompatible with *Test pattern in test target. - Key: LUCENE-465 URL: http://issues.apache.org/jira/browse/LUCENE-465 Project: Lucene - Java Type: Bug Components: Other

[jira] Commented: (LUCENE-323) [PATCH] MultiFieldQueryParser and BooleanQuery do not provide adequate support for queries across multiple fields

[ http://issues.apache.org/jira/browse/LUCENE-323?page=comments#action_12357611 ] paul.elschot commented on LUCENE-323: - There is an issue with the MaxDisjunctionScorer in the .zip attachment, I'm sorry I did not see this earlier when I posted on java-de

Re: Highlighter using spans

I might mention that, if you're converting your query to spans anyway, you could avoid running it twice (once over the document set, another time for highlighting) by using it as a main query and recording the spans as you go along. I'm not sure this is better, but it's what XTF uses. --Martin O