> Since min(a,b) == -1*max(-1*a, -1*b), you could rewrite the previous > expression using this more complicated logic and it would work. But > that's ugly. > > Also, it would crash anyway. It looks like max currently requires one > of its arguments to be a float constant, and neither of our args would > be a float constant.
Ouch. There should be a min() function. The identity function will be slower. But, the 'parse a float' code should take an integer format string and parse it. On Wed, Apr 7, 2010 at 3:41 PM, Chris Harris <rygu...@gmail.com> wrote: > I'm using function queries to boost more recent documents, using > something like the > > recip(ms(NOW,mydatefield),3.16e-11,1,1) > > approach described on the wiki: > http://wiki.apache.org/solr/FunctionQuery#Date_Boosting > > What I'd like to do is figure out the best way to tweak how documents > with missing date fields are handled. > > For reference, what the above expression does with docs with missing > mydatefield values is to treat those docs as if they were dated at the > epoch start. (This is because the default value for a missing field, > including a date field, is 0.) > > What I want to try, in contrast, is to treat docs with missing dates > as if they were dated NOW. Can anyone suggest a satisfying way to do > this? Here are some options that won't work: > > Option 1. Use map > > The most obvious way to do this would be to wrap the reference to > mydatefield inside a map, like this: > > recip(ms(NOW,map(mydatefield,0,0,ms(NOW)),3.16e-11,1,1)) > > However, this throws an exception because map is hard-coded to take > float constants, rather than arbitrary subqueries. > > Option 2. Use min > > The second most obvious way is to replace ms(NOW,mydatefield) with > this expression: > > min(ms(NOW),ms(NOW,mydatefield) > > (Docs with mydatefield will have a very large ms(NOW,mydatefield) term.) > > However there is no min function, so that won't work. > > Option 2a. Fake min with max and multiplication > > Since min(a,b) == -1*max(-1*a, -1*b), you could rewrite the previous > expression using this more complicated logic and it would work. But > that's ugly. > > Also, it would crash anyway. It looks like max currently requires one > of its arguments to be a float constant, and neither of our args would > be a float constant. > -- Lance Norskog goks...@gmail.com
