[
https://issues.apache.org/jira/browse/LUCENE-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14028676#comment-14028676
]
Robert Muir commented on LUCENE-5752:
-------------------------------------
{quote}
+ // nocommit can we use varargs? rob was unhappy before?
static public Automaton concatenate(List<Automaton> l) {
{quote}
Well, an alternative is to have concatenate(String, Automaton) just to ensure
the optimization is preserved for the common case,
and to be less trappy. But I think the optimization is important and currently
relied upon, because we concat tiny strings on the LHS with large ones on the
RHS and depend on it not being costly.
{code}
// adding epsilon transitions with the NFA concatenation algorithm
// in this case always produces a resulting DFA, preventing expensive
// redundant determinize() calls for this common case.
boolean deterministic = a1.isSingleton() && a2.isDeterministic();
{code}
> Explore light weight Automaton replacement
> ------------------------------------------
>
> Key: LUCENE-5752
> URL: https://issues.apache.org/jira/browse/LUCENE-5752
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
>
> This effort started with the patch on LUCENE-4556, to create a "light
> weight" replacement for the current object-heavy Automaton class
> (which creates separate State and Transition objects).
> I took that initial patch much further, and cutover most places in
> Lucene that use Automaton to LightAutomaton. Tests pass.
> The core idea of LightAutomaton is all states are ints, and you build
> up the automaton under the restriction that you add all outgoing
> transitions one state at a time. This worked well for most
> operations, but for some (e.g. UTF32ToUTF8!!) it was harder, so I also
> added a separate builder to add transitions in any order and then in
> the end they are sorted and added to the real automaton.
> If this is successful I think we should just replace the current
> Automaton with LightAutomaton; right now they both exist in my current
> patch...
> This is very much a work in progress, and I'm not sure the
> restrictions the API imposes are "reasonable" (some algos got uglier).
> But I think it's at least worth exploring/iterating... I'll make a branch and
> commit my current state.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
