You’d get a much better idea of what goes on if you added &explain=true and analyzed the output. That’d show you exactly what is calculated when.
Best, Erick > On Oct 22, 2020, at 4:05 AM, Taisuke Miyazaki <miyazakitais...@lifull.com> > wrote: > > Hi, > > If you use a high value for the score, the values on the smaller scale are > ignored. > > Example : > bq = foo:(1.0)^1.0 > bf = sum(2000000) > > When I do this, the additional score for "foo" at 1.0 does not affect the > sort order. > > I'm assuming this is an issue with the precision of the score floating > point, is that correct? > > As a test, if we change the query as follows, the order will change as you > would expect, reflecting the additional score of "foo" when it is 1.0 > bq = foo:(1.0)^10 > bf = sum(2000000) > > How can I avoid this? > The idea I'm thinking of at the moment is to divide the whole thing by an > appropriate number, such as bf= div(sum(2000000),100). > However, this may or may not work as expected depending on when the > floating point operations are done and rounded off. > > At what point are score's floats rounded? > > 1. when sorting > 2. when calculating the score > 3. when evaluating each function for each bq and bf > > Regards, > Taisuke