Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 628E1DC76 for ; Sun, 11 Nov 2012 18:35:34 +0000 (UTC) Received: (qmail 64426 invoked by uid 500); 11 Nov 2012 18:35:33 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 64356 invoked by uid 500); 11 Nov 2012 18:35:33 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 64347 invoked by uid 99); 11 Nov 2012 18:35:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Nov 2012 18:35:32 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mbennett.ideaeng@gmail.com designates 209.85.212.182 as permitted sender) Received: from [209.85.212.182] (HELO mail-wi0-f182.google.com) (209.85.212.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Nov 2012 18:35:26 +0000 Received: by mail-wi0-f182.google.com with SMTP id hm9so1328577wib.5 for ; Sun, 11 Nov 2012 10:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Wb4oC1aZqtdKFnPEnaPoGOJV7Ie4foVwx5KBUiLcSuY=; b=M8QYB1c5PI0NUOa7dfytymF17yO+3jTGm7wqb3XCcPYvZ2W74uqr5Mmy3WIhzkV3iS Vhuhr52GhiXMVB+TmXnwOdjYwJUFlgjL7ZjuKQvMG1HMx7jLjl8njcva1qb0d+SzpTz3 tzlBZ/+IzAmz7WanoQ4cckU5snG/sqdRhYT9JnhdV8+v2RPhxj81+J6H0aqrJQr1Hgck C8I1006kCuI2e9iMkvRD7N3BtIBv+FaXZL5fmhGF5OWSYmBtG9HEvXPxZqu/GXz9FClf IZY5A4iF0fkIetqeZwuABYuqXJQ5PB7MmGuMgcIbaPi4NPS/fPVStkLJ9/UiHAP8w2/R XSrA== Received: by 10.180.7.194 with SMTP id l2mr11578556wia.0.1352658906013; Sun, 11 Nov 2012 10:35:06 -0800 (PST) MIME-Version: 1.0 Sender: mbennett.ideaeng@gmail.com Received: by 10.216.121.72 with HTTP; Sun, 11 Nov 2012 10:34:25 -0800 (PST) In-Reply-To: <0FEFB41EAFE84639A2521DE2A8AED6B5@JackKrupansky> References: <1574581308.74146.1347527827817.JavaMail.jiratomcat@arcas> <7C09B40B9AF7446190E18140406F076D@JackKrupansky> <007001cdbf8a$ab0891b0$0119b510$@thetaphi.de> <99C11B58493E4B59B8A8C61774C725D5@JackKrupansky> <009a01cdbffa$90bd0b90$b23722b0$@thetaphi.de> <0FEFB41EAFE84639A2521DE2A8AED6B5@JackKrupansky> From: Mark Bennett Date: Sun, 11 Nov 2012 10:34:25 -0800 X-Google-Sender-Auth: gmVosEb-tpx22c_etllwUR6zPH0 Message-ID: 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: multipart/alternative; boundary=90e6ba614138985f0804ce3c7101 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba614138985f0804ce3c7101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jack, The project uses both a bit of Lucene and then Solr. So as you suggest, I'd need a way to configure Solr to use the older fuzzy matching by default, and I'm not aware of such an option. The formula to go between percentage and integer edit distance is here: http://stackoverflow.com/questions/6087281 Some code: 3.6.1 contrib/spellchecker/src/java/org/apache/lucene/search/spell/LevensteinDist= ance.java 4.0.0 suggest/src/java/org/apache/lucene/search/spell/LevensteinDistance.java 4.0.0 suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.j= ava -- Mark Bennett / New Idea Engineering, Inc. / mbennett@ideaeng.com Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513 On Sun, Nov 11, 2012 at 7:18 AM, Jack Krupansky wr= ote: > Okay, so maybe this is simply a case where =93an adjustment=94 was made= to > Lucene and Solr did not make a corresponding =93adustment=94 to compensat= e to > =93preserve=94 functionality. Solr users cannot easily override factory > methods, but of course the Solr query parser can and probably should. > > I=92m not able to determine for sure whether Mark=92s comments were direc= ted > strictly at Lucene or Solr. I mean, for a lot of people there isn=92t rea= lly > supposed to be a distinction between the two. > > So, maybe we need a Solr Jira to the effect of adding a parameter such as > =93fuzzy.maxEdit=94 which defaults to =932=94, but could be set higher to= access > =93slow=94 fuzzy query. And, maybe that default should also be keyed off = of the > schema version or Lucene version so that an =93old=94 Solr app would see = no > loss of function, although there is the issue that old queries used a flo= at > correlation factor rather than an int edit distance. > > Is there a reliable formula for converting from the old correlation facto= r > and the new edit distance or at least a reasonable approximation? That > should be in the Javadoc. I suppose it could be approximated, but there a= re > edge cases where the new approach provides more discrimination that the o= ld > approach, such as for very short terms. > > -- Jack Krupansky > > *From:* Uwe Schindler > *Sent:* Sunday, November 11, 2012 2:51 AM > *To:* dev@lucene.apache.org > *Subject:* RE: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] > [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast. > > > Yes, if you override the factory method in the classic QueryParser. The > functionality is still available, you have to just use the classes direct= ly. > **** > > **** > > -----**** > > Uwe Schindler**** > > H.-H.-Meier-Allee 63, D-28213 Bremen**** > > http://www.thetaphi.de**** > > eMail: uwe@thetaphi.de**** > > **** > > *From:* Jack Krupansky [mailto:jack@basetechnology.com] > *Sent:* Sunday, November 11, 2012 6:14 AM > *To:* dev@lucene.apache.org > *Subject:* Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] > [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.**** > > **** > > =93we did not remove functionality=94**** > > **** > > Are you saying that full-featured =93classic=94 fuzzy query is still avai= lable > in the Lucene query parser? By default? Or via what option?**** > > > -- Jack Krupansky**** > > **** > > *From:* Uwe Schindler **** > > *Sent:* Saturday, November 10, 2012 1:30 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.**** > > **** > > Just use SlowFuzzyQuery from contrib, I really don=92t understand where t= he > issue is? The code is available in the sandbox/query module and is > available in Lucene 4.0. There is no reason to complain here, we did not > remove functionality.**** > > **** > > -----**** > > Uwe Schindler**** > > H.-H.-Meier-Allee 63, D-28213 Bremen**** > > http://www.thetaphi.de**** > > eMail: uwe@thetaphi.de**** > > **** > > *From:* mbennett.ideaeng@gmail.com [mailto:mbennett.ideaeng@gmail.com] > *On Behalf Of *Mark Bennett > *Sent:* Saturday, November 10, 2012 10:18 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 guys, > > Not expecting to change minds, but found Robert's last email helpful, so > wanted to try one more round.**** > > On Fri, Nov 9, 2012 at 5:32 PM, Robert Muir wrote:**** > > ... > This is some analysis chain configuration issue.**** > > **** > > Interesting, so you would expect that the seed term *would* go through > analysis before it finds the variants in the index? If it's supposed to > work that way then I can recheck my config. (it wasn't just lowercase, > that was just an example) > **** > > If it doesn't work with 100M documents, i don't want it in lucene.**** > > **** > > Ah, this is very illuminating. For scalability, big data, etc, that > certainly makes sense. > > But there are many important Intranet search applications that have far > less than 100M docs, but still need the fine-grained control of > solr/lucene. Intranet projects in the 35k to 2M doc range often have eve= n > more precise indexing, filtering and faceting requirements, and solr/luce= ne > provides that fine blade. > > Wouldn't it be more constructive to pick some number, say 100M, and give > that the "big data" moniker. Then, perhaps for things are not that > scalable, have some separate area/label but still retain them. Discardin= g > all use cases < 100M seems draconian. > > **** > > > I would have the same opinion if someone wanted unscalable solutions > for scoring w/ language models (e.g. not happy with smoothing for > unknown probabilities), or if someone claimed that spatial queries > should do slow things because they don't currently support > interplanetary distances, and so on.**** > > > On Fri, Nov 9, 2012 at 7:52 PM, Mark Bennett wrote= : > > Hi Robert, > > > > I acknowledge your "-1" vote, and I'm guessing that your objection is > maybe > > 70% "scalability", and only 30% use-case? > > > > The older Levenstein stuff has been around for a long time, scalable or > not, > > and already in real systems. > > > > You seem to have a very "binary" on code being "in" or "out". Is there > any > > room in your world-view of code for "gray code", unsupported, incubator= , > > what-have-you? Maybe analagous to people who jailbreak their iPhones o= r > > something? > > > > You're an important part of the community, and working at Lucid, etc., > and > > clearly concerned about software quality. When smart folks like you ha= ve > > such sharp opinions I do try to ponder them against my own circumstance= s. > > > > And on the quality of the old code, was it just the scalability, or wer= e > > there other concerns such as stability, coding style, or possibly > > inconsistent results? > > > > Isn't the sandbox and admonished reference in Java docs sufficient? > > > > I'm harping on this because I'm really between a rock and hard place, a= nd > > also posted another question. > > > > Just trying to understand your very strong opinions, and I thank you fo= r > > your patience in this matter. This issue is either going to fix or > break my > > weekend / next-deliverble. > > > > Sincere thanks, > > Mark > > > > > > -- > > Mark Bennett / New Idea Engineering, Inc. / mbennett@ideaeng.com > > Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513 > > > > > > On Fri, Nov 9, 2012 at 4:37 PM, Robert Muir wrote: > >> > >> 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 > > >> 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 di= d > >> > everything for everybody all of the time, that would be the way to g= o, > >> > 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 > 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 > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org**** > > **** > --90e6ba614138985f0804ce3c7101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jack,

The project uses both a bit of Lucene and then Solr.=A0 So = as you suggest, I'd need a way to configure Solr to use the older fuzzy= matching by default, and I'm not aware of such an option.

The f= ormula to go between percentage and integer edit distance is here:
=A0=A0=A0 http://sta= ckoverflow.com/questions/6087281
Some code:
=A0=A0=A0 3.6.1 contr= ib/spellchecker/src/java/org/apache/lucene/search/spell/LevensteinDistance.= java
=A0=A0=A0 4.0.0 suggest/src/java/org/apache/lucene/search/spell/Lev= ensteinDistance.java
=A0=A0=A0 4.0.0 suggest/src/java/org/apache/lucene/search/spell/LuceneLeven= shteinDistance.java

--
Mark Bennett / New Idea Engi= neering, Inc. / mbennett@ideaeng.co= m
Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513


On Sun, Nov 11, 2012 at 7:18 AM, Jack Kr= upansky <jack@basetechnology.com> wrote:
Okay, so maybe this is simply a case where =93an adjustment=94 was mad= e to=20 Lucene and Solr did not make a corresponding =93adustment=94 to compensate = to=20 =93preserve=94 functionality. Solr users cannot easily override factory met= hods, but=20 of course the Solr query parser can and probably should.
=A0
I=92m not able to determine for sure whether Mark=92s comments were di= rected=20 strictly at Lucene or Solr. I mean, for a lot of people there isn=92t reall= y=20 supposed to be a distinction between the two.
=A0
So, maybe=20 we need a Solr Jira to the effect of adding a parameter such as =93fuzzy.ma= xEdit=94=20 which defaults to =932=94, but could be set higher to access =93slow=94 fuz= zy query.=20 And, maybe that default should also be keyed off of the schema version or L= ucene=20 version so that an =93old=94 Solr app would see no loss of function, althou= gh there=20 is the issue that old queries used a float correlation factor rather than a= n int=20 edit distance.
=A0
Is there a=20 reliable formula for converting from the old correlation factor and the new= edit=20 distance or at least a reasonable approximation? That should be in the Java= doc.=20 I suppose it could be approximated, but there are edge cases where the new= =20 approach provides more discrimination that the old approach, such as for ve= ry=20 short terms.

-- Jack=20 Krupansky
=A0
Sent: Sunday, November 11, 2012 2:51 AM
Subject: RE: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [ji= ra]=20 [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its=20 fast.
=A0

Yes, if you over= ride the factory method in the classic QueryParser.=20 The functionality is still available, you have to just use the classes=20 directly.

=A0

-----

Uwe=20 Schindler

H.-H.-Meier-Allee=20 63, D-28213 Bremen

http://www.thetaphi.de

eMail:=20 uwe@thetaphi.de=

=A0

From: Jack Krupansky=20 [mailto:jack@b= asetechnology.com]
Sent: Sunday, November 11, 2012 6:14=20 AM
To: dev@lucene.apache.org
Subject: Re: FuzzyQuery vs=20 SlowFuzsyQuery docs? -- was: Re: [jira] [Commented] (LUCENE-2667) Fix=20 FuzzyQuery's defaults, so its fast.

=A0

=93we=20 did not remove functionality=94

=A0

Are you saying that=20 full-featured =93classic=94 fuzzy query is still available in the Lucene qu= ery=20 parser? By default? Or via what option?


-- Jack=20 Krupansky

=A0

From: Uwe Schindler=20

Sent:=20 Saturday, November 10, 2012 1:30 PM

To:<= /b> dev@lucene.apache.org=20

Subject: RE:=20 FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented] (LUCENE-2= 667)=20 Fix FuzzyQuery's defaults, so its fast.

<= /div>

=A0

Just use SlowFuz= zyQuery from contrib, I really don=92t understand where=20 the issue is? The code is available in the sandbox/query module and is avai= lable=20 in Lucene 4.0. There is no reason to complain here, we did not remove=20 functionality.

=A0

-----

Uwe=20 Schindler

H.-H.-Meier-Allee=20 63, D-28213 Bremen

http://www.thetaphi.de

eMail:=20 uwe@thetaphi.de=

=A0

From: mbennett.ideaeng@gmail.com = [mailto:mbe= nnett.ideaeng@gmail.com]=20 On Behalf Of Mark Bennett
Sent: Saturday, November 10, 201= 2=20 10:18 PM
To: dev@lucene.apache.org
Subject:=20 Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented]=20 (LUCENE-2667) Fix FuzzyQuery's defaults, so its=20 fast.

