I'm reproducing things consistently across a few machines -- various flavors of i5 or i7, win 8 or win 8.1 and VS 2013.
Do you have VS2013? I'm suspecting we are running into a 4.5 vs 4.5.1 thing . . . On Wed, May 27, 2015 at 12:40 PM Laimonas Simutis <[email protected]> wrote: > Wyatt, > > OS: Windows 8.1 64-bit > RAM: 16GB RAM > VS: VS 2012 > > Can you reproduce it consistently on your machine? > > > Laimis > > > On Wed, May 27, 2015 at 12:13 PM, Wyatt Barnett <[email protected]> > wrote: > > > This is the test that passes on your machine in release or debug even > > though it fails in release mode on my machines and in TeamCity. > > > > If so I think the first thing to pin down is why it works on your machine > > in release mode -- that might pinpoint what the issue is. I'll start > with a > > few dumb questions -- like what is the basic hardware and OS setup and > what > > version of visual studio are you using to build against? > > > > On Tue, May 26, 2015 at 10:02 PM Laimonas Simutis <[email protected]> > > wrote: > > > > > Hello, > > > > > > I am running into an issue in Lucene.net with what seems to be a > floating > > > point number comparison inconsistency. Looking for anyone's guidance or > > > suggestions. > > > > > > Here is the offending code: > > > > > > > > > > > > https://github.com/apache/lucenenet/blob/master/src/Lucene.Net.Core/Search/FuzzyTermsEnum.cs#L243 > > > > > > This conditional evaluation specifically: > > > > > > termAfter ? Bottom >= CalculateMaxBoost(MaxEdits) : Bottom > > > > CalculateMaxBoost(MaxEdits) > > > > > > There is a code path where termAfter is false, so Bottom > > > > CalculateMaxBoost(MaxEdits) evaluation runs. The evaluation for what > > looks > > > like two equal numbers returns Bottom as being greater. > > > The way I captured this is that I pushed another branch which emits the > > > values of these numbers, and here is what I see: > > > > > > termAfter=False, Bottom=0.8571429, maxBoost:0.8571429, yet maxEdits is > > > substracted.... > > > > > > What makes this worse, I can't reproduce it locally. Also if you change > > the > > > logic to evaluate differently (precalculate max boost), it goes away on > > TC > > > (almost always :)). There is no random components involved as far as I > > can > > > tell. The same numbers / data is executed in Lucene.Net and Lucene > > versions > > > of the test. > > > > > > Here is the failing test that suffers from this on TC: > > > > > > > > > > > > http://teamcity.codebetter.com/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=191414#_focus=6322 > > > > > > Also, this issue goes away in Debug builds, even on TC. > > > > > > Anyone have any suggestions how to proceed? Not sure what else to try. > > > Would it be a terrible idea to choose double over float here for better > > > accuracy, if it is some sort of rounding issue? > > > > > > > > > Laimis > > > > > >
