Status: Won't Fix
Fix Version/s: None
PhotoCalib is not hashable. As part of removing Calib, I've removed its hash function, but we now need one for PhotoCalib. It should probably delegate to the underlying BoundedField (so we'll need hash functions for those), and combine that with the hash of the mean and err.
To first order, one could also just combine the hash of the mean and error: for any two "interesting" PhotoCalibs, those should be different, whatever the underlying BoundedFields are.
If the use cases we've had so far are not just in unit tests, I would be interested to hear about them. To me, PhotoCalib fits into a very common category of class (for us) in which it's super useful to have equality comparison for the purposes of writing tests, but it's never needed in any kind of regular/pipeline context. I think it's often tempting but only sometimes productive to satisfy the need for test comparisons by adding equality to the class itself, essentially because I think the test comparisons can often afford to make simplifying assumptions that cannot be made more generally.
Re: equality, I think my uses were "is this persisted object the same as that other one?" From two runs of jointcal for example.
This is now officially an "old" ticket. It seems like the debate was not resolved back in 2019. Do we still want to do this ticket?
I'm just going to call it Won't Fix since I don't think we have a strong case for a hash function, though John Parejko has convinced me that the equality operator definitely should stay.
Well, it's not clear to me that a PhotoCalib is really a value type rather than a utility class. In the former case, we should support hashability, just so that future developers don't have to waste time going "oh, it looks like I wasn't supposed to do that"; in the latter, it doesn't make sense. It sounds like John Parejko leans toward a PhotoCalib being a value.
The main problem is a purely technical one: the way C++ handles hashing works very poorly with polymorphism, and therefore BoundedField, so supporting hashing is a lot more work than supporting equality. So based on the expense I agree with John Swinbank that we shouldn't make it a priority.