Implement separate __eq__ methods#1033
Conversation
Pull Request Test Coverage Report for Build 4719168322
💛 - Coveralls |
|
Just like with |
damonge
left a comment
There was a problem hiding this comment.
Some comments. Will look at core.py next, then tests
|
@damonge all done, back to you now and we can move on with the rest if you are happy with the changes. |
damonge
left a comment
There was a problem hiding this comment.
Just one (maybe major) comment for core.py
damonge
left a comment
There was a problem hiding this comment.
Final comments on tests
|
@damonge back to you |
damonge
left a comment
There was a problem hiding this comment.
OK, we're done. Merge when the tests pass.
As @rmjarvis and @marcpaterno correctly pointed out, we can save loads of time comparing
CCLObjectsif we compare parameters instead of strings. To that end, I extended some functionality that was already there to do parameter comparisons for most objects.Just like the
__repr_attrs__class variable, which automatically builds a repr using a list of specified arguments,__eq_attrs__now makes sure that the default__eq__is overridden and that the individual attributes are compared one-by-one.For example, in the
Cosmologyobject, we only need to add this line in the beginning:There are only 3 classes where this is not possible (because we have to check the C-level objects):
Pk2D,Tk3D,Tracer. For these, I implemented full__eq__methods as per the usual way.Timings show that this way is indeed much faster (


bldis therepr):Note, however, that with the current implementation in
master, the first computation of_reprmight be slow, but every new call to__eq__is of the order of nanoseconds (compare to microseconds with this PR proposal). It is a trade-off. So, if we compare objects sequentially (and discard the old one if they are not equal, like in an MCMC) this PR wins. But if we compare one object with several others, the currently implemented way wins.