Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of rcmuir@gmail.com designates
 209.85.216.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <7C09B40B9AF7446190E18140406F076D@JackKrupansky>
References: <1574581308.74146.1347527827817.JavaMail.jiratomcat@arcas>
 <alpine.DEB.2.02.1209131522190.415@frisbee>
 <CAOdYfZVw3557kXo3FsHJcXt-xXqkW-iKW2T8F929PoAepsN5KA@mail.gmail.com>
 <CA+NxCsMSqvg-WY3o6WcjbbfYVfiG3QVPK_d0k0QEpepkHHzUyg@mail.gmail.com>
 <7C09B40B9AF7446190E18140406F076D@JackKrupansky>
From: Robert Muir <rcmuir@gmail.com>
Date: Fri, 9 Nov 2012 19:37:33 -0500
Message-ID: 
 <CAOdYfZXz4wMkZawhyZ6X5QOih4odG3te-nRitXr6X5oRUKUWtQ@mail.gmail.com>
Subject: Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented]
 (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8

I'm -1 for having unscalable shit in lucene's core. This query should
have never been added.

I don't care if a few people complain because they aren't using
lowercasefilter or some other insanity. Fix your analysis chain. I
don't have any sympathy.

On Fri, Nov 9, 2012 at 7:35 PM, Jack Krupansky <jack@basetechnology.com> wrote:
> +1 for permitting a choice of fuzzy query implementation.
>
> I agree that we want a super-fast fuzzy query for simple variations, but I
> also agree that we should have the option to trade off speed for function.
>
> But I am also sympathetic to assuring that any core Lucene features be as
> performant as possible.
>
> Ultimately, if there was a single fuzzy query implementation that did
> everything for everybody all of the time, that would be the way to go, but
> if choices need to be made to satisfy competing goals, we should support
> going that route.
>
> -- Jack Krupansky
>
> From: Mark Bennett
> Sent: Friday, November 09, 2012 3:48 PM
> To: dev@lucene.apache.org
> Subject: Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira]
> [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.
>
> Hi Robert,
>
> On Thu, Sep 13, 2012 at 7:39 PM, Robert Muir <rcmuir@gmail.com> wrote:
>>
>> ...
>> ... I'm strongly against having this
>> unscalable garbage in lucene's core.
>>
>> There is no use case for ed > 2, thats just crazy.
>
>
> I promise you there ARE use cases for edit distances > 2, especially with
> longer words.  Due to NDA I can't go into details.
>
> Also ed>2 can be useful when COMBINING that low-quality part of the search
> with other sub-queries, or additional business rules.  Maybe instead of
> boiling an ocean this lets you just boil the sea.  ;-)
>
> I won't comment on the quality of the older Levenstein code, or the likely
> very slow performance, nor where the code should live, etc.
>
> But your statement about "no use case for ed > 2" is simply not true.
> (whether you'd agree with any of them or not is certainly another matter)
>
> I understand your concerns about not having it be the default.  (or maybe
> having a giant warning message or something, whatever)
>
>> --
>> lucidworks.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org