Another request on the descriptor theme (which has been discussed
before):
I still would like to get an optional AtomContainer or
AtomContainerSet back from the descriptorcalculation, in order to be
able to visualize it in 2D/3D. I'm aware that not all descriptors
support this, but I'd like the possibility. For example, if a
descriptor can be visualized by coloring atoms/bonds of the molecule
in 2D, that would be nice to display as output.
Cheers,
.../Ola
On May 22, 2008, at 17:26 , Nina Jeliazkova wrote:
> Rajarshi Guha <[EMAIL PROTECTED]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On May 22, 2008, at 2:08 AM, Nina Jeliazkova wrote:
>>> Rajarshi Guha wrote:
>>>>
>>>> Hmm, making the top class an array type would be a good idea. But
>>>> at one point you'd need to know the type of the result (numeric,
>>>> string, boolean) to do something with it. Since the top class
>>>> would probably be an array of Object
>>>>
>>> What about
>>>
>>> public interface IDescriptorResult<T> extends Iterator<T> {
>>> double doubleValue();
>>> int intValue();
>>> String stringValue();
>>> ...
>>> //or even
>>> double convert(T value);
>>> String convert(T value);
>>> }
>>>
>>> Then there could be a top class based on T[] , but also another one
>>> based on other collections.
>>
>> Can you give some example (pseudo) code of how one might use this? It
>> still seems that I need to check the specific type of the descriptor
>> result to know what to do with it. So if I don't know whether a
>> descriptor returns a String or a double, how would the above design
>> help me avoid doing an instanceof check?
>>
>
> Well, I guess it depends what one needs to do with the results.
> If just for printing / displaying in UI, one doesn't need to know
> what type
> is, just get the string value (could be property formatted by
> default, not
> just Double.toString()).
>
> The same (perhaps) is true for saving in a file.
>
> If the intention is to submit values to a QSAR model, then the best
> is to have
> the types into the schema, and to e.g. avoid using a descriptor,
> generating
> String values in a linear regression.
>
> If I would like to store double values into a DB table, I'll most
> probably not
> care if the result is float, integer or boolean since all can be
> (safely)
> stored in the predefined numeric field in the table, therefore
> double() value
> should be fine. I would not like to store String value into such
> table, so
> better not to calculate such descriptor at all , and be able to
> recognise this
> beforehand. There could be a different table (and different
> workflow) for e.g.
> String descriptors.
>
> Following an approach with generics, it will be possible to refactor
> Fingerprinter as a descriptor - which is logical IMHO - and the
> result type
> might be IDescriptorResult<BitSet>.
>
> I might be well missing something - do you have in mind some case
> it is
> necessary to know the type?
>
>>> Just came to my mind this is not far away from jdbc ResultSet
>>> interface http://java.sun.com/j2se/1.4.2/docs/api/java/sql/
>>> ResultSet.html - see lot of getXXX() methods in there.
>>
>> Right, but invariably, you will now the type of the columns in your
>> schema. And so you can use the appropriate getXXX() method at compile
>> time
>>
>>> A step further might be to introduce the short descriptor name into
>>> IDescriptorResult interface, rather than in a separate array.
>>
>> Well this would imply that the short names only became available
>> after the descriptor has been calculated, since getting the
>> descriptor result object before calculation, though doable, seems to
>> make the semantics a little wierd.
>
> Right, although it will be good to have both, if possible.
>
>>
>> What about have the descriptor names as part of the specific
>> descriptor class (static method?)? That's actually an easy fix (add a
>> method in the IMolecularDescriptor interface), just needs some
>
> I agree the names should be static (not instantiated on every
> descriptor
> calculation).
>
> But, if I remember correct, you can't add a static method to an
> interface. If
> it becomes a class methos, this limits the use of the
> IMolecularDescriptor
> interface ...
>
>
> Regards,
> Nina
>
> grunt
>> work to move the code around. I can probably get to this after June
>> 4, so if you can put in a feature request to remind me. Of course,
>> you are free to do this as well :)
>>
>> - -------------------------------------------------------------------
>> Rajarshi Guha <[EMAIL PROTECTED]>
>> GPG Fingerprint: D070 5427 CC5B 7938 929C DD13 66A1 922C 51E7 9E84
>> - -------------------------------------------------------------------
>> A mathematician is a device for turning coffee into theorems.
>> -- P. Erdos
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.8 (Darwin)
>>
>> iEYEARECAAYFAkg1eLcACgkQZqGSLFHnnoQ5jQCgtKnNbvM36NxVcHgQcMKO0y++
>> x78AoL4x5hwzoKv6rQ9gLx4SJQRFGfUS
>> =V6py
>> -----END PGP SIGNATURE-----
>>
>
>
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Cdk-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cdk-user
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cdk-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdk-user
