Re: [BlueObelisk-discuss] Cahn-Ingold-Prelog rules into Jmol

[Chalk, Stuart]

So, I have been following the conversation about implementing code to determine 
stereochemistry based on the CIP rules with great interest because, as a recent 
convert into the cheminformatics area, a few thoughts come to mind.

1) Has anyone taken the CIP rules and rewritten them as formal logic (and 
machine readable) rules?
2) Does anyone involved with the development of the current InChI specification 
have any comments to make about its implementation of the CIP rules and how 
that will need to change in the current InChI Trust project to do a better job 
with encoding stereo centers?
3) Has there been any discussion here or in IUPAC about revising the CIP rules?

I am not an expert in this area, so these may be very naive questions, but it 
seems to me that if the representation of chemical structure goes down a 
semantic path (and yes that would mean another molecular structure file format) 
now is the time to rethink these things in light of electronic representation 
(i.e. think about the computer needs before human needs).

Stuart

Stuart Chalk, Ph.D.
Associate Professor of Chemistry
Department of Chemistry, Building 50, Room 3514,
University of North Florida
1 UNF Drive, Jacksonville, FL 32224 USA
P: 904-620-1938
F: 904-620-3535
E: sch...@unf.edu
W: http://www.unf.edu/coas/chemistry/faculty/Stuart_Chalk.aspx

On Apr 10, 2017, at 8:50 AM, Robert Hanson 
> wrote:

OK. That's fine. Point me to the algorithm. I'll say no more.

On Mon, Apr 10, 2017 at 7:10 AM, Noel O'Boyle 
> wrote:
Sorry, but I have to call you out on this, especially as this is the
Blue Obelisk mailing list.

I've no problem anyone reimplementing anything for fun or profit, but
I have to disagree with the suggestion that having an N'th
implementation of the same algorithm is progress, or good for this
community. At a recent meeting at the EBI, I think there were at least
7 attendees who had written versions of this algorithm. The whole goal
of the Blue Obelisk is to pool our expertise to develop common
resources, to avoid exactly this situation.

- Noel

On 9 April 2017 at 23:53, Robert Hanson 
> wrote:
> "re" implementing is a great way to find additional bugs and compare
> strategies. This (to this point) took me two days. And if I started with a
> "libRS" in Java, I would still have to modify it extensively to fit Jmol.
> That said, I wouldn't mind taking a look at how other have implemented it.
>
> In the mean time, is it OK for me to continue this discussion without libRS?
>
> Q: What do you say for the stereochemistry of [13CH@@]12C3C1.C2=CC3  ?
>
>
>
>
> On Sun, Apr 9, 2017 at 1:53 PM, Noel O'Boyle 
> > wrote:
>>
>> We need libRS. Everyone reimplementing these rules is some type of
>> madness.
>>
>> On 9 Apr 2017 7:05 p.m., "Robert Hanson" 
>> > wrote:
>>>
>>> OK, I don't get the logic of this:
>>>
>>>
>>> Rule 1 (a) Higher atomic number precedes lower;
>>> (b) A duplicated atom, with its predecessor node having the same label
>>> closer
>>> to the root, ranks higher than a duplicated atom, with its predecessor
>>> node
>>> having the same label farther from the root, which ranks higher than any
>>> nonduplicated-atom-node (proposed by Custer, ref. 36)
>>>
>>> Rule 2 Higher atomic mass number precedes lower;
>>>
>>>
>>> Seriously? root distance is checked before isotope. Sure seems odd to me.
>>> Why would that distance check not be after atomic number and mass??
>>>
>>> Whatever...
>>>
>>> Bob
>>>
>>>
>>>
>>>
>>> On Sun, Apr 9, 2017 at 12:11 PM, Robert Hanson 
>>> >
>>> wrote:

 OK, so I am reading Chapter 9 now to see the gory details. I didn't know
 about the root-distance check, and so now


 1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-cyclopropylethyl)-pentan-3-yl]methan-1-ol.mol

 is working. So all of this is easy enough. That's probably it for
 independent stereochemistry.  Where there is a dependency  of one
 stereochemical determination from another -- R/S after E/Z; E/Z after R/S,
 E/Z after E/Z, R/S after R/S -- obviously that takes some sort of more
 general iteration.

 I think I will have to tackle that another day.

 Bob





 On Sun, Apr 9, 2017 at 11:03 AM, John Mayfield
 > wrote:
>
> Good good,
>
> Fake news before fake news - a paper published in the CCG journal by
> the CCG.
>
> John
>
> On 9 April 2017 at 16:51, Robert Hanson 
> > wrote:
>>
>> No, John. Don't worry.  I just happened to look at that page prior to
>> designing my own.
>>

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

OK. That's fine. Point me to the algorithm. I'll say no more.

On Mon, Apr 10, 2017 at 7:10 AM, Noel O'Boyle  wrote:

