Hi, In case you want to round up, you can use negative numbers and percentage of failed matches so 75% of matches rounded up can be written as -25%.
HTH, Emir -- Monitoring - Log Management - Alerting - Anomaly Detection Solr & Elasticsearch Consulting Support Training - http://sematext.com/ > On 29 Mar 2018, at 17:00, Shawn Heisey <apa...@elyograg.org> wrote: > > On 3/29/2018 1:42 AM, iamluckysharma.0...@gmail.com wrote: >> Just a suggestion , Shouldn't we need to use Math.round instead of direct >> int when watch mode is in %, >> example i have 3 boolean clauses if i go for mm=50%, currently it reduce it >> to ~1, instead it can be ~2, >> >> another example could be when we have 5 boolean clauses and mm=75%, we get >> calc as 3.75 currently it took 3, so instead of 3 it should have taken 4. as >> Math.round() > > Maybe that is what it SHOULD do, but in most languages, converting a float > value to an integer truncates the decimal portion, it doesn't round. To do > that requires a deliberate choice in the code, and that probably doesn't > exist in dismax/edismax. If your assertion is that this should have been > done from day one, I'd say you're right. But that decision is now ancient > history. The person who wrote the code might have had a very good reason to > NOT do it that way. > > At this point, if the functionality were changed, it would result in an > upgraded Solr version behaving VERY differently than the previous version. > While new functionality is often added in any new minor release, changing > existing behavior that users rely on without a configuration option is > usually only done in a major version. So for 7.x, dismax/edismax would need > an option to enable rounding on minimum-should-match calculations. Sounds > like a great feature request to put into Jira, and patches are always welcome. > > Thanks, > Shawn >
