ModificationWithMass hashing seems odd about mzlib HOT 5 CLOSED

Hm, looks like a bug. Good catch! Do you have a fix in mind?

from mzlib.

I'm a little uncertain about the history here. If I remember correctly, we decided not to hash on the ID for some reason, maybe basing the uniqueness on other properties. As for the monoisotopic mass, it seems like you want a little tolerance (1e-9), so I'm not sure how to handle that in a hash code. Rounding seems like an option, but that's not the same as a tolerance.

from mzlib.

I looked into this, and now I'm not sure this is a concern, since hash codes do not need to be unique. Unless this poses an actual problem, I vote to close this issue.

from mzlib.

The problem I'm encountering is in merging databases. Consider 2 databases both derived from the UniProt database but with additional sets of PTMs. They will have many of the same mods at positions along proteins in the databases. In merging, it would be nice to make a hash set of modifications at each position and call it a day. Instead, the hash set behaves weirdly, getting rid of ModificationWithMass
objects that have very different masses and different IDs.

We already use HashSets of Modification objects (here and here), so we should be careful here.

from mzlib.

The test I wrote yesterday works now... I think the tests weren't building properly at the end of the day yesterday. Thanks!

from mzlib.