> 3429680: [Li+251] 24639246 > 3429701: [ClH+276] 24639289 > 3429702: CCCC[n+251]1cccc(C)c1 24639291
These are an easy fix to the SMILES reader. Currently, we only take single digits for charge. Now I think the molecule is preposterous (e.g., lithium doesn't have 251 electrons to remove!) but I can certainly imagine some metals with formal charges of +10 or above. My feeling is that eMolecules probably wants to add some level of filtering to remove species with highly unusual valence. Also, does the SMILES format have a "continue after error" flag like SDF? That seems like a good addition. > These have large rings which are not found I think. We should be able > to correctly detect ring membership though since this is done using a > spanning tree before SSSR/LSSR analysis is done. I'll take a look at > this. I found this similar bug when doing fragment analysis last night. I have a defensive fix which solves the segfault but does not fix the analysis. I'll commit that shortly which is useful anyway. > consider the H atoms that are added when writing out the smiles. I can > add this to the canonical code but I'll probably copy some code for > this from the smiles format. That makes a lot of sense. It definitely seems like trunk is getting much closer to "bullet-proof" which is a good sign before a release. Next come thousands of users who will test our definition of bullet-proof. :-) Thanks, -Geoff ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
