Bob,
I noticed that the return was either an array of all of the atomIndexes
or null. The Boolean return for the statement was "on" or "off."
I picked up on the fact that the find was not associative from your
original discussion of the Jmol SMILES applet. I have to admit that I've
been approaching this issue by trial and error. I have difficulty
understanding who is to be searched by whom! Your specific example below
may be putting me on the correct path on this issue. Am I on the right
track with the following four search order assumptions?
1) If no stereo information is involved in either SMILES, it does not
matter.
2) If both have stereo information, it does not matter???
3) If one SMILES has stereo information and one does not, then the
stereo SMILES is the one to search???
4) In "XXXXX".find("SMILES","YYYYY"), "XXXXX" is being searched for "YYYYY."
I'm assuming above that my intent is an identity check. I'm also
assuming that 3 would return a match, but with stereo ambiguity.
Ahh, didn't your vacation start yesterday?
Best, Otis
Otis Rothenberger
chemagic.com
On 8/9/2010 1:01 AM, Robert Hanson wrote:
> SMILES generation is broken in 12.0. Let's take a look at this again
> after I fix that.
>
> Note that find is not associative:
>
> "c...@h](Cl)F".find("SMILES","CC(Cl)F")
>
> and
>
> "CC(Cl)F".find("SMILES","c...@h](Cl)F")
>
> are not the same. In the first case, the result is TRUE; in the second
> case it is FALSE.
>
> Also, I have just changed the output from that function. It now
> returns an array of integers indicating which atoms of the initial
> string were part of the match
> et/lists/listinfo/jmol-users
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
