From: Egon W. <ego...@gm...> - 2008-01-18 08:02:47
|
On Jan 17, 2008 8:34 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 17, 2008, at 3:05 AM, Nina Jeliazkova wrote: > > public boolean matches(IAtom atom) { > > // TODO: this is just a hack for a few > > if (atom.getAtomicNumber() != 0) { > > return (atom.getAtomicNumber() == getAtomicNumber()); > > } > > if (atom.getSymbol().equals("C")) { > > return getAtomicNumber() == 6; > > } else if (atom.getSymbol().equals("O")) { > > return getAtomicNumber() == 8; > > } else if (atom.getSymbol().equals("N")) { > > return getAtomicNumber() == 7; > > } > > return false; > > } > > } > > > > and the less obvious one why atom.getAtomicNumber() returns zero > > and then falls into the next conditions to match atomic number by > > symbol. > > I think this is for the case where a SMARTS may contain a wild card > atom (say any aromatic or any aliphatic) - in which case the atom > will be of class PseudoAtom and have an atomic number of 0 I haven't quite looked at the bug report, but "C" versus '6' has been something on my mind for some time... Though I have not done any serious benchmarking.... the use of not-final Strings and String in itself is more memory demanding than using the atomic number... And, this does relate to the bug I think... because constructing an IAtom with String now, does not automatically set the atomic number... I think we need to discuss the default way of constructing elemental atoms. Maybe we should totally deprecate IAtom(String) in favor of IAtom(IElement) and IAtom(int atomicNumber)... Oh, while at it... I really like to see that int to become a short (we're quite far away from the discovery of the element with atomic number 256)... tiny memory gain, but all bits help... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Thomas K. <tho...@we...> - 2008-01-18 08:35:33
|
What is with an enum? Cheers, Thomas -----Urspr=FCngliche Nachricht----- Von: cdk...@li... [mailto:cdk...@li...] Im Auftrag von Egon Willighagen Gesendet: Freitag, 18. Januar 2008 09:03 An: Rajarshi Guha Cc: cdkdevel; Nina Jeliazkova Betreff: [Cdk-devel] RFC: atomic number versus symbol (was: smarts.AtomicNumberAtom bug (was HydrogenAdder)) On Jan 17, 2008 8:34 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 17, 2008, at 3:05 AM, Nina Jeliazkova wrote: > > public boolean matches(IAtom atom) { > > // TODO: this is just a hack for a few > > if (atom.getAtomicNumber() !=3D 0) { > > return (atom.getAtomicNumber() =3D=3D = getAtomicNumber()); > > } > > if (atom.getSymbol().equals("C")) { > > return getAtomicNumber() =3D=3D 6; > > } else if (atom.getSymbol().equals("O")) { > > return getAtomicNumber() =3D=3D 8; > > } else if (atom.getSymbol().equals("N")) { > > return getAtomicNumber() =3D=3D 7; > > } > > return false; > > } > > } > > > > and the less obvious one why atom.getAtomicNumber() returns zero > > and then falls into the next conditions to match atomic number by > > symbol. > > I think this is for the case where a SMARTS may contain a wild card > atom (say any aromatic or any aliphatic) - in which case the atom > will be of class PseudoAtom and have an atomic number of 0 I haven't quite looked at the bug report, but "C" versus '6' has been something on my mind for some time... Though I have not done any serious benchmarking.... the use of not-final Strings and String in itself is more memory demanding than using the atomic number... And, this does relate to the bug I think... because constructing an IAtom with String now, does not automatically set the atomic number... I think we need to discuss the default way of constructing elemental atoms. Maybe we should totally deprecate IAtom(String) in favor of IAtom(IElement) and IAtom(int atomicNumber)... Oh, while at it... I really like to see that int to become a short (we're quite far away from the discovery of the element with atomic number 256)... tiny memory gain, but all bits help... Egon --=20 ---- http://chem-bla-ics.blogspot.com/ -------------------------------------------------------------------------= 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-devel mailing list Cdk...@li... https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: Egon W. <ego...@gm...> - 2008-01-18 08:46:56
|
On Jan 18, 2008 9:35 AM, Thomas Kuhn <tho...@we...> wrote: > What is with an enum? That could be used for enumerating all elements, like: enum Symbols { HYDROGEN, ..., CARBON, ... } There is a class Symbols in cdk.config... and also an Elements, which allows: new Atom(Elements.CARBON) But this Elements class have all fields as Element, and not DebugElement or NNElement... That's fine, except for the hard coded dependency on the data module... Actually, while talking about this... I have been pondering about a more involving change to the core data classes... To have IElement and IAtomType fields instead of super classes... So, public class IAtom { IAtomType atomType; IElement element; } Maybe even only IAtomType, if you consider an IElement a special case of an IAtomType, that is, one without any additional properties like hybridization state and formal charge... but that requires some ontological changes... This has the advantage that: 1. we have atom type fields in a static final way. the set of atom types is limited, while IAtom instances are very abundant. Say, 1000 atom types (considering several schemes) and many thousands of atoms for a reasonably sized SD or PDB file. 2. the default memory consumption drops anyway, if no atom Type has been set... 3. it's easier to see if atom type perception has been performed Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 13:06:45
|
On Jan 18, 2008, at 3:46 AM, Egon Willighagen wrote: > On Jan 18, 2008 9:35 AM, Thomas Kuhn <tho...@we...> wrote: >> What is with an enum? > > That could be used for enumerating all elements, like: > > enum Symbols { > HYDROGEN, > ..., > CARBON, > ... > } > > There is a class Symbols in cdk.config... and also an Elements, > which allows: > > new Atom(Elements.CARBON) This is nice, but I wonder how much of a performance we observe by having a String constructor, since doing new IAtom("C") is pretty intuitive > To have IElement and IAtomType fields instead of super classes... > > So, > > public class IAtom { > > IAtomType atomType; > IElement element; > > } > > Maybe even only IAtomType, if you consider an IElement a special case > of an IAtomType, that is, one without any additional properties like > hybridization state and formal charge... but that requires some > ontological changes... > > 2. the default memory consumption drops anyway, if no atom Type has > been set... > 3. it's easier to see if atom type perception has been performed If you only have an atom type field and no perception was done, what details of the atom are available? ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- The emacs religion: to be saved, control excess... |
From: Egon W. <ego...@gm...> - 2008-01-18 13:13:09
|
On Jan 18, 2008 2:06 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 18, 2008, at 3:46 AM, Egon Willighagen wrote: > > new Atom(Elements.CARBON) > > This is nice, but I wonder how much of a performance we observe by > having a String constructor, since doing new IAtom("C") is pretty > intuitive The proper way of testing things would be to process a 10MB SD file, with two versions of the MDLV2000Reader... one that uses: new Atom(foundElement) (current version) and one that uses: new Atom(int bla) which would use Symbols for implementing getSymbol() and with no IElement.symbol field. Sounds like an excellent junior job... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 13:09:41
|
On Jan 18, 2008, at 3:02 AM, Egon Willighagen wrote: > On Jan 17, 2008 8:34 PM, Rajarshi Guha <rg...@in...> wrote: >> On Jan 17, 2008, at 3:05 AM, Nina Jeliazkova wrote: >>> public boolean matches(IAtom atom) { >>> // TODO: this is just a hack for a few >>> if (atom.getAtomicNumber() != 0) { >>> return (atom.getAtomicNumber() == getAtomicNumber()); >>> } >>> if (atom.getSymbol().equals("C")) { >>> return getAtomicNumber() == 6; >>> } else if (atom.getSymbol().equals("O")) { >>> return getAtomicNumber() == 8; >>> } else if (atom.getSymbol().equals("N")) { >>> return getAtomicNumber() == 7; >>> } >>> return false; >>> } >>> } >>> >>> and the less obvious one why atom.getAtomicNumber() returns zero >>> and then falls into the next conditions to match atomic number by >>> symbol. >> >> I think this is for the case where a SMARTS may contain a wild card >> atom (say any aromatic or any aliphatic) - in which case the atom >> will be of class PseudoAtom and have an atomic number of 0 > > And, this does relate to the bug I think... because constructing an > IAtom with String now, does not automatically set the atomic number... Shouldn't this be a bug? > I think we need to discuss the default way of constructing elemental > atoms. Maybe we should totally deprecate IAtom(String) in favor of > IAtom(IElement) and IAtom(int atomicNumber)... At least for the latter case, you'd be setting a symbol right? > Oh, while at it... I really like to see that int to become a short > (we're quite far away from the discovery of the element with atomic > number 256)... tiny memory gain, but all bits help... I would like to see how much of an advantage short would be before such a change is made ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- A list is only as strong as its weakest link. -- Don Knuth |
From: Egon W. <ego...@gm...> - 2008-01-18 13:15:45
|
On Jan 18, 2008 2:06 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 18, 2008, at 3:46 AM, Egon Willighagen wrote: > > 3. it's easier to see if atom type perception has been performed > > If you only have an atom type field and no perception was done, what > details of the atom are available? Point2d/Point3d/CrystalCoords... PartialCharge Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Egon W. <ego...@gm...> - 2008-01-18 13:19:27
|
On Jan 18, 2008 2:09 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 18, 2008, at 3:02 AM, Egon Willighagen wrote: > > On Jan 17, 2008 8:34 PM, Rajarshi Guha <rg...@in...> wrote: > > And, this does relate to the bug I think... because constructing an > > IAtom with String now, does not automatically set the atomic number... > > Shouldn't this be a bug? No. It was never formalized that IAtom(String) should only accept element symbols + "R"... The IPseudoAtom was only added later... > > I think we need to discuss the default way of constructing elemental > > atoms. Maybe we should totally deprecate IAtom(String) in favor of > > IAtom(IElement) and IAtom(int atomicNumber)... > > At least for the latter case, you'd be setting a symbol right? No, actually not. Instead IElement.getSymbol() would return a final static from Symbols... and the IElement.symbol would be removed. One less useless pointer... obviously, IPseudoAtom would have the label field... > > Oh, while at it... I really like to see that int to become a short > > (we're quite far away from the discovery of the element with atomic > > number 256)... tiny memory gain, but all bits help... > > I would like to see how much of an advantage short would be before > such a change is made Yes, of course... another nice junior job... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 13:31:22
|
On Jan 18, 2008, at 8:15 AM, Egon Willighagen wrote: > On Jan 18, 2008 2:06 PM, Rajarshi Guha <rg...@in...> wrote: >> On Jan 18, 2008, at 3:46 AM, Egon Willighagen wrote: >>> 3. it's easier to see if atom type perception has been performed >> >> If you only have an atom type field and no perception was done, what >> details of the atom are available? > > Point2d/Point3d/CrystalCoords... > PartialCharge Where would the symbol and atomic number come from? ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Gods are fragile things; they may be killed by a whiff of science or a dose of common sense. -- Chapman Cohen |
From: Egon W. <ego...@gm...> - 2008-01-18 13:31:56
|
On Jan 18, 2008 2:28 PM, Rajarshi Guha <rg...@in...> wrote: > Where would the symbol and atomic number come from? IElement. E. -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 13:31:53
|
On Jan 18, 2008, at 8:19 AM, Egon Willighagen wrote: > On Jan 18, 2008 2:09 PM, Rajarshi Guha <rg...@in...> wrote: >> On Jan 18, 2008, at 3:02 AM, Egon Willighagen wrote: >>> On Jan 17, 2008 8:34 PM, Rajarshi Guha <rg...@in...> wrote: >>> And, this does relate to the bug I think... because constructing an >>> IAtom with String now, does not automatically set the atomic >>> number... >> >> Shouldn't this be a bug? > > No. It was never formalized that IAtom(String) should only accept > element symbols + "R"... > The IPseudoAtom was only added later... I'm not sure I understand this. Why wouldn't the atomic number available given a symbol? I thought that pseudo atoms were defined to have atomic number 0 > >>> I think we need to discuss the default way of constructing elemental >>> atoms. Maybe we should totally deprecate IAtom(String) in favor of >>> IAtom(IElement) and IAtom(int atomicNumber)... >> >> At least for the latter case, you'd be setting a symbol right? > > No, actually not. Instead IElement.getSymbol() would return a final > static from Symbols... and the IElement.symbol would be removed. One > less useless pointer... obviously, IPseudoAtom would have the label > field... Aah, OK ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- All the passions make us commit faults; love makes us commit the most ridiculous ones. -- La Rochefoucauld |
From: Egon W. <ego...@gm...> - 2008-01-18 13:33:38
|
On Jan 18, 2008 2:30 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 18, 2008, at 8:19 AM, Egon Willighagen wrote: > I'm not sure I understand this. Why wouldn't the atomic number > available given a symbol? I thought that pseudo atoms were defined to > have atomic number 0 I think only because we do/did not have NULL for that field yet? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 13:36:53
|
On Jan 18, 2008, at 8:33 AM, Egon Willighagen wrote: > On Jan 18, 2008 2:30 PM, Rajarshi Guha <rg...@in...> wrote: >> On Jan 18, 2008, at 8:19 AM, Egon Willighagen wrote: >> I'm not sure I understand this. Why wouldn't the atomic number >> available given a symbol? I thought that pseudo atoms were defined to >> have atomic number 0 > > I think only because we do/did not have NULL for that field yet? Hmm. Well I think going the IElement route is a good idea. So IAtom.getSymbol() would access the symbol via the IElement field (for normal atoms). How would it work for pseudo atoms? And IAtom.getAtomicNumber() would do it via the IElement as well? ANd a pseudo atom could just return 0 ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- ...but there was no one in it....... - RG |
From: Egon W. <ego...@gm...> - 2008-01-18 13:42:54
|
On Jan 18, 2008 2:36 PM, Rajarshi Guha <rg...@in...> wrote: > Hmm. Well I think going the IElement route is a good idea. So > IAtom.getSymbol() would access the symbol via the IElement field (for > normal atoms). How would it work for pseudo atoms? > > And IAtom.getAtomicNumber() would do it via the IElement as well? ANd > a pseudo atom could just return 0 This is the current behavior, I think... I guess you mean that we add a stub in the new IAtom with an IElement as field? Haven't though about that yet... IPseudoAtom should indeed *not* have an IElement field... And therefore not have atomic number and symbol fields... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 14:13:32
|
On Jan 18, 2008, at 8:42 AM, Egon Willighagen wrote: > On Jan 18, 2008 2:36 PM, Rajarshi Guha <rg...@in...> wrote: >> Hmm. Well I think going the IElement route is a good idea. So >> IAtom.getSymbol() would access the symbol via the IElement field (for >> normal atoms). How would it work for pseudo atoms? >> >> And IAtom.getAtomicNumber() would do it via the IElement as well? ANd >> a pseudo atom could just return 0 > > This is the current behavior, I think... > > I guess you mean that we add a stub in the new IAtom with an > IElement as field? OK, so I finally looked at the sources (as I should have done in the beginning!). If IAtom is a child of IElement, why should it have a field for an IElement? Also, I'm wondering whether there is any need for the getLabel/ setLabel methods in IPseudoAtom? Wouldn't it be better to remove them, so that the ysmbol is accessed by getSymbol() just like for any other atom? But getAtomicNumber would be overridden to return a hard coded 0? The advantage is that one does not need to inspect the class via instanceof to detect a pseudo atom (though one could do it if required). Instead one can simply check te aotmic number. Of course this assumes, that for all real atoms, the atomic number is set properly ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- There is no truth to the allegation that statisticians are mean. They are just your standard normal deviates. |
From: Egon W. <ego...@gm...> - 2008-01-18 14:26:07
|
On Jan 18, 2008 3:13 PM, Rajarshi Guha <rg...@in...> wrote: > On Jan 18, 2008, at 8:42 AM, Egon Willighagen wrote: > OK, so I finally looked at the sources (as I should have done in the > beginning!). Yeah, we're still not used to things being open source :) Our younger generation of chemoinformaticians have all been trained as alchemists using black cauldrons. > If IAtom is a child of IElement, why should it have a field for an > IElement? Right. That's the API change I have been thinking about: no longer extending IAtom from IElement, but having IElement as field :) > Also, I'm wondering whether there is any need for the getLabel/ > setLabel methods in IPseudoAtom? Semantics. > Wouldn't it be better to remove them, so that the ysmbol is accessed > by getSymbol() just like for any other atom? But getAtomicNumber > would be overridden to return a hard coded 0? Well, NULL preferably then... I'd rather even see IPseudoAtom *not* having getAtomicNumber()... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 16:49:27
|
On Jan 18, 2008, at 9:26 AM, Egon Willighagen wrote: > On Jan 18, 2008 3:13 PM, Rajarshi Guha <rg...@in...> wrote: >> On Jan 18, 2008, at 8:42 AM, Egon Willighagen wrote: >> OK, so I finally looked at the sources (as I should have done in the >> beginning!). > > Yeah, we're still not used to things being open source :) Our younger > generation of chemoinformaticians have all been trained as alchemists > using black cauldrons. Laziness also plays a role :) >> If IAtom is a child of IElement, why should it have a field for an >> IElement? > > Right. That's the API change I have been thinking about: no longer > extending IAtom from IElement, but having IElement as field :) Aah, yes. I think this is a good idea, since conceptually an atom is an instance of an element, rather than a 'type' of element >> Also, I'm wondering whether there is any need for the getLabel/ >> setLabel methods in IPseudoAtom? > > Semantics. I think it'd be more consistent to make IPseudoAtom as close to IAtom as possible >> Wouldn't it be better to remove them, so that the ysmbol is accessed >> by getSymbol() just like for any other atom? But getAtomicNumber >> would be overridden to return a hard coded 0? > > Well, NULL preferably then... I'd rather even see IPseudoAtom *not* > having getAtomicNumber()... Makes sense ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Despite the high cost of living, it remains popular. |
From: Daniel Z. <zah...@dt...> - 2008-01-18 14:47:46
|
On Jan 18, 2008, at 9:13 AM, Rajarshi Guha wrote: > > On Jan 18, 2008, at 8:42 AM, Egon Willighagen wrote: > >> On Jan 18, 2008 2:36 PM, Rajarshi Guha <rg...@in...> wrote: >>> Hmm. Well I think going the IElement route is a good idea. So >>> IAtom.getSymbol() would access the symbol via the IElement field >>> (for >>> normal atoms). How would it work for pseudo atoms? >>> >>> And IAtom.getAtomicNumber() would do it via the IElement as well? >>> ANd >>> a pseudo atom could just return 0 >> >> This is the current behavior, I think... >> >> I guess you mean that we add a stub in the new IAtom with an >> IElement as field? > > OK, so I finally looked at the sources (as I should have done in the > beginning!). > > If IAtom is a child of IElement, why should it have a field for an > IElement? > > Also, I'm wondering whether there is any need for the getLabel/ > setLabel methods in IPseudoAtom? > Wouldn't it be better to remove them, so that the ysmbol is accessed > by getSymbol() just like for any other atom? But getAtomicNumber > would be overridden to return a hard coded 0? The advantage is that > one does not need to inspect the class via instanceof to detect a > pseudo atom (though one could do it if required). Instead one can > simply check te aotmic number. Of course this assumes, that for all > real atoms, the atomic number is set properly > I don't know the code details here, but this is related to something I've wanted to get to for a while. We have a lot of molfiles that come out of our system with various text labels. In essence, the structure file is really a display file. Obviously a lot of the uses of this are really bad practice, but 1) that's what we have and 2) there are a lot of very interesting uses for display only elements on a structure. Generally display programs will display what returns from getSymbol() (or equivalent), so usually the files we have now will end up with some 'R's scattered about the display. I certainly wouldn't mind having the label stored as the symbol as then this could be fixed with no change in all the display codes, but I don't know what the larger consequences are of having substantial strings in the symbol field. Then there is still the problem of identifying it as a non-element. Having getAtomicNumber( return 0 (or null) would work, but are there multiple ways of being a non-element that we would have to distinguish? DanZ /******************************************** Daniel Zaharevitz Chief, Information Technology Branch National Cancer Institute zah...@dt... ********************************************/ |
From: Rajarshi G. <rg...@in...> - 2008-01-18 16:57:49
|
On Jan 18, 2008, at 9:47 AM, Daniel Zaharevitz wrote: > > On Jan 18, 2008, at 9:13 AM, Rajarshi Guha wrote: > > I don't know the code details here, but this is related to > something I've wanted to get to for a while. We have a lot of > molfiles that come out of our system with various text labels. In > essence, the structure file is really a display file. Obviously a > lot of the uses of this are really bad practice, but 1) that's what > we have and 2) there are a lot of very interesting uses for display > only elements on a structure. Generally display programs will > display what returns from getSymbol() (or equivalent), so usually > the files we have now will end up with some 'R's scattered about > the display. I certainly wouldn't mind having the label stored as > the symbol as then this could be fixed with no change in all the > display codes, but I don't know what the larger consequences are > of having substantial strings in the symbol field. I think this is a good reason to make pseudo atoms more similar to atoms > Then there is still the problem of identifying it as a non-element. > Having getAtomicNumber( return 0 (or null) would work, but are > there multiple ways of being a non-element that we would have to > distinguish? A very good point - I'm definitely in favor of the Python philosophy, i.e., 'One Good Way' (as opposed to the Perl philosophy, TMTOWTDI). I think if getAtomicNumber() returned NULL, that would be a suitable identifier for pseudo atoms. Of course, checking the type of the object would also be one way (but I think checking for NULL is more efficient than instanceof). I should point out that I think IPseudoAtom should remain - only that we drop the get/setLabel() and override getAtomicNumber() to hard code a NULL return value ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Q: What do you get when you cross a mosquito with a mountain climber? A: Nothing. You can't cross a vector with a scaler. |