From: Nina J. <ni...@ac...> - 2008-05-22 15:26:16
|
Rajarshi Guha <rg...@in...> 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 <rg...@in...> > 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----- > |