i'm not sure i follow what you're saying on #3. let me clarify in case it's
on my end. i was wanting to *eventually* set a lower bound of -10%size1 and
an upper of +10%size1. for the sake of experimentation i started with just
the lower bound. i didn't care (at that point) about the results, just
getting a successful query to run. upon getting to that point i would then
tailor the lower and upper bounds accordingly to begin testing more true to
life queries.
at any rate, the #4 point seems to be the path to take for the present.
thanks for the discussion!
--
*John Blythe*
Product Manager & Lead Developer
251.605.3071 | j...@curvolabs.com
www.curvolabs.com
58 Adams Ave
Evansville, IN 47713
On Thu, May 28, 2015 at 4:56 PM, Chris Hostetter <hossman_luc...@fucit.org>
wrote:
>
> : 2) lame :\
>
> Why do you say that? ... it's a practical limitation -- for each document
> a function is computed, and then the result of that function is compared
> against the (fixed) upper and lower bounds.
>
> In situations where you want the something like the lower bound of the
> range comparison to be another function relative to the document, that's
> equivilent to "unwinding" that lower bound function and rolling it into
> the function you are testing -- just like i did in the example i posted in
> "#4" of my email (below)
>
> By requiring that the uper and lower bounds be fixed, the common case can
> be optimized, but cases like that one can stll be supported. if the lower
> & upper bound params supported arbitrary functions, the implementation
> would be a lot more complex -- slower for hte common case, and hte same
> speed for uncommon cases like what you're describing.
>
> : 3) right. i hadn't bothered with the upper limit yet simply for sake of
> : less complexity / chance to fk it up. wanted to get the function working
> : for lower before worrying about adding u= and getting the query refined
>
> To be very clear: even if what you were trying to do worked as you wrote
> it, adding an upper bound wouldn't change the fact that the comparison you
> were trying ot make in your query doesn't match the problem statement in
> your question, and doesn't make sense in general -- you need to compare
> the field value with 10% of some OTHER input value -- not 10% of itself.
>
> Adding an upper bound that was similar to hte lower bound you were trying
> would have simply prevented any docs from mathcing at all.
>
>
>
> : > : Expected identifier at pos 29 str='{!frange l=sum(size1,
> product(size1,
> : > : .10))}size1
> : > :
> : > : pos 29 is the open parenthesis of product(). can i not use a function
> : > : within a function? or is there something else i'm missing in the way
> i'm
> : > : constructing this?
> : >
> : > 1) you're confusing the parser by trying to put whitespace inside of a
> : > local param (specifically the 'l' param) w/o quoting the param value
> .. it
> : > things that you want "sum(size1" to be the value of the "l" param, and
> : > then it doesn't know what to make of "product(size1" as a another local
> : > param that it can't make sense of.
> : >
> : > 2) if you remove the whitespace, or quote the param, that will solve
> that
> : > parsing error -- but it will lead to a new error from
> : > ValueSourceRangeFilter (ie: "frange") because the "l" param doesn't
> : > support arbitrary functions -- it needs to be a concrete number.
> : >
> : > 3) even if you could pass a function for the "l" param, conceptually
> what
> : > you are asking for doesn't really make much sense ... you are asking
> solr
> : > to only return documents where the value of the "size1" field is in a
> : > range between X and infinity, where X is defined as the sum of the
> value
> : > of the "size1" field plus 10% of the value of the "size1" field.
> : >
> : > In other words: "give me all docs where S * 1.1 <= S"
> : >
> : > Basically you are asking it to return all documents with a negative
> value
> : > in the "size1" field.
> : >
> : >
> : > 4) your original question was about filtering docs where the value of a
> : > field was inside a range of +/- X% of a specified value. a range query
> : > where you computed the lower/upper bounds bsed on that percentage in
> the
> : > client is really the most straight forward way to do that.
> : >
> : > the main reason to consider using frange for something like this is if
> you
> : > wnat to filter documents based on the reuslts of a function over
> multiple
> : > fields. (ie: "docs where the price field divided by the
> quantity_included
> : > field was within a client specified range")
> : >
> : > adimitedly, you could do something like this...
> : >
> : > fq={!frange u=0.10}div(abs(sub($target,size1)),$target)&target=345
> : >
> : > ...which would tell solr to find you all documents where the "size1"
> field
> : > was within 10% of the target value (345 in this case) -- ie: "310.5 <=
> : > size1 <= 379.5)
> : >
> : > however it's important to realize that doing something like this is
> going
> : > to be less inefficient then just computing the lower/upper range
> : > bounds in the client -- because solr will be evaluating that function
> for
> : > every document in order to make the comparison. (meanwhile you can
> : > compute the upper and lower bounds exactly once and just let solr do
> the
> : > comparisons)
> : >
> : >
> : > -Hoss
> : > http://www.lucidworks.com/
> : >
> :
>
> -Hoss
> http://www.lucidworks.com/
>
