Return-Path: <dev-return-258612-archive-asf-public=cust-asf.ponee.io@lucene.apache.org>
X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io
Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io
Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183])
	by cust-asf2.ponee.io (Postfix) with ESMTP id 7D5E1200B81
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Tue, 13 Sep 2016 11:05:23 +0200 (CEST)
Received: by cust-asf.ponee.io (Postfix)
	id 7BF0D160AD2; Tue, 13 Sep 2016 09:05:23 +0000 (UTC)
Delivered-To: archive-asf-public@cust-asf.ponee.io
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by cust-asf.ponee.io (Postfix) with SMTP id C5DCA160AC6
	for <archive-asf-public@cust-asf.ponee.io>; Tue, 13 Sep 2016 11:05:22 +0200 (CEST)
Received: (qmail 66285 invoked by uid 500); 13 Sep 2016 09:05:21 -0000
Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:dev@lucene.apache.org>
List-Id: <dev.lucene.apache.org>
Reply-To: dev@lucene.apache.org
Delivered-To: mailing list dev@lucene.apache.org
Received: (qmail 66164 invoked by uid 99); 13 Sep 2016 09:05:21 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Sep 2016 09:05:21 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id 140BC2C1B7F
	for <dev@lucene.apache.org>; Tue, 13 Sep 2016 09:05:21 +0000 (UTC)
Date: Tue, 13 Sep 2016 09:05:21 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.13003586.1473342938000.557478.1473757521079@Atlassian.JIRA>
In-Reply-To: <JIRA.13003586.1473342938000@Atlassian.JIRA>
References: <JIRA.13003586.1473342938000@Atlassian.JIRA> <JIRA.13003586.1473342938837@arcas>
Subject: [jira] [Commented] (LUCENE-7439) Should FuzzyQuery match short
 terms too?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Tue, 13 Sep 2016 09:05:23 -0000


    [ https://issues.apache.org/jira/browse/LUCENE-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15486719#comment-15486719 ] 

ASF subversion and git services commented on LUCENE-7439:
---------------------------------------------------------

Commit 4db3e7b8a7ca818002af9041bf10660c25905915 in lucene-solr's branch refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4db3e7b ]

LUCENE-7439: improve test case


> Should FuzzyQuery match short terms too?
> ----------------------------------------
>
>                 Key: LUCENE-7439
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7439
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: master (7.0), 6.3
>
>         Attachments: LUCENE-7439.patch, LUCENE-7439.patch
>
>
> Today, if you ask {{FuzzyQuery}} to match {{abcd}} with edit distance 2, it will fail to match the term {{ab}} even though it's 2 edits away.
> Its javadocs explain this:
> {noformat}
>  * <p>NOTE: terms of length 1 or 2 will sometimes not match because of how the scaled
>  * distance between two terms is computed.  For a term to match, the edit distance between
>  * the terms must be less than the minimum length term (either the input term, or
>  * the candidate term).  For example, FuzzyQuery on term "abcd" with maxEdits=2 will
>  * not match an indexed term "ab", and FuzzyQuery on term "a" with maxEdits=2 will not
>  * match an indexed term "abc".
> {noformat}
> On the one hand, I can see that this behavior is sort of justified in that 50% of the characters are different and so this is a very "weak" match, but on the other hand, it's quite unexpected since edit distance is such an exact measure so the terms should have matched.
> It seems like the behavior is caused by internal implementation details about how the relative (floating point) score is computed.  I think we should fix it, so that edit distance 2 does in fact match all terms with edit distance <= 2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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