"Egon Willighagen" <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 9:46 AM, Nina Jeliazkova <[EMAIL PROTECTED]> wrote: > > > The QSAR descriptor classes are just (or should be) just wrappers > > > around actual functionality... if there is some property for which the > > > given substructure is interesting to be colored, it should have been > > > available as separate API anyway... > > > > IMHO, this approach can complicate the code. Suppose I am calculating a > > descriptor, that relies on finding set fragments. As a result, I would like > > not only the final (numerical) value, but also the set of fragments (atom > > and bonds) that had been used in the calculation. The most elegant approach > > will need nothing different than descriptor API; > > The descriptor API just defines how to get to a data matrix with column names.
data matrix might be extended beyound simple numeric types. > > > it will be rather awkward > > to peek the internals of the descriptor calculation via separate calls. > > Actually, peeking at the internals is important! CDK is not an end > product, it's a development library and an educational tool. We don't > want black boxes. > > > > So, I don't think we should extend the QSAR descriptor API with such > > > functionality. > > > > What about just introducing a class, that will implement DescriptorResult > > interface, but will also provide the desired functionality (selected > > atoms/bonds)? Thus descriptor API will not be extended at all, just the > > descriptors where "selection" is relevant will return the relevant class. > > I'm against this idea; I really think we should split algorithms from > descriptors... what you are really interested in, is the outcome of > some algorithm, not so much the calculated values. The descriptor API > is about the latter, our convenience black box approach, which is why > the should only be wrapping. The algorithm, instead, should allow > peaking at details, such as which *bla* has been used to get to the > numeric outcome. > Yes, exactly, but relying on nonunified API for different algorithms complicates the final use of the library. No intention for supporting black boxes or flaming! Nina > IMO > > Egon ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Cdk-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cdk-user