> Sorry, but I have to call you out on this, especially as this is the
> Blue Obelisk mailing list.
>
> I've no problem anyone reimplementing anything for fun or profit, but
> I have to disagree with the suggestion that having an N'th
> implementation of the same algorithm is progress, or good for this
> community. At a recent meeting at the EBI, I think there were at least
> 7 attendees who had written versions of this algorithm. The whole goal
> of the Blue Obelisk is to pool our expertise to develop common
> resources, to avoid exactly this situation.
>
> - Noel
>
> On 9 April 2017 at 23:53, Robert Hanson  wrote:
> > "re" implementing is a great way to find additional bugs and compare
> > strategies. This (to this point) took me two days. And if I started with
> a
> > "libRS" in Java, I would still have to modify it extensively to fit Jmol.
> > That said, I wouldn't mind taking a look at how other have implemented
> it.
> >
> > In the mean time, is it OK for me to continue this discussion without
> libRS?
> >
> > Q: What do you say for the stereochemistry of [13CH@@]12C3C1.C2=CC3  ?
> >
> >
> >
> >
> > On Sun, Apr 9, 2017 at 1:53 PM, Noel O'Boyle 
> wrote:
> >>
> >> We need libRS. Everyone reimplementing these rules is some type of
> >> madness.
> >>
> >> On 9 Apr 2017 7:05 p.m., "Robert Hanson"  wrote:
> >>>
> >>> OK, I don't get the logic of this:
> >>>
> >>>
> >>> Rule 1 (a) Higher atomic number precedes lower;
> >>> (b) A duplicated atom, with its predecessor node having the same label
> >>> closer
> >>> to the root, ranks higher than a duplicated atom, with its predecessor
> >>> node
> >>> having the same label farther from the root, which ranks higher than
> any
> >>> nonduplicated-atom-node (proposed by Custer, ref. 36)
> >>>
> >>> Rule 2 Higher atomic mass number precedes lower;
> >>>
> >>>
> >>> Seriously? root distance is checked before isotope. Sure seems odd to
> me.
> >>> Why would that distance check not be after atomic number and mass??
> >>>
> >>> Whatever...
> >>>
> >>> Bob
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Apr 9, 2017 at 12:11 PM, Robert Hanson 
> >>> wrote:
> 
>  OK, so I am reading Chapter 9 now to see the gory details. I didn't
> know
>  about the root-distance check, and so now
> 
> 
>  1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-
> cyclopropylethyl)-pentan-3-yl]methan-1-ol.mol
> 
>  is working. So all of this is easy enough. That's probably it for
>  independent stereochemistry.  Where there is a dependency  of one
>  stereochemical determination from another -- R/S after E/Z; E/Z after
> R/S,
>  E/Z after E/Z, R/S after R/S -- obviously that takes some sort of more
>  general iteration.
> 
>  I think I will have to tackle that another day.
> 
>  Bob
> 
> 
> 
> 
> 
>  On Sun, Apr 9, 2017 at 11:03 AM, John Mayfield
>   wrote:
> >
> > Good good,
> >
> > Fake news before fake news - a paper published in the CCG journal by
> > the CCG.
> >
> > John
> >
> > On 9 April 2017 at 16:51, Robert Hanson  wrote:
> >>
> >> No, John. Don't worry.  I just happened to look at that page prior
> to
> >> designing my own.
> >>
> >> On Sun, Apr 9, 2017 at 10:44 AM, John Mayfield
> >>  wrote:
> >>>
> >>> Hi Bob,
> >>>
> >>> On 9 April 2017 at 13:42, Robert Hanson 
> wrote:
> 
>  [I actually do know it is Cahn; pulled "Cohen" without thinking
> from
>  https://www.chemcomp.com/journal/chiral.htm. Serves me right.
> Duh!]
> >>>
> >>>
> >>> Was that the algorithm you implemented because it's not correct -
> it
> >>> doesn't (and can't) handle ghost atoms. Trying to track down the
> example but
> >>> Daniel Lowe constructed a small reproducible example to
> demonstrate why this
> >>> can never work.
> >>>
> >>> John
> >>>
> >>>
> >>>
> >>> 
> --
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>> ___
> >>> Blueobelisk-discuss mailing list
> >>> Blueobelisk-discuss@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
> >>>
> >>
> >>
> >>
> >> --
> >> Robert M. Hanson
> >> Larson-Anderson Professor of Chemistry
> >> St. Olaf College
> >> Northfield, MN
> >> http://www.stolaf.edu/people/hansonr
> >>
> >>
> >> If nature does 

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[John Mayfield]

Noel pointed out I only sent this back to Bob.

On 10 April 2017 at 08:40, John Mayfield 
wrote:

> On 9 April 2017 at 23:53, Robert Hanson  wrote:
>
>> [13CH@@]12C3C1.C2=CC3
>
>
> Well if you make it valid (Open) SMILES:
>
> [13C@@H]12C3C1.C2=CC3
>
> Also why so many dots, that's considered "not good form" in SMILES
>
> C1C2CC=C[13C@@H]12
>
> Anyways, it should be S. A simpler example is:
>
> CC[C@](CO)([H])[14CH2]C R
> CC[C@@](CO)([H])[14CH2]C S
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss