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

feat!: Decouple expression hashing and equality #277

Merged
merged 3 commits into from
Aug 10, 2023
Merged

Conversation

genos
Copy link
Contributor

@genos genos commented Aug 10, 2023

BREAKING: Expressions no longer use hashing for implementing equality
BREAKING: Expression hashing and equality no longer take commutativity into account

In #276, @Shadow53 noted

One thing that may be useful enough to pull into its own PR is the change to not use hashing in the implementation of PartialEq for Expression, which also helps speed things up.

We originally put this together in #27 to ensure that equality held in the face of commutativity, e.g., 1 + x == x + 1. In addition to the performance benefits of decoupling the hashing and equality implementations, it makes sense to remove any special status for commutative operations in light of all the work we're doing on expression simplification. If we wished to ensure expressions are Eq if and only if they represent the same mathematical expression, we'd have to have equality contingent upon simplification, which would be even more costly.

BREAKING: Expressions no longer use hashing for implementing equality
BREAKING: Expression equality no longer takes commutativity into account

In #276, @Shadow53 noted

> One thing that may be useful enough to pull into its own PR is the
> change to not use hashing in the implementation of `PartialEq` for
> `Expression`, which also helps speed things up.

We originally put this together in #27 to ensure that equality held in
the face of commutativity, e.g., `1 + x == x + 1`. In addition to the
performance benefits of decoupling the hashing and equality
implementations, it makes sense to remove any special status for
commutative operations in light of all the work we're doing on
expression simplification. If we wished to ensure expressions are
`Eq` if and only if they represent the same mathematical expression,
we'd have to have equality contingent upon simplification, which would
be even more costly.
@genos genos requested review from MarquessV, Shadow53 and kalzoo August 10, 2023 17:10
@kalzoo
Copy link
Contributor

kalzoo commented Aug 10, 2023

Good to see it!

Copy link
Contributor

@Shadow53 Shadow53 left a comment

Choose a reason for hiding this comment

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

Looks good! Thanks for pulling this out of the other PR. Left a style nit, but it's fine to merge without.

match self {
Address(m) => {
Expression::Address(m) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Small style nit, but while we're here: should use Self instead of Expression.

(It's fine not to make this change if there isn't anything more substantial being made. It's just a style thing that is triggered by a certain clippy lint)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks!

Yikes, I just ran cargo clippy -- -W clippy::pedantic 😮

@genos genos merged commit fd27679 into main Aug 10, 2023
@genos genos deleted the equality-and-hashing branch August 10, 2023 20:11
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