design question: conformers in IAtomContainer

[nightly.py]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Matt's post led me to thinking about how we handle conformers.  
Currently a collection of conformers for a molecule is represented as  
a ConformerContainer - whose semantics are essentially that of a  
List<IAtomContainer>

However I was wondering whether it might not be better to modify  
IAtomContainer itself to store conformers. The motivation is that the  
semantics are closer to the way we think about conformers  for a  
molecule -  as a property of that molecule.

Implementation-wise, the only that'd change in IAtomContainer is the  
way coordinates are handled - but would essentially be a copy of the  
current ConformerContainer approach: List<Point3D[]>. By default, if  
there are no conformers, the list would have one element and methods  
such as getPoint3D() which would either just take the coordinates  
from the first element.

One could change the current conformer to something else using  
setConformer(int)

The downside to this approach is that it's not clear what it means to  
'loop over conformers'. Should it return a new IAtomContainer at  
every iteration? Similarly what would getConformer(int)  mean? Does  
it make sense for an IAtomContainer to 'produce' another IAtomContainer?

Another downside is that since atom/bond manipulation is a core  
feature of IAtomContainer, these operations would now have to take  
into account the coordinates list as well. This could lead to slow  
down on common operations which might not be a good idea

If this is interesting, I'll put in a feature request.

- -------------------------------------------------------------------
Rajarshi Guha  <rguha@...>
GPG Fingerprint: D070 5427 CC5B 7938 929C  DD13 66A1 922C 51E7 9E84
- -------------------------------------------------------------------
All the passions make us commit faults; love makes us commit the most
ridiculous ones.
        -- La Rochefoucauld


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiCCiMACgkQZqGSLFHnnoQTaACePOHOfJQPx3R1OdUtbgkjAhB8
shkAoIWqB7gVtSihhbgeMMTY1Io1Dykk
=10BA
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cdk-devel mailing list
Cdk-devel@...
https://lists.sourceforge.net/lists/listinfo/cdk-devel

[Christoph Steinbeck-4]

While I can see the virtues of your suggestion to have AtomContainer
handle all the information about all its conformers, I would rather go
with the "old-fashoned" approach.
It would require much less reengineering of things. All the I/O, all the
classes dealing of properties of 3D (Energies, distances, etc) would
otherwise need to be rewritten and in many cases, arbitrary choices
would have to be made on which conformer to look at.

Cheers,

Chris

Rajarshi Guha wrote:

> Hi, Matt's post led me to thinking about how we handle conformers.  
> Currently a collection of conformers for a molecule is represented as  
> a ConformerContainer - whose semantics are essentially that of a  
> List<IAtomContainer>
>
> However I was wondering whether it might not be better to modify  
> IAtomContainer itself to store conformers. The motivation is that the  
> semantics are closer to the way we think about conformers  for a  
> molecule -  as a property of that molecule.
>
> Implementation-wise, the only that'd change in IAtomContainer is the  
> way coordinates are handled - but would essentially be a copy of the  
> current ConformerContainer approach: List<Point3D[]>. By default, if  
> there are no conformers, the list would have one element and methods  
> such as getPoint3D() which would either just take the coordinates  
> from the first element.
>
> One could change the current conformer to something else using  
> setConformer(int)
>
> The downside to this approach is that it's not clear what it means to  
> 'loop over conformers'. Should it return a new IAtomContainer at  
> every iteration? Similarly what would getConformer(int)  mean? Does  
> it make sense for an IAtomContainer to 'produce' another IAtomContainer?
>
> Another downside is that since atom/bond manipulation is a core  
> feature of IAtomContainer, these operations would now have to take  
> into account the coordinates list as well. This could lead to slow  
> down on common operations which might not be a good idea
>
> If this is interesting, I'll put in a feature request.
>
> -------------------------------------------------------------------
> Rajarshi Guha  <rguha@...>
> GPG Fingerprint: D070 5427 CC5B 7938 929C  DD13 66A1 922C 51E7 9E84
> -------------------------------------------------------------------
> All the passions make us commit faults; love makes us commit the most
> ridiculous ones.
> -- La Rochefoucauld
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cdk-devel mailing list
Cdk-devel@...
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 [phone]

What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cdk-devel mailing list
Cdk-devel@...
https://lists.sourceforge.net/lists/listinfo/cdk-devel

[nightly.py]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 20, 2008, at 6:53 AM, Christoph Steinbeck wrote:
> While I can see the virtues of your suggestion to have  
> AtomContainer handle all the information about all its conformers,  
> I would rather go with the "old-fashoned" approach.
> It would require much less reengineering of things. All the I/O,  
> all the classes dealing of properties of 3D (Energies, distances,  
> etc) would otherwise need to be rewritten and in many cases,  
> arbitrary choices would have to be made on which conformer to look at.

Aah, that's true.

- -------------------------------------------------------------------
Rajarshi Guha  <rguha@...>
GPG Fingerprint: D070 5427 CC5B 7938 929C  DD13 66A1 922C 51E7 9E84
- -------------------------------------------------------------------

A list is only as strong as its weakest link.
                -- Don Knuth


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiDPSYACgkQZqGSLFHnnoQjbACeNLdVtkTMQdcDC+95SeAfUgxS
YYMAn3+h6ysnP8t0GXFPaGYeswXvnweP
=EW5A
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cdk-devel mailing list
Cdk-devel@...
https://lists.sourceforge.net/lists/listinfo/cdk-devel