Comments on: Floating point errors http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/ Addressing the challenges of computational drug discovery Fri, 03 Sep 2010 19:30:16 +0000 http://wordpress.org/?v=2.0.11 by: zsolt http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1509 Fri, 05 Sep 2008 17:53:24 +0000 http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1509 Trevor, No, unfortunately, you are wrong for 2 reasons: 1. First of all what you say is not true: differences like 4.200000 versus 4.199999 will happen in the same form for doubles, the only "advantage" is that you have a longer list of 9 digits for doubles, but the first difference still occurs at the first decimal place. 2. OK, I know that is not what you meant. You mean, that the difference is smaller, so if I subtract the two results than I get 0 for at least 6 decimal places. However, that does not "solve" the problem either. The problem is not how accurate the value is, but whether or not a fundamental algebraic identity is broken. ANY difference, however small in a+b+c!=c+a+b can lead to horrible consequences. For example, if you are sorting partial solutions and want to keep the "best 100" for further processing, then you selection set will be different depending on what order you added up numbers during calculations. Same problem if you use any kind of threshold decisions, e.g. "solutions under a given energy limit are accepted" -- again you get different solution sets that may even be radically different in terms of conformation -- once you drop a solution it is simply not present and there is no guarantee that you have another similar solution that made it through the threshold condition. ZZ Trevor,

No, unfortunately, you are wrong for 2 reasons:

1. First of all what you say is not true: differences like 4.200000 versus 4.199999 will happen in the same form for doubles, the only “advantage” is that you have a longer list of 9 digits for doubles, but the first difference still occurs at the first decimal place.

2. OK, I know that is not what you meant. You mean, that the difference is smaller, so if I subtract the two results than I get 0 for at least 6 decimal places. However, that does not “solve” the problem either. The problem is not how accurate the value is, but whether or not a fundamental algebraic identity is broken. ANY difference, however small in a+b+c!=c+a+b can lead to horrible consequences. For example, if you are sorting partial solutions and want to keep the “best 100″ for further processing, then you selection set will be different depending on what order you added up numbers during calculations. Same problem if you use any kind of threshold decisions, e.g. “solutions under a given energy limit are accepted” — again you get different solution sets that may even be radically different in terms of conformation — once you drop a solution it is simply not present and there is no guarantee that you have another similar solution that made it through the threshold condition.

ZZ

]]> by: Trevor http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1508 Fri, 05 Sep 2008 17:27:19 +0000 http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1508 "This problem cannot be solved by using double precision" Actually, it can. If you change the floats to doubles, the sums will be identical for at least the first 6 or so decimal places. “This problem cannot be solved by using double precision”

Actually, it can. If you change the floats to doubles, the sums will be identical for at least the first 6 or so decimal places.

]]> by: Unilever Centre for Molecular Informatics, Cambridge - petermr’s blog » Blog Archive » Quality is emerging in chemical software http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1486 Wed, 04 Jun 2008 08:30:45 +0000 http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1486 [...] PMR: ZZ addresses this below in reporting a competition and I’ll continue there Are the docking and QSAR study results reproducible ? With eHiTS and LASSO, the answer is definitely YES! I understand that many tools on the docking/QSAR market use stochastic (read random) methods and therefore their results are inherently unreproducible. Again, I can only speak with authority about our own software, which uses strictly deterministic and reproducible techniques. So if a different researcher in a different location runs our software on the same input they will get the same result. However, I do not see how one could run the “same calculation” using a different software. By definition, if you are using a different software (which embodies the calculation) then you are not running the same calculation. I can assure you the same is true for QM software as well, for the simple floating point error reasons I have explained in a previous blog post. So any different QM implementation will necessarily involve computation steps in different orders (as simple as summation in different order will suffice) and therefore get slightly different results. [...] […] PMR: ZZ addresses this below in reporting a competition and I’ll continue there Are the docking and QSAR study results reproducible ? With eHiTS and LASSO, the answer is definitely YES! I understand that many tools on the docking/QSAR market use stochastic (read random) methods and therefore their results are inherently unreproducible. Again, I can only speak with authority about our own software, which uses strictly deterministic and reproducible techniques. So if a different researcher in a different location runs our software on the same input they will get the same result. However, I do not see how one could run the “same calculation” using a different software. By definition, if you are using a different software (which embodies the calculation) then you are not running the same calculation. I can assure you the same is true for QM software as well, for the simple floating point error reasons I have explained in a previous blog post. So any different QM implementation will necessarily involve computation steps in different orders (as simple as summation in different order will suffice) and therefore get slightly different results. […]

]]> by: SimBioSys Blog » Blog Archive » Quality in chemical software - the debate continues http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1483 Tue, 03 Jun 2008 22:44:54 +0000 http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1483 [...] Are the docking and QSAR study results reproducible ? With eHiTS and LASSO, the answer is definitely YES! I understand that many tools on the docking/QSAR market use stochastic (read random) methods and therefore their results are inherently unreproducible. Again, I can only speak with authority about our own software, which uses strictly deterministic and reproducible techniques. So if a different researcher in a different location runs our software on the same input they will get the same result. However, I do not see how one could run the “same calculation” using a different software. By definition, if you are using a different software (which embodies the calculation) then you are not running the same calculation. I can assure you the same is true for QM software as well, for the simple floating point error reasons I have explained in a previous blog post. So any different QM implementation will necessarily involve computation steps in different orders (as simple as summation in different order will suffice) and therefore get slightly different results. PMR: [...] […] Are the docking and QSAR study results reproducible ? With eHiTS and LASSO, the answer is definitely YES! I understand that many tools on the docking/QSAR market use stochastic (read random) methods and therefore their results are inherently unreproducible. Again, I can only speak with authority about our own software, which uses strictly deterministic and reproducible techniques. So if a different researcher in a different location runs our software on the same input they will get the same result. However, I do not see how one could run the “same calculation” using a different software. By definition, if you are using a different software (which embodies the calculation) then you are not running the same calculation. I can assure you the same is true for QM software as well, for the simple floating point error reasons I have explained in a previous blog post. So any different QM implementation will necessarily involve computation steps in different orders (as simple as summation in different order will suffice) and therefore get slightly different results. PMR: […]

]]> by: ChemSpiderMan http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1479 Thu, 29 May 2008 00:31:56 +0000 http://www.simbiosys.com/blog/2008/05/28/floating-point-errors/#comment-1479 Thanks for the education! ANd keep this type of post coming. It's likely educational for the majority of the people in the domain who don't understand the specifics. Thanks for the education! ANd keep this type of post coming. It’s likely educational for the majority of the people in the domain who don’t understand the specifics.

]]>