Open tylerperyea opened 10 years ago
The simple, poor man's resolution to this, of course, is to simply feed the output of the standardizer back into the standardized, until it stops changing. I'm not yet aware of infinite oscillating hashes, but if they exist, such a procedure could bail out and notify the user of an error...
This is fixed as of commit 9b38dbdd97da53e3a4a5e3ba458f7d6784df07e2. I've also reworked in how we handle stereocenters with explicit Hs.
Some structures (usually with several fused rings that contain stereo annotations) don't return the same hash after a round-trip. I'm not sure why this happens.
Example:
Yeilds:
But, if the output file is fed through again, I get:
Each new loop seems to agree with the last hash. This may be due to parity conflict resolution, which seems to be done arbitrarily. If there is ambiguity/conflict, it would probably be better to err on the side of no annotation. However, I think this example does contain enough information to work.
Similarly, this happens with the following (theoretically equivalent) molfile:
Which gets: java -jar lychi-all-v0.1.jar test.mol
java -jar lychi-all-v0.1.jar test.mol | java -jar lychi-all-v0.1.jar