That would improve things for recent documents, but documents that were close to each other, but a long time from NOW, would still have very small differences that would be susceptible to rounding errors that can cause results to get shuffled.
Stephen Duncan Jr www.stephenduncanjr.com On Tue, Feb 22, 2011 at 6:07 PM, David Yang <dy...@nextjump.com> wrote: > One suggestion: use logarithms to compress the large time range into > something easier to compare: 1/log(ms(now,date) > > -----Original Message----- > From: Stephen Duncan Jr [mailto:stephen.dun...@gmail.com] > Sent: Tuesday, February 22, 2011 6:03 PM > To: solr-user@lucene.apache.org > Subject: Sort Stability With Date Boosting and Rounding > > I'm trying to use > > http://wiki.apache.org/solr/SolrRelevancyFAQ#How_can_I_boost_the_score_of_newer_documents > as > a bf parameter to my dismax handler. The problem is, the value of NOW can > cause documents in a similar range (date value within a few seconds of each > other) to sometimes round to be equal, and sometimes not, changing their > sort order (when equal, falling back to a secondary sort). This, in turn, > screws up paging. > > The problem is that score is rounded to a lower level of precision than > what > the suggested formula produces as a difference between two values within > seconds of each other. It seems to me if I could round the value to > minutes > or hours, where the difference will be large enough to not be rounded-out, > then I wouldn't have problems with order changing on me. But it's not > legal > syntax to specify something like: > recip(ms(NOW,manufacturedate_dt/HOUR),3.16e-11,1,1) > > Is this a problem anyone has faced and solved? Anyone have suggested > solutions, other than indexing a copy of the date field that's rounded to > the hour? > > -- > Stephen Duncan Jr > www.stephenduncanjr.com >
