On terça-feira, 20 de setembro de 2016 11:29:32 PDT Olivier Goffart wrote: > > Is such a behavior change really acceptable for 5.8? I think it can break > > applications that were relying on the current behavior in pretty bad, hard > > to debug ways (random bugs based on rounding errors). > > I tend to agree with that. > This is a behavior change, and i see no reason to do it. Comparing double > for equality with operator== is a bad idea. > I know QVariant::operator== has problems, but i don't think this is > something that should be changed.
I did add a changelog for important behaviour change and I do think it should be changed. Fuzzy comparisons only operate on certain values. We know there's a problem with them when both numbers are close to zero: for example, fuzzy comparing 1.2e-12 to 0 is false, comparing it to -1.2e-12 is false, even though they could be the result from the same operation. I also think that if you want a fuzzy comparison in variants, you should call qFuzzyCompare(QVariant, QVariant) (which doesn't exist, I can add it). > (Correct me if i'm wrong, but this might actually have quite some bad > performance impact on QML where lot of bindings are done on a real value and > they are compared for equality before emiting the changed signal. (or does > QML takes the value out of qvariant before comparing?)) Question for Simon. > On the other hand, the fact that qFuzzyCompare(inf, -inf) returns true looks > like a bug within qFuzzyCompare. And I will reject any patch that adds more complexity in qFuzzyCompare for a 0.01% corner-case. Instead, we should document that it only works for finite numbers far enough away from zero. If your number can be infinite or NaN or zero, you have to find something else. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development