=A0

Hi=20 guys,

Not expecting to change minds, but found Robert's last ema= il=20 helpful, so wanted to try one more round.

On Fri, Nov 9, 2012 at 5:32 PM,=20 Robert Muir <rcmui= r@gmail.com> wrote:

...
This is some analysis chain=20 configuration issue.

=A0

Interesting, so you would expect=20 that the seed term *would* go through analysis before it finds the variants= in=20 the index?=A0 If it's supposed to work that way then I can recheck my= =20 config.=A0 (it wasn't just lowercase, that was just an=20 example)
=A0

If it doesn't work with 100M=20 documents, i don't want it in lucene.

=A0

Ah, this is very=20 illuminating.=A0 For scalability, big data, etc, that certainly makes=20 sense.

But there are many important Intranet search applications tha= t=20 have far less than 100M docs, but still need the fine-grained control of=20 solr/lucene.=A0 Intranet projects in the 35k to 2M doc range often have eve= n=20 more precise indexing, filtering and faceting requirements, and solr/lucene= =20 provides that fine blade.

Wouldn't it be more constructive to pi= ck some=20 number, say 100M, and give that the "big data" moniker.=A0 Then, = perhaps for=20 things are not that scalable, have some separate area/label but still retai= n=20 them.=A0 Discarding all use cases < 100M seems=20 draconian.

