From: Alberto M. <alb...@un...> - 2012-11-24 08:07:08
|
Dear all, I encountered a strange Exception while using classes for generation of SMILES. For a couple of molecules, I get a "Comparison method violates its general contract!" message and I really can understand the meaning! I'm actually working with CDK 1.4.9, following a slice of code where such Exception is raised: String s_in = "CC(C)(C)C1=CC(=C(OP2OCC3(COP(OC4=CC=C(C=C4C(C)(C)C)C(C)(C)C)OC3)CO2)C=C1)C(C)(C)C"; SmilesParser sp = new SmilesParser(DefaultChemObjectBuilder.getInstance()); IMolecule m = sp.parseSmiles(s_in); SmilesGenerator sg = new SmilesGenerator(); String s_out = sg.createSMILES(m); System.out.println(s_out); The molecule itself is correctly parsed from the SMILES, and anyway it doesn't seem a "strange" or complex molecule... but then when I try to generate again the SMILES from the molecule, I get that Exception. Does anyone know what's wrong? I make some mistakes or is it a weird behaviour of the SMILES generator? Thanks in advance for the help! Regards Alberto -- Alberto Manganaro Milano Chemometrics and QSAR Research Group Department of Environmental Sciences University of Milano-Bicocca P.zza della Scienza, 1 20126 Milano - Italy http://michem.disat.unimib.it/chm/ |
From: Nina J. <jel...@gm...> - 2012-11-24 08:41:55
|
Dear Alberto, All On 24 November 2012 10:06, Alberto Manganaro <alb...@un...>wrote: > Dear all, > > I encountered a strange Exception while using classes for generation of > SMILES. For a couple of molecules, I get a "Comparison method violates > its general contract!" message and I really can understand the meaning! > > I'm actually working with CDK 1.4.9, following a slice of code where > such Exception is raised: > > String s_in = > > "CC(C)(C)C1=CC(=C(OP2OCC3(COP(OC4=CC=C(C=C4C(C)(C)C)C(C)(C)C)OC3)CO2)C=C1)C(C)(C)C"; > SmilesParser sp = new SmilesParser(DefaultChemObjectBuilder.getInstance()); > IMolecule m = sp.parseSmiles(s_in); > SmilesGenerator sg = new SmilesGenerator(); > String s_out = sg.createSMILES(m); > System.out.println(s_out); > > The molecule itself is correctly parsed from the SMILES, and anyway it > doesn't seem a "strange" or complex molecule... but then when I try to > generate again the SMILES from the molecule, I get that Exception. > > Does anyone know what's wrong? I make some mistakes or is it a weird > behaviour of the SMILES generator? Thanks in advance for the help! Regards > I did a quick test with https://github.com/ideaconsult/examples-cdk/tree/master/maven-single-module, where CDK versions could be changed by maven profile. It works fine, no exceptions (you could get the code and run it with , e.g. mvn clean install -P cdk-1.4.9 ) ------------------------------------------------------- T E S T S ------------------------------------------------------- Running net.idea.examples.cdk.maven_single_module.SmilesTest O(C=1C=CC(=CC=1C(C)(C)C)C(C)(C)C)P2OCC4(CO2)(COP(OC3=CC=C(C=C3C(C)(C)C)C(C)(C)C)OC4) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.706 sec Otherwise, the error means a comparator is not transitive (Google search is usually exceptionally precise when searching for error messages ;) https://www.google.com/search?q=Comparison+method+violates+its+general+contract Which exactly comparator is hard to say without reproducing the error. But it is likely due to error in a specific JDK version - which one do you use? (I've tested with JDK 1.6_037) http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#source *Area:* API: Utilities *Synopsis:* Updated sort behavior for Arrays and Collections may throw an IllegalArgumentException *Description:* The sorting algorithm used by java.util.Arrays.sort and (indirectly) byjava.util.Collections.sort has been replaced. The new sort implementation may throw anIllegalArgumentException if it detects a Comparable that violates the Comparable contract. The previous implementation silently ignored such a situation. If the previous behavior is desired, you can use the new system property, java.util.Arrays.useLegacyMergeSort, to restore previous mergesort behavior. *Nature of Incompatibility:* behavioral *RFE:* 6804124 <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6804124> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6804124 I am copying the cdk-devel list, as this seems to be change in the behaviour in JDK 1.7 for a pretty core JDK functionality , and it could affect lot more code than SMILES processing ... Regards, Nina > Alberto > > -- > Alberto Manganaro > > Milano Chemometrics and QSAR Research Group > Department of Environmental Sciences > University of Milano-Bicocca P.zza della Scienza, 1 > 20126 Milano - Italy > > http://michem.disat.unimib.it/chm/ > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Cdk-user mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-user > |
From: Alberto M. <alb...@un...> - 2012-11-24 17:43:38
|
Dear Nina, sorry I did not answer to your question: > But it is likely due to error in a specific JDK version - which one do you > use? (I've tested with JDK 1.6_037) > > ... > > I am copying the cdk-devel list, as this seems to be change in the > behaviour in JDK 1.7 for a pretty core JDK functionality , and it could > affect lot more code than SMILES processing ... I'm working with version 1.7.0, now I'm going to do some tests... maybe I will write again if I find something interesting to share. Thanks again for your help, regards A. -- Alberto Manganaro Milano Chemometrics and QSAR Research Group Department of Environmental Sciences University of Milano-Bicocca P.zza della Scienza, 1 20126 Milano - Italy http://michem.disat.unimib.it/chm/ |
From: John M. <jo...@eb...> - 2012-11-24 12:18:07
|
Hi Nina, You're exactly right on the error. Stephan mentioned this the other day but we thought it might just have been if you mix the byte codes (i.e. compile with JDK 6 and run with JDK 7). Luckily I found the error straight away. A comparison violation is as follows if a < b and b < c then a must be less then c. If a is not less then c you haven't written the comparison method incorrectly. Having a quick look at the stack trace it's possible to find the bug in the canonical labeller. Hint: what happens if the first values is negative… :) 1 2 3 4 5 6 7 8 9 10 11 12 private void sortArrayList(ArrayList v) { Collections.sort(v, new Comparator() { public int compare(Object o1, Object o2) { return (int) (((InvPair) o1).getCurr() - ((InvPair) o2).getCurr()); } }); Collections.sort(v, new Comparator() { public int compare(Object o1, Object o2) { return (int) (((InvPair) o1).getLast() - ((InvPair) o2).getLast()); } }); } https://gist.github.com/4139439 John May | Predoctoral Student – Chemoinformatics and Metabolism European Bioinformatics Institute, Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK jo...@eb... | +44–(0) 1223 49 2603 On 24 Nov 2012, at 08:41, Nina Jeliazkova <jel...@gm...> wrote: > Dear Alberto, All > > On 24 November 2012 10:06, Alberto Manganaro <alb...@un...> wrote: > Dear all, > > I encountered a strange Exception while using classes for generation of > SMILES. For a couple of molecules, I get a "Comparison method violates > its general contract!" message and I really can understand the meaning! > > I'm actually working with CDK 1.4.9, following a slice of code where > such Exception is raised: > > String s_in = > "CC(C)(C)C1=CC(=C(OP2OCC3(COP(OC4=CC=C(C=C4C(C)(C)C)C(C)(C)C)OC3)CO2)C=C1)C(C)(C)C"; > SmilesParser sp = new SmilesParser(DefaultChemObjectBuilder.getInstance()); > IMolecule m = sp.parseSmiles(s_in); > SmilesGenerator sg = new SmilesGenerator(); > String s_out = sg.createSMILES(m); > System.out.println(s_out); > > The molecule itself is correctly parsed from the SMILES, and anyway it > doesn't seem a "strange" or complex molecule... but then when I try to > generate again the SMILES from the molecule, I get that Exception. > > Does anyone know what's wrong? I make some mistakes or is it a weird > behaviour of the SMILES generator? Thanks in advance for the help! Regards > > I did a quick test with https://github.com/ideaconsult/examples-cdk/tree/master/maven-single-module , where CDK versions could be changed by maven profile. It works fine, no exceptions (you could get the code and run it with , e.g. mvn clean install -P cdk-1.4.9 ) > > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running net.idea.examples.cdk.maven_single_module.SmilesTest > O(C=1C=CC(=CC=1C(C)(C)C)C(C)(C)C)P2OCC4(CO2)(COP(OC3=CC=C(C=C3C(C)(C)C)C(C)(C)C)OC4) > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.706 sec > > Otherwise, the error means a comparator is not transitive (Google search is usually exceptionally precise when searching for error messages ;) https://www.google.com/search?q=Comparison+method+violates+its+general+contract > > Which exactly comparator is hard to say without reproducing the error. > > But it is likely due to error in a specific JDK version - which one do you use? (I've tested with JDK 1.6_037) > > http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#source > Area: API: Utilities > Synopsis: Updated sort behavior for Arrays and Collections may throw anIllegalArgumentException > Description: The sorting algorithm used by java.util.Arrays.sort and (indirectly) byjava.util.Collections.sort has been replaced. The new sort implementation may throw anIllegalArgumentException if it detects a Comparable that violates the Comparable contract. The previous implementation silently ignored such a situation. > If the previous behavior is desired, you can use the new system property,java.util.Arrays.useLegacyMergeSort, to restore previous mergesort behavior. > Nature of Incompatibility: behavioral > RFE: 6804124 > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6804124 > > I am copying the cdk-devel list, as this seems to be change in the behaviour in JDK 1.7 for a pretty core JDK functionality , and it could affect lot more code than SMILES processing ... > > Regards, > Nina > > > > Alberto > > -- > Alberto Manganaro > > Milano Chemometrics and QSAR Research Group > Department of Environmental Sciences > University of Milano-Bicocca P.zza della Scienza, 1 > 20126 Milano - Italy > > http://michem.disat.unimib.it/chm/ > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Cdk-user mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-user > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________ > Cdk-user mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-user |
From: John M. <jo...@eb...> - 2012-11-24 12:28:01
|
Sorry that should have read: "If a is not less then c you haven't written the comparison method correctly" Either way I've changed it and it now works as expected. Will create the patch straight away. Many thanks, J |
From: Alberto M. <alb...@un...> - 2012-11-24 17:13:56
|
Dear Nina and dear John, thanks for your clear explanation, now the problem is clear to me. Regards A. -- Alberto Manganaro Milano Chemometrics and QSAR Research Group Department of Environmental Sciences University of Milano-Bicocca P.zza della Scienza, 1 20126 Milano - Italy http://michem.disat.unimib.it/chm/ |
From: Alberto M. <alb...@un...> - 2012-11-25 08:57:19
|
Dear all, I'd just like to report you the test I made. As I said, I'm working with JDK 1.7 and with CDK 1.4.9, I'm using the donwnloaded jar (looking inside it, it seems that the bytecode has been done with target JDK 1.5). To make a quick test, I put inside my project the classes SmilesGenerator and CanonicalLabeler (taken form the original source of 1.4.9), so everything I made was with target JDK 1.7 (but I think that's not relevant). Then, in the CanonicalLabeler, I just tried to surround with try-catch the call that produced the Exception, sortArrayList(v) in the method step3(ArrayList v, IAtomContainer atoms). I didn't put any code in the catch, so actually I just ignored the Exception, but as far as I understand this was what happenened when running on JDK versions prior to 1.7. I tested my code on several thousands of molecule, and actually it worked fine: I generated the correct SMILES, and I've finally been able to produce the SMILES for a couple of compounds for which the Exception was raised. I didn't try to check the code for CanonicalLabeler so actually I have no idea of what I'm ignoring by putting that try-catch, but I guess that anyway I'm obtaining the same behaviour of the code for previous JDK versions. Anyway this means that there is something wrong in the CanonicalLabeler, but that before it was just ignored, right? Thanks again for your help, regards A. -- Alberto Manganaro Milano Chemometrics and QSAR Research Group Department of Environmental Sciences University of Milano-Bicocca P.zza della Scienza, 1 20126 Milano - Italy http://michem.disat.unimib.it/chm/ |
From: Nina J. <jel...@gm...> - 2012-11-25 09:34:19
|
Dear Alberto, On 25 November 2012 10:57, Alberto Manganaro <alb...@un...>wrote: > Dear all, > > I'd just like to report you the test I made. > > As I said, I'm working with JDK 1.7 and with CDK 1.4.9, I'm using the > donwnloaded jar (looking inside it, it seems that the bytecode has been > done with target JDK 1.5). > To make a quick test, I put inside my project the classes > SmilesGenerator and CanonicalLabeler (taken form the original source of > 1.4.9), so everything I made was with target JDK 1.7 (but I think that's > not relevant). > > Indeed, this is not relevant. Yes, AFAIK the CDK releases are compiled with 1.5 (Egon, am I right?) , but what matters is the JVM version used to execute the code (that's it, 1.7) > Then, in the CanonicalLabeler, I just tried to surround with try-catch > the call that produced the Exception, sortArrayList(v) in the method > step3(ArrayList v, IAtomContainer atoms). I didn't put any code in the > catch, so actually I just ignored the Exception, but as far as I > understand this was what happenened when running on JDK versions prior > Not exactly. The are no exceptions under JDK < 1.7 . The sort() procedure was changed in JDK 1.7 and apparently it requires more rigorous implementation of comparators, and apparently Oracle decided to change the default behaviour to throw exceptions if comparators are not transitive. Such a change is a very unusual ! > to 1.7. I tested my code on several thousands of molecule, and actually > it worked fine: I generated the correct SMILES, and I've finally been > able to produce the SMILES for a couple of compounds for which the > Exception was raised. > > I didn't try to check the code for CanonicalLabeler so actually I have > no idea of what I'm ignoring by putting that try-catch, but I guess that > anyway I'm obtaining the same behaviour of the code for previous JDK > versions. Anyway this means that there is something wrong in the > CanonicalLabeler, but that before it was just ignored, right? > > See above. There are no exceptions in versions prior to JDK 1.7 , the code was executing fine, so if you comment the code it is not exactly the same. The change in behaviour is due to JDK 7 replacement of the sort() procedure and a subtle error in the implementation of a comparator inside CanonicalLabeler, which John fixed yesterday (thanks!) Your options are: 1) Use JDK older than 1.7 , there will be no errors at all 2) Use JDK 1.7 and the very latest patched CDK code, which includes John's fix. 3) Use JDK 1.7 and set Java system property java.util.Arrays. useLegacyMergeSort "If the previous behavior is desired, you can use the new system property, java.util.Arrays.useLegacyMergeSort, to restore previous mergesort behavior." My guess is the error in the Canonical labeler comparator affects only the canonical order of atoms, it will generate valid SMILES, but probably not canonical. Which is consistent with my observation the canonical SMILES in CDK were never canonical :) May be as a side effect this had been fixed as well! Best regards, Nina > Thanks again for your help, regards > > A. > > -- > Alberto Manganaro > > Milano Chemometrics and QSAR Research Group > Department of Environmental Sciences > University of Milano-Bicocca P.zza della Scienza, 1 > 20126 Milano - Italy > > http://michem.disat.unimib.it/chm/ > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Cdk-user mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-user > |