Rascal exactConnectionsMatch bug #7359
Conversation
| @@ -103,7 +103,7 @@ RDKIT_SMILESPARSE_EXPORT std::string MolToSmiles( | |||
| RDKIT_SMILESPARSE_EXPORT std::string MolToSmiles( | |||
| const ROMol &mol, const SmilesWriteParams ¶ms); | |||
|
|
|||
| //! \brief returns canonical SMILES for a molecule | |||
| //! \brief returns SMILES for a molecule, canonical by default | |||
There was a problem hiding this comment.
This might have snuck in accidentally, not that more docs are bad!
There was a problem hiding this comment.
I came across it whilst fixing this bug, and it didn't seem worth a separate PR.
| bondLabels[b->getIdx()] = atomLabels[b->getBeginAtomIdx()] + | ||
| std::to_string(b->getBondType()) + | ||
| atomLabels[b->getEndAtomIdx()]; | ||
| if (b->getBeginAtom()->getAtomicNum() == b->getEndAtom()->getAtomicNum()) { |
There was a problem hiding this comment.
Are there any other canonicalization that would be required? charge? hcount? Should you use getTotalDegree?
There was a problem hiding this comment.
Rather selfishly, perhaps, I went with just what I needed to get the job done. Element and bond type are already encoded, so I don't think getTotalDegree would be any different from getDegree. Charge might be useful, maybe, and you could make a case for options for things like treating all halogens the same. Given that enhancements now go in in the bug fixing releases, I think it would be ok to work on an on-demand basis.
Reference Issue
No issue.
What does this implement/fix? Explain your changes.
Further testing of the new exactConnectionsMatch option for RASCAL revealed that the MCES sometimes gave incomplete results with different atom orders of the same molecule.
Any other comments?
I have also updated the docstring for the C++ MolToSmiles function as it was incomplete.