From: Rajarshi G. <rg...@in...> - 2007-10-27 19:11:51
|
Hi, while adding a new atom type I have to add the entry to the XML file but also add code to CDKAtomTypeMatcher I'm curious as to why I would need to add code to a source file to match a new atom type? Shouldn't the code be able to know all available atom types and then find a matching one on its own? Why is the current class designed so that individual atoms (O, N, C etc) are matched in separate functions? It appears that much of these individual functions have very similar code ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Science kind of takes the fun out of the portent business. -Hobbes |
From: Egon W. <ego...@gm...> - 2007-10-28 09:08:13
|
On 10/27/07, Rajarshi Guha <rg...@in...> wrote: > Shouldn't the code be able to know all available atom types and then > find a matching one on its own? No, that's the approach we used in the past, and which does not work. For example, because of missing information. > Why is the current class designed so > that individual atoms (O, N, C etc) are matched in separate > functions? It appears that much of these individual functions have > very similar code Just organization. It could have easily done perceiveChargedAtoms() etc. But I like it this way. Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Egon W. <ego...@gm...> - 2007-10-29 12:46:23
|
On 10/28/07, Egon Willighagen <ego...@gm...> wrote: > On 10/27/07, Rajarshi Guha <rg...@in...> wrote: > > Shouldn't the code be able to know all available atom types and then > > find a matching one on its own? > > No, that's the approach we used in the past, and which does not work. > For example, because of missing information. The old SaturationChecker and ValencyChecker's work this way. Practically, it is very difficult to model uncharged, charged and radicals for a variety of of elements in a simple set of rules. Therefore, better go for a more complex, but organized, set of rules. Note that many other atom typing schemes even used SMARTS queries for each atom type. This is, for example, what OB does too. > > Why is the current class designed so > > that individual atoms (O, N, C etc) are matched in separate > > functions? It appears that much of these individual functions have > > very similar code > > Just organization. It could have easily done perceiveChargedAtoms() > etc. But I like it this way. Actually, I think this makes most sense as elements are the key to chemical properties. In some cases, one may take advantage of isoelectronic properties of a series of elements, which is why there is a perceiveHalogens() method. I can very well image that these methods may collapse to something like: public IAtomType perceiveIsoElectronicBlaTypes(IAtom) { if (elementIsAIsoelectronicBlaAtom(IAtom.getSymbol())) { // proceed } } I will recode perceiveHalogens() accordingly. Egon -- ---- http://chem-bla-ics.blogspot.com/ |