From: Rajarshi G. <rg...@in...> - 2009-01-12 20:28:29
|
Hi, I seem to recall that the CDK policy was to do just enough and no more. In that vein why does the SMILES parser perform atom typing, h addition and aromaticity perception in the parseSmiles method? Shouldn't these be done by the caller? ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- Accuracy, n.: The vice of being right |
From: Nina J. <ni...@ac...> - 2009-01-13 07:16:40
|
Hi, While not (yet) using the recent cdk code, atom typing, h addition and aromaticity perception is exactly what I would expect from a SMILES parser. All that information is derived from the SMILES string. This is user point of view :) Regards, Nina Rajarshi Guha wrote: > Hi, I seem to recall that the CDK policy was to do just enough and no > more. In that vein why does the SMILES parser perform atom typing, h > addition and aromaticity perception in the parseSmiles method? > > Shouldn't these be done by the caller? > > ------------------------------------------------------------------- > Rajarshi Guha <rg...@in...> > GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 > ------------------------------------------------------------------- > Accuracy, n.: > The vice of being right > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |
From: Nikolay K. <ni...@un...> - 2009-01-14 20:30:29
|
> I really think we should read in what we get, not more but also not less. > If we start validating things inside the SMILES parser, we get into a > lot of trouble and a never ending story. > So, I think c1ccc1 should result in a 4-membered ring with all > aromaticity flags set. > It might be an error or someone wants to tell us something he considers > important. :-) > Again, afterwards, there can be a Validator running over what the SMILES > parser returned. > This concept is modular and removes decencies. > c1ccc1 is not aromatic. As far as I can remember it anti-aromatic. In SMILES "c" - does not mean aromatic. It means sp2 carbon (and it might be aromatic or not aromatic) Nick -- Dr. Nikolay Kochev University of Plovdiv, Department of Analytical Chemistry http://web.uni-plovdiv.bg/nick |
From: Christoph S. <ste...@eb...> - 2009-01-14 22:37:57
|
Nikolay Kochev wrote: >> I really think we should read in what we get, not more but also not less. >> If we start validating things inside the SMILES parser, we get into a >> lot of trouble and a never ending story. >> So, I think c1ccc1 should result in a 4-membered ring with all >> aromaticity flags set. >> It might be an error or someone wants to tell us something he considers >> important. :-) >> Again, afterwards, there can be a Validator running over what the SMILES >> parser returned. >> This concept is modular and removes decencies. >> > > > c1ccc1 is not aromatic. As far as I can remember it anti-aromatic. As I said above, detecting it as aromatic is an error (as in "wrong"). > In SMILES "c" - does not mean aromatic. It means sp2 carbon (and it might > be aromatic or not aromatic) That has been discussed again and again and there is no normative source for one or the other. Cheers, Chris -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <ego...@gm...> - 2009-01-13 07:51:39
|
On Mon, Jan 12, 2009 at 9:28 PM, Rajarshi Guha <rg...@in...> wrote: > Hi, I seem to recall that the CDK policy was to do just enough and no > more. In that vein why does the SMILES parser perform atom typing, h > addition and aromaticity perception in the parseSmiles method? The SMILES parser is indeed somewhat diverging from the general scheme... if not mistaken, this was decided on the last in the past year... it should have been recorded as RFC... now I can only point the the ML archived :( h addition is somewhat different btw... this is in the SMILES specification... the organic subset (the atoms we may use without square brackets) have a strictly defined hydrogen count... but I guess the parser just does all atoms anyway... that could be considered a bug... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2009-01-13 13:20:53
|
On Jan 13, 2009, at 2:51 AM, Egon Willighagen wrote: > On Mon, Jan 12, 2009 at 9:28 PM, Rajarshi Guha <rg...@in...> > wrote: >> Hi, I seem to recall that the CDK policy was to do just enough and no >> more. In that vein why does the SMILES parser perform atom typing, h >> addition and aromaticity perception in the parseSmiles method? > > The SMILES parser is indeed somewhat diverging from the general > scheme... if not mistaken, this was decided on the last in the past > year... it should have been recorded as RFC... now I can only point > the the ML archived :( Aah, OK - should be a wiki page BTW, would it be OK to make the private parseSmiles method public (possibly renamed) so that we can access the parsed-only molecule? ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- A red sign on the door of a physics professor: 'If this sign is blue, you're going too fast.' |
From: Christoph S. <ste...@eb...> - 2009-01-14 09:53:11
|
I think that the SMILES parser should return a molecule with all information *explicitly* encoded in the SMILES, which, in my opinion, is element symbols, bonds, bond orders and aromaticity. Any additional information needed to deduce this may also be computed. Still, I would think that there is no need to run the aromaticity detector. Atoms are coded as aromatic explicitly, so no detection needed there. Can anyone remind me why we need to run the Aromaticity Detection inside the SMILES parser then? Cheers, Chris Nina Jeliazkova wrote: > Hi, > > While not (yet) using the recent cdk code, atom typing, h addition and > aromaticity perception is exactly what I would expect from a SMILES > parser. All that information is derived from the SMILES string. This is > user point of view :) > > Regards, > Nina > > > Rajarshi Guha wrote: >> Hi, I seem to recall that the CDK policy was to do just enough and no >> more. In that vein why does the SMILES parser perform atom typing, h >> addition and aromaticity perception in the parseSmiles method? >> >> Shouldn't these be done by the caller? -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <ego...@gm...> - 2009-01-14 10:04:15
|
On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: > I think that the SMILES parser should return a molecule with all > information *explicitly* encoded in the SMILES, which, in my opinion, is > element symbols, bonds, bond orders and aromaticity. > Any additional information needed to deduce this may also be computed. > Still, I would think that there is no need to run the aromaticity > detector. Well, that is in the SMILES specs... see the OpenSMILES discussions that shed some light on the complexity... > Atoms are coded as aromatic explicitly, so no detection needed > there. Check OpenSMILES.org... > Can anyone remind me why we need to run the Aromaticity Detection inside > the SMILES parser then? I can only refer to the ML archives and the many SmilesParser bug reports... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2009-01-14 13:10:54
|
On Jan 14, 2009, at 4:53 AM, Christoph Steinbeck wrote: > I think that the SMILES parser should return a molecule with all > information *explicitly* encoded in the SMILES, which, in my > opinion, is > element symbols, bonds, bond orders and aromaticity. What if the input SMILES is C1C=CC=CC1? ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- I saw Elvis. He sat between me and Bigfoot on the UFO. |
From: Christoph S. <ste...@eb...> - 2009-01-14 15:46:00
|
Rajarshi Guha wrote: > On Jan 14, 2009, at 4:53 AM, Christoph Steinbeck wrote: > >> I think that the SMILES parser should return a molecule with all >> information *explicitly* encoded in the SMILES, which, in my >> opinion, is >> element symbols, bonds, bond orders and aromaticity. > > What if the input SMILES is C1C=CC=CC1? Then the molecule is not aromatic anyway :-) But seriously, as I said in my other email to Nikolay, I think the parser should return what is in the SMILES, which in your case is single and double bonds. If the programmer wants aromaticity detection, he plugs the aromaticity detector behind the SMILES parser. He can also run a check before that, if there is already any aromaticity information return by the SMILES parser and run the AromaticityDetector only conditionally. I think this is the right way to do it for a Lego(TM)-like library. We run into thousands of problems if our modules all do more than one thing at a time *and* if that can be avoided. Cheers, Chris -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Rajarshi G. <rg...@in...> - 2009-01-14 15:50:15
|
On Jan 14, 2009, at 10:45 AM, Christoph Steinbeck wrote: > Rajarshi Guha wrote: >> On Jan 14, 2009, at 4:53 AM, Christoph Steinbeck wrote: >> >>> I think that the SMILES parser should return a molecule with all >>> information *explicitly* encoded in the SMILES, which, in my >>> opinion, is >>> element symbols, bonds, bond orders and aromaticity. >> >> What if the input SMILES is C1C=CC=CC1? > > Then the molecule is not aromatic anyway :-) > But seriously, as I said in my other email to Nikolay, I think the > parser should return what is in the SMILES, which in your case is > single > and double bonds. > If the programmer wants aromaticity detection, he plugs the > aromaticity > detector behind the SMILES parser. He can also run a check before > that, > if there is already any aromaticity information return by the SMILES > parser and run the AromaticityDetector only conditionally. I think > this > is the right way to do it for a Lego(TM)-like library. I agree - ideally the SMILES parser should not do aromaticity. That way, dealing with molecules from any input format, will be consistent ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- If you don't get a good night kiss, you get Kafka dreams." -Hobbes |
From: Christoph S. <ste...@eb...> - 2009-01-14 15:58:59
|
Ok, I filed a bug on this. Cheers, Chris Rajarshi Guha wrote: > On Jan 14, 2009, at 10:45 AM, Christoph Steinbeck wrote: > >> Rajarshi Guha wrote: >>> On Jan 14, 2009, at 4:53 AM, Christoph Steinbeck wrote: >>> >>>> I think that the SMILES parser should return a molecule with all >>>> information *explicitly* encoded in the SMILES, which, in my >>>> opinion, is >>>> element symbols, bonds, bond orders and aromaticity. >>> What if the input SMILES is C1C=CC=CC1? >> Then the molecule is not aromatic anyway :-) >> But seriously, as I said in my other email to Nikolay, I think the >> parser should return what is in the SMILES, which in your case is >> single >> and double bonds. >> If the programmer wants aromaticity detection, he plugs the >> aromaticity >> detector behind the SMILES parser. He can also run a check before >> that, >> if there is already any aromaticity information return by the SMILES >> parser and run the AromaticityDetector only conditionally. I think >> this >> is the right way to do it for a Lego(TM)-like library. > > I agree - ideally the SMILES parser should not do aromaticity. That > way, dealing with molecules from any input format, will be consistent > > ------------------------------------------------------------------- > Rajarshi Guha <rg...@in...> > GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 > ------------------------------------------------------------------- > If you don't get a good night kiss, you get Kafka dreams." > -Hobbes > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <ego...@gm...> - 2009-01-14 16:44:50
|
On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: > Ok, I filed a bug on this. Guys, how do you plan to handle: c1ccc1 ? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2009-01-14 16:55:46
|
On Jan 14, 2009, at 11:44 AM, Egon Willighagen wrote: > On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: >> Ok, I filed a bug on this. > > Guys, how do you plan to handle: > > c1ccc1 What do you mean? Currently, the aromaticity detector in parse should not perceive it as aromatic. if the aromaticity perception is moved out of the parser, we should end up with the same result. ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- Writing software is more fun than working. |
From: Egon W. <ego...@gm...> - 2009-01-14 17:04:02
|
On 1/14/09, Rajarshi Guha <rg...@in...> wrote: > On Jan 14, 2009, at 11:44 AM, Egon Willighagen wrote: > > On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: > > Guys, how do you plan to handle: > > > > c1ccc1 > > What do you mean? Currently, the aromaticity detector in parse should > not perceive it as aromatic. if the aromaticity perception is moved > out of the parser, we should end up with the same result. I really don't want to have the discussion about this yet another time... please do check the mailing list archives of the past year... see also my comment to Chris' bug report. Point I wanted to make is, that SMILES does not really have a concept of aromaticity... Which means that c1ccc1 is not aromatic, while c1ccccc1 is... At least the OpenSMILES specs does not allow CccC, which is OK for Daylight Depict... Do we support SMILES or OpenSMILES in our parser? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2009-01-14 17:10:50
|
On Jan 14, 2009, at 12:03 PM, Egon Willighagen wrote: > I really don't want to have the discussion about this yet another > time... please do check the mailing list archives of the past year... > see also my comment to Chris' bug report. > > Point I wanted to make is, that SMILES does not really have a concept > of aromaticity... > Which means that c1ccc1 is not aromatic, while c1ccccc1 is... > > At least the OpenSMILES specs does not allow CccC, which is OK for > Daylight Depict... Do we support SMILES or OpenSMILES in our parser? I'm getting a little confused :) The original question was: does the parser do aromaticity perception? Or does the user do it? This seems to be independent of the actual parsing step, since the call to CDKHueckelAromaticity detector is after getting back a parsed molecule. ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- |
From: Christoph S. <ste...@eb...> - 2009-01-14 18:08:55
|
I really think we should read in what we get, not more but also not less. If we start validating things inside the SMILES parser, we get into a lot of trouble and a never ending story. So, I think c1ccc1 should result in a 4-membered ring with all aromaticity flags set. It might be an error or someone wants to tell us something he considers important. :-) Again, afterwards, there can be a Validator running over what the SMILES parser returned. This concept is modular and removes decencies. Cheers, Chris Egon Willighagen wrote: > On 1/14/09, Rajarshi Guha <rg...@in...> wrote: >> On Jan 14, 2009, at 11:44 AM, Egon Willighagen wrote: >> > On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: >> > Guys, how do you plan to handle: >> > >> > c1ccc1 >> >> What do you mean? Currently, the aromaticity detector in parse should >> not perceive it as aromatic. if the aromaticity perception is moved >> out of the parser, we should end up with the same result. > > I really don't want to have the discussion about this yet another > time... please do check the mailing list archives of the past year... > see also my comment to Chris' bug report. > > Point I wanted to make is, that SMILES does not really have a concept > of aromaticity... > Which means that c1ccc1 is not aromatic, while c1ccccc1 is... > > At least the OpenSMILES specs does not allow CccC, which is OK for > Daylight Depict... Do we support SMILES or OpenSMILES in our parser? > > Egon > -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <ego...@gm...> - 2009-01-14 18:27:09
|
On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: > So, I think c1ccc1 should result in a 4-membered ring with all > aromaticity flags set. That's not what the SMILES says... not even in OpenSMILES, which is more strictly defined. 'c' is not an aromatic SMILES. Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Nikolay K. <ni...@un...> - 2009-01-14 13:46:03
|
> I think that the SMILES parser should return a molecule with all > information *explicitly* encoded in the SMILES, which, in my opinion, is > element symbols, bonds, bond orders and aromaticity. > Any additional information needed to deduce this may also be computed. > Still, I would think that there is no need to run the aromaticity > detector. Atoms are coded as aromatic explicitly, so no detection needed > there. > > Can anyone remind me why we need to run the Aromaticity Detection inside > the SMILES parser then? > IMHO In some cases aromaticity detection would be needed because there at least two ways in SMILES standard to define aromaticity. For example benzene can be represented by: c1ccccc1 and C1=CC=CC=C1 For the second case aromaticity detection would be need Best regards Nick |
From: Nina J. <ni...@ac...> - 2009-01-14 13:51:42
|
Nikolay Kochev wrote: >> I think that the SMILES parser should return a molecule with all >> information *explicitly* encoded in the SMILES, which, in my opinion, is >> element symbols, bonds, bond orders and aromaticity. >> Any additional information needed to deduce this may also be computed. >> Still, I would think that there is no need to run the aromaticity >> detector. Atoms are coded as aromatic explicitly, so no detection needed >> there. >> >> Can anyone remind me why we need to run the Aromaticity Detection inside >> the SMILES parser then? >> >> > > IMHO > In some cases aromaticity detection would be needed because there at least > two ways in SMILES standard to define aromaticity. > For example benzene can be represented by: > c1ccccc1 and C1=CC=CC=C1 > For the second case aromaticity detection would be need > ... and bond order detection for the first case. Best regards, Nina > Best regards > Nick > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |
From: Christoph S. <ste...@eb...> - 2009-01-14 15:40:34
|
Nikolay Kochev wrote: >> I think that the SMILES parser should return a molecule with all >> information *explicitly* encoded in the SMILES, which, in my opinion, is >> element symbols, bonds, bond orders and aromaticity. >> Any additional information needed to deduce this may also be computed. >> Still, I would think that there is no need to run the aromaticity >> detector. Atoms are coded as aromatic explicitly, so no detection needed >> there. >> >> Can anyone remind me why we need to run the Aromaticity Detection inside >> the SMILES parser then? >> > > IMHO > In some cases aromaticity detection would be needed because there at least > two ways in SMILES standard to define aromaticity. > For example benzene can be represented by: > c1ccccc1 and C1=CC=CC=C1 > For the second case aromaticity detection would be need Right, but in that second case, the CDK policy holds that we do not do more than neccessary. As a library, we provide components, so if the developers who uses the SMILES parser in his code wants this aromaticity information, the smiles parser needs to send by a molecule with double and single bonds in the benzene ring and the programmer needs to code a line of aromaticity detection after smiles parsing. That was the policy that Rajarshi was referring to and I think it is a very good one. We do LEGO after all :-) Cheers, Chris -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Rajarshi G. <rg...@in...> - 2009-01-14 15:43:33
|
On Jan 14, 2009, at 10:40 AM, Christoph Steinbeck wrote: >> >> IMHO >> In some cases aromaticity detection would be needed because there >> at least >> two ways in SMILES standard to define aromaticity. >> For example benzene can be represented by: >> c1ccccc1 and C1=CC=CC=C1 >> For the second case aromaticity detection would be need > > Right, but in that second case, the CDK policy holds that we do not do > more than neccessary. As a library, we provide components, so if the > developers who uses the SMILES parser in his code wants this > aromaticity > information, the smiles parser needs to send by a molecule with double > and single bonds in the benzene ring and the programmer needs to > code a > line of aromaticity detection after smiles parsing. > That was the policy that Rajarshi was referring to and I think it is a > very good one. We do LEGO after all :-) The problem is the fact that sometimes a SMILES will have explicit aromaticity and sometimes not - implying that it always has to aromaticity perception, wich breaks the policy. Overall, it's OK by me as long as it's documented somewhere that this is a special case. (Of course a caching scheme would remove the need for the user to worry about this) ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- Finally I am becoming stupider no more - Paul Erdos' epitaph |
From: Nina J. <ni...@ac...> - 2009-01-14 16:51:07
|
Christoph Steinbeck wrote: > Nikolay Kochev wrote: > >>> I think that the SMILES parser should return a molecule with all >>> information *explicitly* encoded in the SMILES, which, in my opinion, is >>> element symbols, bonds, bond orders and aromaticity. >>> Any additional information needed to deduce this may also be computed. >>> Still, I would think that there is no need to run the aromaticity >>> detector. Atoms are coded as aromatic explicitly, so no detection needed >>> there. >>> >>> Can anyone remind me why we need to run the Aromaticity Detection inside >>> the SMILES parser then? >>> >>> >> IMHO >> In some cases aromaticity detection would be needed because there at least >> two ways in SMILES standard to define aromaticity. >> For example benzene can be represented by: >> c1ccccc1 and C1=CC=CC=C1 >> For the second case aromaticity detection would be need >> > > Right, but in that second case, the CDK policy holds that we do not do > more than neccessary. As a library, we provide components, so if the > developers who uses the SMILES parser in his code wants this aromaticity > information, the smiles parser needs to send by a molecule with double > and single bonds in the benzene ring and the programmer needs to code a > line of aromaticity detection after smiles parsing. > When parsing "c1ccccc1" the parser have a knowledge aromaticity detection is not necessary, while it might be for the second case. Leaving this processing for outside of the parser, the programmer will need to do aromaticity detection after any invocation of the SMILES parser, just for consistency. Not considering the performance penalty, this kind of approach will lead (leads already) to lot of misunderstanding and plenty of bug reports (IMHO ). Regards, Nina > That was the policy that Rajarshi was referring to and I think it is a > very good one. We do LEGO after all :-) > > Cheers, > > Chris > > |
From: Rajarshi G. <rg...@in...> - 2009-01-14 16:59:04
|
On Jan 14, 2009, at 11:51 AM, Nina Jeliazkova wrote: > Leaving this processing for outside of the parser, the programmer > will need to do aromaticity detection after any invocation of the > SMILES parser, just for consistency. But this is standard protocol for molecules read in from other formats > Not considering the performance penalty, this kind of approach will > lead (leads already) to lot of misunderstanding and plenty of bug > reports (IMHO ). Then the more fundamental decision is to decide whether input code must perform aromaticity within the code or leave it to the user. As long as it's documented, I don't see why it should be a problem if the user has to run aromaticity etc. With respect to performance - I agree it can be bad. But to address that I think we need to think about caching, dirty flags etc, rather than hack around the problem. But this would be a long term goal ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84 ------------------------------------------------------------------- I saw Elvis. He sat between me and Bigfoot on the UFO. |
From: Christoph S. <ste...@eb...> - 2009-01-14 22:38:55
|
Egon Willighagen wrote: > On 1/14/09, Christoph Steinbeck <ste...@eb...> wrote: >> So, I think c1ccc1 should result in a 4-membered ring with all >> aromaticity flags set. > > That's not what the SMILES says... not even in OpenSMILES, which is > more strictly defined. 'c' is not an aromatic SMILES. Who knows what the SMILES says - in this respect. You will remember that we've discussed this again and again and we never found one normative source. Cheers, Chris -- Dr. Christoph Steinbeck Head of Chemoinformatics and Metabolism European Bioinformatics Institute (EBI) Wellcome Trust Genome Campus Hinxton, Cambridge CB10 1SD UK Phone +44 1223 49 2640 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |