Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

I opened https://issues.apache.org/jira/browse/LUCENE-7517. Le ven. 21 oct. 2016 à 14:52, Robert Muir a écrit : > The problem is more than worth it. The alternative is to remove the > optimization? I don't think being incorrect / adding leniency to tests > is a valid option at

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

The problem is more than worth it. The alternative is to remove the optimization? I don't think being incorrect / adding leniency to tests is a valid option at all. In general, if we dont apply a general fix, it will just make more such optimizations harder: more jenkins failures, more deltas in

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

I suspect we could do something on the Scorer API indeed, eg. by giving scorers a way to expose the double value of the score. However it's not clear to me that this problem is worth making the Scorer API more complex? Le ven. 21 oct. 2016 à 12:37, Robert Muir a écrit : > But

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

But maybe the old "trick" can still be used somehow: just means using double precision internally to erase most differences? Maybe it means a change to scorer api or whatever, but still I think its a good practical solution (vs something more extreme like kahan summation). I am sure it does not

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

Le ven. 21 oct. 2016 à 12:20, Robert Muir a écrit : > What changed? > The issue here is ReqOptSumScorer, which computes the score of the MUST and SHOULD clauses separately and then sum them up. In that test case, in one case body:d is in the list of SHOULD clauses, and in the

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

We had similar tests before though, with BS1 vs BS2. Because BS1 scored out-of-order, it performed additions in different order, too. But we did the math in these boolean scorers with double precision internally and this kept the test happy (I am sure, if you had a massive massive BQ it would

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

I don't think this test failure proves that the optimization is broken. The other failure is a bit easier to understand so I'll use it as an example, but this one is the same. We have an initial query which is #body:d (+body:b (body:d body:a))^4.0 +body:c body:d)^4.0)^8.0)^3.0)^9.0 and we are

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

Personally I think that is not correct to do. Some optimization or another is broken if scores differ in this way... Just because differences are "small" does not make them insignificant. Think about the tie-break case to users and so on, especially with smaller documents / less terms / etc.

Re: [JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18103 - Unstable!

It is the same one as the other day, we need to relax a bit the check on scores somehow. Le ven. 21 oct. 2016 à 08:40, Policeman Jenkins Server a écrit : > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18103/ > Java: 64bit/jdk-9-ea+140