=A0


I would have the same=20 opinion if someone wanted unscalable solutions
for scoring w/ language= =20 models (e.g. not happy with smoothing for
unknown probabilities), or i= f=20 someone claimed that spatial queries
should do slow things because the= y=20 don't currently support
interplanetary distances, and so=20 on.


On Fri, Nov 9, 2012 at 7:52=20 PM, Mark Bennett <mbennett@ideaeng.com> wrote:
>=20 Hi Robert,
>
> I acknowledge your "-1" vote, and I&= #39;m guessing that=20 your objection is maybe
> 70% "scalability", and only 30%= =20 use-case?
>
> The older Levenstein stuff has been around for = a=20 long time, scalable or not,
> and already in real=20 systems.
>
> You seem to have a very "binary" on co= de being "in"=20 or "out".=A0 Is there any
> room in your world-view of co= de for "gray=20 code", unsupported, incubator,
> what-have-you?=A0 Maybe anala= gous to=20 people who jailbreak their iPhones or
> something?
>
>= =20 You're an important part of the community, and working at Lucid, etc.= ,=20 and
> clearly concerned about software quality.=A0 When smart folks= =20 like you have
> such sharp opinions I do try to ponder them against= my=20 own circumstances.
>
> And on the quality of the old code, wa= s it=20 just the scalability, or were
> there other concerns such as stabil= ity,=20 coding style, or possibly
> inconsistent results?
>
> I= sn't=20 the sandbox and admonished reference in Java docs sufficient?
>
= >=20 I'm harping on this because I'm really between a rock and hard pl= ace,=20 and
> also posted another question.
>
> Just trying to= =20 understand your very strong opinions, and I thank you for
> your=20 patience in this matter.=A0 This issue is either going to fix or break=20 my
> weekend / next-deliverble.
>
> Sincere thanks,
= >=20 Mark
>
>
> --
> Mark Bennett / New Idea Engineeri= ng,=20 Inc. / mbennett= @ideaeng.com
>=20 Direct: 408-733-0387 /= Main: 866-IDEA-ENG /=20 Cell: 408-829-6513
= >
>
> On=20 Fri, Nov 9, 2012 at 4:37 PM, Robert Muir <rcmuir@gmail.com>=20 wrote:
>>
>> I'm -1 for having unscalable shit in l= ucene's=20 core. This query should
>> have never been=20 added.
>>
>> I don't care if a few people complain = because=20 they aren't using
>> lowercasefilter or some other insanity.= Fix your=20 analysis chain. I
>> don't have any sympathy.
>>>>=20 On Fri, Nov 9, 2012 at 7:35 PM, Jack Krupansky <jack@basetechnology.com>
&= gt;>=20 wrote:
>> > +1 for permitting a choice of fuzzy query=20 implementation.
>> >
>> > I agree that we want a= =20 super-fast fuzzy query for simple variations, but
>> >=20 I
>> > also agree that we should have the option to trade off= =20 speed for
>> > function.
>> >
>> > Bu= t I=20 am also sympathetic to assuring that any core Lucene features be
>&= gt;=20 > as
>> > performant as possible.
>> >
>= >=20 > Ultimately, if there was a single fuzzy query implementation that=20 did
>> > everything for everybody all of the time, that would= be=20 the way to go,
>> > but
>> > if choices need to b= e=20 made to satisfy competing goals, we should support
>> > going= that=20 route.
>> >
>> > -- Jack Krupansky
>>=20 >
>> > From: Mark Bennett
>> > Sent: Friday,= =20 November 09, 2012 3:48 PM
>> > To: dev@lucene.apache.org
>> >= =20 Subject: Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira]
>= ;>=20 > [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its=20 fast.
>> >
>> > Hi Robert,
>>=20 >
>> > On Thu, Sep 13, 2012 at 7:39 PM, Robert Muir <rcmuir@gmail.com>= ; wrote:
>>=20 >>
>> >> ...
>> >> ... I'm strong= ly=20 against having this
>> >> unscalable garbage in lucene'= ;s=20 core.
>> >>
>> >> There is no use case for = ed=20 > 2, thats just crazy.
>> >
>> >
>> &= gt; I=20 promise you there ARE use cases for edit distances > 2,=20 especially
>> > with
>> > longer words.=A0 Due to= =20 NDA I can't go into details.
>> >
>> > Also e= d>2=20 can be useful when COMBINING that low-quality part of the
>> >= ;=20 search
>> > with other sub-queries, or additional business=20 rules.=A0 Maybe instead of
>> > boiling an ocean this lets yo= u=20 just boil the sea.=A0 ;-)
>> >
>> > I won't c= omment=20 on the quality of the older Levenstein code, or the
>> >=20 likely
>> > very slow performance, nor where the code should = live,=20 etc.
>> >
>> > But your statement about "no = use case=20 for ed > 2" is simply not true.
>> > (whether you'= ;d agree with=20 any of them or not is certainly another
>> > matter)
>&= gt;=20 >
>> > I understand your concerns about not having it be t= he=20 default.=A0 (or
>> > maybe
>> > having a giant=20 warning message or something, whatever)
>> >
>> >= >=20 --
>> >> lucidworks.com
>> >>
>> >>=20 ---------------------------------------------------------------------
= >>=20 >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>= ;>=20 >> For additional commands, e-mail: dev-help@lucene.apache.org
>>= =20 >>
>> >
>>
>>=20 ---------------------------------------------------------------------
= >>=20 To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>=20 For additional commands, e-mail: dev-help@lucene.apache.org
>>
><= br>
--------------------------------------------------------------------= -
To=20 unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For=20 additional commands, e-mail: dev-help@lucene.apache.org

=

=A0

=

--90e6ba614138985f0804ce3c7101--