Otis, it will take some getting used to and some careful documentation, but I think you will find this SMILES/SMARTS "find" business extraordinarily useful. It is a bit tricky.
On Mon, Aug 9, 2010 at 9:35 AM, Otis Rothenberger <[email protected]>wrote: > 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? > > I assume we are talking about "xxx".find("SMILES","yyy") here: > 1) If no stereo information is involved in either SMILES, it does not > matter. > right > 2) If both have stereo information, it does not matter??? > right > 3) If one SMILES has stereo information and one does not, then the > stereo SMILES is the one to search??? > if "xxx" has stereochemistry and "yyy" does not, then stereochemistry is ignored if "yyy" has stereochemistry and "xxx" does not, then the match will fail The idea is that when you "find" yyy "in" xxx if you have specified stereochemistry in yyy, then it better be there in xxx because you are explicitly looking for it; if you have not specified stereochemistry in "yyy", then it doesn't matter what stereochemistry is indicated in xxx, because -- apparently -- you don't care. The return from that will be as it was documented -- > 0 for a find, 0 for no find, and -1 for error. The array return business is now with "SMARTS" only. In that case, an error just returns "?" > 4) In "XXXXX".find("SMILES","YYYYY"), "XXXXX" is being searched for > "YYYYY." > > right. Just like in "XXXXX".find("YYYY") the string "XXXXX" is being searched for "YYYY". > 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? > > Wednesday > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
