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