Skip to content

Conversation

@beverlylytle
Copy link
Member

I noticed some small bugs in the custom magic methods of a few primitives. In particular
Polyline([[0, 0, 0], [0, 0, 1]]) == Polyline([[0, 0, 0], [0, 0, 1], [0, 0, 2]) would return True , and a similar bug existed in a few other classes.

What type of change is this?

  • Bug fix in a backwards-compatible manner.
  • New feature in a backwards-compatible manner.
  • Breaking change: bug fix or new feature that involve incompatible API changes.
  • Other (e.g. doc update, configuration, etc)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

  • I added a line to the CHANGELOG.md file in the Unreleased section under the most fitting heading (e.g. Added, Changed, Removed).
  • I ran all tests on my computer and it's all green (i.e. invoke test).
  • I ran lint on my computer and there are no errors (i.e. invoke lint).
  • I added new functions/classes and made them available on a second-level import, e.g. compas.datastructures.Mesh.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added necessary documentation (if appropriate)

return False
for v1, v2 in zip(self, other):
for a, b in zip(v1, v2):
if math.fabs(a - b) > tol:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we not replace this with the precision setting of compas?
noticed that we are not doing this for the other checks either...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that makes sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, i'm a little confused by this comment. isn't compas.PRECISION more about formatting the way objects are printed rather than prescribing tolerances on computations?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes and no. it is, for example, also used in the geometric maps to determine comparison precision...
but i agree that there is no "official policy" for this at the moment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but in the tests, when geometry comparisons are concerned, we tend to use (or should be using) allclose to avoid tests failing for lack of precision

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, i've changed to using allclose now, but that also uses a hardcoded tolerance...

maybe once there is an "official policy" on this, such changes can be made more thoroughly.

@beverlylytle beverlylytle merged commit 71dc6c9 into main Mar 15, 2021
@beverlylytle beverlylytle deleted the length_eq branch March 15, 2021 12:09
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 this pull request may close these issues.

3 participants