Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of trejkaz@trypticon.org
 designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANSc5vEuaBmG_u3me1uzyTB1O0qu8ZXeELWbQmFbtJopMJCP5Q@mail.gmail.com>
References: 
 <CANSc5vH9PS3S74qUxmRAnEVxciMe60UtFD9HeCrXev18YtPi8g@mail.gmail.com>
	<CANSc5vEuaBmG_u3me1uzyTB1O0qu8ZXeELWbQmFbtJopMJCP5Q@mail.gmail.com>
Date: Sat, 26 May 2012 13:53:18 +1000
Message-ID: 
 <CADuAvzcuSvSPW70xMEOC1tNVffij9M2T3iijFcBtxw7W_7MsGA@mail.gmail.com>
Subject: Re: Approches/semantics for arbitrarily combining boolean and
 proximity search operators?
From: Trejkaz <trejkaz@trypticon.org>
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=UTF-8

On Sat, May 26, 2012 at 12:07 PM, Chris Harris <ryguasu@gmail.com> wrote:
>
> Alternatively, if you insist that query
>
> merger w/5 (medical and agreement)
>
> should match document "medical x x x merger x x x agreement"
>
> then you can propagate 2x the parent's slop value down to child queries.

This is in fact exactly how we are approximating them. The selling
point was this one:

> * You get a nice 1-to-1 mapping from one subquery to one SpanQuery;
> the output query trees look recognizably parallel to the input
> queries, regardless of query complexity.

The problem with the other "more accurate" transformations at the time
were the explosion of query complexity once users started to combine
them.

Of course, a native SpanAndQuery would allow for a more elegant and
precise 1-to-1 mapping. :)   I even tried to modify one of the
existing span queries to get similar behaviour, but it wasn't easy
enough to get it right.

TX

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