Looking at blame online, it seems that Tim made the change to allow
ferrocene structures to be normalised for the eMolecule
canonicalisation tests:
http://openbabel.svn.sourceforge.net/viewvc/openbabel/openbabel/trunk/src/formats/smilesformat.cpp?r1=4033r2=4034;
IMO, structure normalisations
On Thu, May 24, 2012 at 6:03 AM, Noel O'Boyle baoille...@gmail.com wrote:
Looking at blame online, it seems that Tim made the change to allow
ferrocene structures to be normalised for the eMolecule
canonicalisation tests:
On Thu, May 24, 2012 at 7:45 AM, Craig James cja...@emolecules.com wrote:
On Thu, May 24, 2012 at 6:03 AM, Noel O'Boyle baoille...@gmail.comwrote:
Looking at blame online, it seems that Tim made the change to allow
ferrocene structures to be normalised for the eMolecule
canonicalisation
Here are my changes:
http://openbabel.svn.sourceforge.net/viewvc/openbabel/openbabel/trunk/src/formats/smilesformat.cpp?r1=4758r2=4763;
Craig
On Thu, May 24, 2012 at 8:00 AM, Craig James cja...@emolecules.com wrote:
On Thu, May 24, 2012 at 7:45 AM, Craig James cja...@emolecules.comwrote:
On
I should probably devise a test application to add to OpenBabel so that this
doesn't happen again. Is there some way to add a test to the system where
success is defined by performance rather than correct output?
There are a few ways. Probably the easiest is to add a small unit test (look
Hi,
Deleting the copying of the molecule should be no problem since the
ferrocene specific code is also gone. This code was added to make the
canonicalization of ferrocene-like structures possible. Since it
requires 10! labelings to be analysed, it took forever to find the
canonical labeling.
If I'm not mistaken, these two SMILES should represent the same molecule,
but OB thinks they're different:
c1n1
c1[n]1
According to the SMILES spec, putting the nitrogen in brackets only says
that its charge is zero and H-count is zero, which are the defaults when
the nitrogen is
Hi,
I've run into a case where one of my algorithms runs something like 10,000
time slower in 2.3.x than it did in 2.2.x, and running valgrind with the
callgrind tool seems to indicate that aromaticity detection is the
problem.
Here's the problem: Normally when you generate a SMILES, it detects
More information on this question...
On Wed, May 23, 2012 at 3:05 PM, Craig James cja...@emolecules.com wrote:
Hi,
I've run into a case where one of my algorithms runs something like 10,000
time slower in 2.3.x than it did in 2.2.x, and running valgrind with the
callgrind tool seems to
