Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QuantityGenerator ignores ComparisonType in the obsolete Equals method #1394

Closed
gmkado opened this issue Jun 13, 2024 · 7 comments · Fixed by #1396
Closed

QuantityGenerator ignores ComparisonType in the obsolete Equals method #1394

gmkado opened this issue Jun 13, 2024 · 7 comments · Fixed by #1396

Comments

@gmkado
Copy link

gmkado commented Jun 13, 2024

We are in the process of migrating UnitsNet to the latest and found that some of our obsolete equals methods were failing. Inspecting the generated code shows that the comparison type is ignored.

comparisonType: ComparisonType.Absolute);

Seems like the comparison class still supports it, any reason to not keep it backwards compatible?

return EqualsRelative(referenceValue, otherValue, tolerance);

@lipchev
Copy link
Collaborator

lipchev commented Jun 13, 2024

Given that the operations with doubles introduce rounding errors along the way, we decided (in v5) that it would be best if we deprecated the standard equality contract (A.Equals(B)) in favor of comparing with tolerance.
Frankly, the problems with rounding errors run quite deeply- I wouldn't even trust the CompareTo operator (>=, <=): see #1367 for more details.

The good news is that I've been working on a solution to all these problems (no nuget available ATM). So I don't know how many warnings you've got after upgrading, but yeah- if you're not in a hurry, you might want to hold off on the "big-refactoring" until the official v6 release (there is currently a beta package, but that's no good either).

@gmkado
Copy link
Author

gmkado commented Jun 13, 2024

Thanks for the quick response, I was reading through the various issues around comparisons and I understand the deprecation, but was there a reason to force ComparisonType.Absolute in the obsoleted method?

If you changed this line:

comparisonType: ComparisonType.Absolute);

to

comparisonType: comparisonType);

Then it wouldn't change the behavior of existing (albeit problematic) comparisons, right?

@lipchev
Copy link
Collaborator

lipchev commented Jun 13, 2024

Oh I see what you mean, I think this must be a mistake 👍 :

        [Obsolete("Use Equals(Density other, Density tolerance) instead, to check equality across units and to specify the max tolerance for rounding errors due to floating-point arithmetic when converting between units.")]
        public bool Equals(Density other, double tolerance, ComparisonType comparisonType)
        {
            if (tolerance < 0)
                throw new ArgumentOutOfRangeException(nameof(tolerance), "Tolerance must be greater than or equal to 0.");

            return UnitsNet.Comparison.Equals(
                referenceValue: this.Value,
                otherValue: other.As(this.Unit),
                tolerance: tolerance,
                comparisonType: ComparisonType.Absolute);
        }

@angularsen
we're not actually using the parameter (it's only used for in the xml-docs)..

@angularsen
Copy link
Owner

Looks like a mistake, anyone up for a pull request?

lipchev added a commit to lipchev/UnitsNet that referenced this issue Jun 16, 2024
@lipchev
Copy link
Collaborator

lipchev commented Jun 16, 2024

Easy fix, now let's see if that "breaks" someone's code 😄

angularsen pushed a commit that referenced this issue Jun 16, 2024
fixes #1394 

note that the error is also present in the v6 branch
@angularsen
Copy link
Owner

Fix should be out shortly

Release UnitsNet/5.52.0 · angularsen/UnitsNet

@gmkado
Copy link
Author

gmkado commented Jun 18, 2024

Wow, thanks for the quick work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants