Ah, I see what you mean. Thanks, Igor
On Thu, 2011-09-15 at 13:33 +0100, Noel O'Boyle wrote: > I understand what you're saying, but that is on purpose. The library > API is geared towards converting files, rather than returning string > representations for further processing. > > - Noel > > On 15 September 2011 13:22, Igor Filippov <igor.v.filip...@gmail.com> wrote: > > Speaking of InChI and InChIKey - I noticed that InChIKey calculated > > through libopenbabel (via a Perl script in my case) seems to end with a > > carriage return. Surely the library should return just the InChI or > > InChIKey string without "\n" stuck at the end? > > > > Igor > > > > On Thu, 2011-09-15 at 08:07 -0400, Chris Morley wrote: > >> On 05/09/2011 19:27, Ken Smith wrote: > >> > >> In response to this, I have made a few changes to the way OpenBabel > >> calculates InChI. > >> > >> > E.g. for a proton [H+], I get: > >> > > >> > InChI=1S/H/q+1 > >> > (ASSFXGJQJOXDAB-UHFFFAOYSA-N) > >> > > >> > But I *think* I should be getting: > >> > > >> > InChI=1S/p+1 > >> > (GPRLSGONYQIRFK-UHFFFAOYSA-N) > >> > >> OB now gives InChI=1S/p+1 which Dmitrii Tchekhovskoi on the > >> InChI-discuss mailing list recommends as correct. > >> > >> > Likewise for protonated molecular hydrogen (whose SMILES notation I > >> > assume is [H][H][H+]). I'm getting an InChI of: > >> > > >> > InChI=1S/H3/h1H2/q+1 > >> > > >> > whereas I'm fairly sure it should be something like: > >> > > >> > InChI=1S/H2/h1H/p+1 > >> > >> OB still gives InChI=1S/H3/h1H2/q+1, which is apparently correct for a > >> linear structure. > >> > >> On the other list Dmitrii Tchekhovskoi and Geoff Hutchinson discussed > >> calculating InChIKey directly from an input InChi, rather than going > >> through an OBMol. This is now done by default on the commandline or in > >> the GUI whenever InChI is the input format. There is an option to force > >> a recalculation. (The inchi descriptor behaves as if it always reuses an > >> input InChI.) > >> > >> Chris > >> > >> ------------------------------------------------------------------------------ > >> Doing More with Less: The Next Generation Virtual Desktop > >> What are the key obstacles that have prevented many mid-market businesses > >> from deploying virtual desktops? How do next-generation virtual desktops > >> provide companies an easier-to-deploy, easier-to-manage and more affordable > >> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > >> _______________________________________________ > >> OpenBabel-discuss mailing list > >> OpenBabel-discuss@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/openbabel-discuss > > > > > > > > ------------------------------------------------------------------------------ > > Doing More with Less: The Next Generation Virtual Desktop > > What are the key obstacles that have prevented many mid-market businesses > > from deploying virtual desktops? How do next-generation virtual desktops > > provide companies an easier-to-deploy, easier-to-manage and more affordable > > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > > _______________________________________________ > > OpenBabel-discuss mailing list > > OpenBabel-discuss@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/openbabel-discuss > > ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ OpenBabel-discuss mailing list OpenBabel-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
