[Issue 8476] float comparison operand not truncated from real
https://issues.dlang.org/show_bug.cgi?id=8476 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #10 from Vladimir Panteleev thecybersha...@gmail.com 2013-05-28 10:05:10 EEST --- *** Issue 10187 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #9 from Maxim Fomin ma...@maxim-fomin.ru 2012-10-16 09:18:02 PDT --- Regardless of whether (when comparing floats with reals) compiler should compare with full or truncated to smaller type precision, current behavior seems to be inconsistent with spec. According to the spec in section Equality Expressions floating point types are compared bitwise. This means that if two floats are compared, compiler need not care about extra precision but currently it compares 32 bit with 80 bit (issue is better revealed in 8745). But if this is feature and not a bug, spec should be changed and better explain the issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 --- Comment #6 from bearophile_h...@eml.cc 2012-07-31 02:12:51 PDT --- (In reply to comment #5) D made the decision early on that: more precision == better and that any program that relied on results being less accurate was a faulty program. You are right, of course, and such problems are common: http://www.parashift.com/c++-faq-lite/floating-point-arith2.html On the other hand I remember one of my D programs not being as efficient as a very similar C++ program just because the C++ code used float-based operations instead of double-based ones, despite me typing float every FP variable and tagging with f every floating point literal. In some cases std.math return a double even if all it's required is a float, and the useless computation of the extra precision slows down the code compared to the C++ code that uses functions that return only a float precision. I presume the float versions of some functions perform less iterations to compute the smaller number of precision digits, and this makes them faster. And in some way std.math was unable to let me use the faster float version. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-07-30 14:44:36 PDT --- I'm not sure what the issue is here. Can you point to what you think it should be doing? Also, the compiler is allowed to not truncate reals to floats when doing comparisons, even if it is typed as a float. This is a feature, not a bug. The compiler is always allowed to use a higher precision for intermediate calculations than the source is typed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 --- Comment #3 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-07-30 16:09:48 PDT --- (In reply to comment #1) I'm not sure what the issue is here. Can you point to what you think it should be doing? Also, the compiler is allowed to not truncate reals to floats when doing comparisons, even if it is typed as a float. This is a feature, not a bug. The compiler is always allowed to use a higher precision for intermediate calculations than the source is typed. my diagnosis is probably wrong, but writeln(fitness(z) fitness(z) ?,f f); writeln(fitness(z) fitness(z) ?,less(z,z)); are printing out different results when they should be printing the same thing. dmd 2.059, 32 bit only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-07-30 20:58:21 PDT --- f is of type float. z is of type chromosome. Where are they the same types? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8476] float comparison operand not truncated from real
http://d.puremagic.com/issues/show_bug.cgi?id=8476 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2012-07-30 21:00:54 PDT --- (In reply to comment #2) (In reply to comment #1) The compiler is always allowed to use a higher precision for intermediate calculations than the source is typed. A disadvantage of this is loss of floating point reproducibility across compilers, maybe similar to using the -ffast-math of GCC. D made the decision early on that: more precision == better and that any program that relied on results being less accurate was a faulty program. Use of float should be for: 1. speed 2. less memory consumption and *never* for reduced precision. float guarantees a *minimum* precision, not a maximum. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
