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/ >