SMP/DMP comparison

[Chris Smith]

I have been prototyping an SMP sparse internal representation for Poly, parallel to DMP, using the existing raw-dict routines in sparsetools.py.

I now have a question about equality. . Poly.__eq__ currently compares generators, domain, and finally the representation itself, and hashing likewise depends on the representation. Thus equivalent DMP- and SMP-backed Poly objects would compare unequal unless this changes.

There seem to be precedents in both directions. SymPy equality is often structural (Float(1) != Integer(1)), but storage representation is hidden for matrices:

Matrix([[1]]) == SparseMatrix([[1]]) # True

and matrix equality explicitly unifies the underlying representations.

Should DMP/SMP similarly be considered an implementation detail for Poly equality, or should differing representations make the Poly objects unequal? The former would also require making Poly hashing representation-independent.

/c

[Muhammad Usaid]

I'd lean toward the representation-independent equality here following the Matrix and SparseMatrix precedent you cited. For the user DMP and SMP is a storage and performance choice not a mathematical distinction . Two poly objects with the same domain , same generators and same coefficients are the same polynomials regardless of being back representative. if equality leaks any detail about that it becomes a footgun . Polys built via different code paths could silently fail == checks or break set membership.
This is different from Float(1) != Integer(1) , float vs int is a semantically meaningful choice made by the user. So unequal comparison communicates real information. DMP vs SMP is an internal optimization.
The consequences are that the hash would need to become representation independent. That's more implementation work but the right tradeoff.
One thing worth noticing is for the implementation , if DMP and SMP could ever differ in domain normalization or precision in edge cases , equality should fall back to comparing canonicalized coefficients rather than assuming same domain , same generators , convert-and-compare is always cheap , could be a real cost for large sparse polys where materializing to compare is expensive.
Happy to look at the draft if that would help move this forward.

[Chris Smith]

Thanks for the offer to help. The PR is ready for review at 30604 . It's large but coverage is high so tests should be a good indicator of whether or not this is doing what is expected.

/c