Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1836021694.233171265985628404.JavaMail.jira@brutus.apache.org>
Date: Fri, 12 Feb 2010 14:40:28 +0000 (UTC)
From: "Robert Muir (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-2089) explore using automaton for
 fuzzyquery
In-Reply-To: <1780563173.1258902039668.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Robert Muir commented on LUCENE-2089:
-------------------------------------

bq. I guess "gheto dfa" would not work, at least not fast enough (I didn't think about it really). Practically you would need to know which characters extend current character in you dictionary, or in DFA parlance, all outgoing transitions from the current state. "gheto dfa" cannot do it efficiently?

i think it does it efficiently enough for any finite language (such as what you would use for fuzzy), the real problem with ghetto DFA relates more to infinite languages (* operator in wildcard/regex).

its very easy to see the worst case and very difficult to see the average case, see: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.133.2155&rep=rep1&type=pdf

if you have an idea you should try it on ghetto DFA (lucene's existing term dictionary), unless you can easily consume that average-case analysis presented in the paper (i can't)... :) 

eg its surprising to me in practice.  Don't be afraid of the average complexity presented in the paper of O\(sqrt\(n\)\) where n is number of terms..., this is for "average regular expression", for things like levenstein automata it is much less as they are finite (e.g. 64 inspections for Lev1 of my 10 million terms benchmark, not 3,000 inspections.

> explore using automaton for fuzzyquery
> --------------------------------------
>
>                 Key: LUCENE-2089
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2089
>             Project: Lucene - Java
>          Issue Type: Wish
>          Components: Search
>            Reporter: Robert Muir
>            Assignee: Mark Miller
>            Priority: Minor
>         Attachments: LUCENE-2089.patch, Moman-0.2.1.tar.gz, TestFuzzy.java
>
>
> Mark brought this up on LUCENE-1606 (i will assign this to him, I know he is itching to write that nasty algorithm)
> we can optimize fuzzyquery by using AutomatonTermsEnum, here is my idea
> * up front, calculate the maximum required K edits needed to match the users supplied float threshold.
> * for at least small common E up to some max K (1,2,3, etc) we should create a DFA for each E. 
> if the required E is above our supported max, we use "dumb mode" at first (no seeking, no DFA, just brute force like now).
> As the pq fills, we swap progressively lower DFAs into the enum, based upon the lowest score in the pq.
> This should work well on avg, at high E, you will typically fill the pq very quickly since you will match many terms. 
> This not only provides a mechanism to switch to more efficient DFAs during enumeration, but also to switch from "dumb mode" to "smart mode".
> i modified my wildcard benchmark to generate random fuzzy queries.
> * Pattern: 7N stands for NNNNNNN, etc.
> * AvgMS_DFA: this is the time spent creating the automaton (constructor)
> ||Pattern||Iter||AvgHits||AvgMS(old)||AvgMS (new,total)||AvgMS_DFA||
> |7N|10|64.0|4155.9|38.6|20.3|
> |14N|10|0.0|2511.6|46.0|37.9|	
> |28N|10|0.0|2506.3|93.0|86.6|
> |56N|10|0.0|2524.5|304.4|298.5|
> as you can see, this prototype is no good yet, because it creates the DFA in a slow way. right now it creates an NFA, and all this wasted time is in NFA->DFA conversion.
> So, for a very long string, it just gets worse and worse. This has nothing to do with lucene, and here you can see, the TermEnum is fast (AvgMS - AvgMS_DFA), there is no problem there.
> instead we should just build a DFA to begin with, maybe with this paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.652
> we can precompute the tables with that algorithm up to some reasonable K, and then I think we are ok.
> the paper references using http://portal.acm.org/citation.cfm?id=135907 for linear minimization, if someone wants to implement this they should not worry about minimization.
> in fact, we need to at some point determine if AutomatonQuery should even minimize FSM's at all, or if it is simply enough for them to be deterministic with no transitions to dead states. (The only code that actually assumes minimal DFA is the "Dumb" vs "Smart" heuristic and this can be rewritten as a summation easily). we need to benchmark really complex DFAs (i.e. write a regex benchmark) to figure out if minimization is even helping right now.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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