Open tylerperyea opened 10 years ago
This example isn't so much about explicit H's but more about their parities. To fix this we need to be able to define a canonical set of parity flags for the specified stereocenters. This is far from a trivial fix.
It can't just be parity though, because this messes up the atom label layer, not just the stereo layer. If it only had a problem with stereo, that'd be less concerning.
This particular example should now work properly from the recent commit 9b38dbdd97da53e3a4a5e3ba458f7d6784df07e2.
In certain cases, explicit hydrogens seem to cause trouble for the atom-labelling layer of the hash. In these cases, it seems that the smiles generated by the standardizer produces a different hash than the input molfile itself.
Consider the following poorly layed-out structure:
[molfile below]
Direct generation of hash from this Std_SMILES:
And this hash:
However, when that same smiles is fed into the standardizer, I get:
If the explicit hydrogens are removed entirely:![encodeprob2](https://f.cloud.github.com/assets/1581898/1789539/3d95c8a0-695c-11e3-9bbf-e06cff074639.png)
The output hash is now compatible with the smiles.
Molfile for explicit hydrogen version: