digitalmars.D.bugs - [Issue 8745] New: floating point comparison ("is" vs "==") inconsistency (on 32)
- d-bugmail puremagic.com (71/71) Oct 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8745
- d-bugmail puremagic.com (12/12) Oct 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8745
- d-bugmail puremagic.com (26/29) Oct 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8745
- d-bugmail puremagic.com (17/17) Oct 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8745
- d-bugmail puremagic.com (12/12) Oct 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=8745
http://d.puremagic.com/issues/show_bug.cgi?id=8745 Summary: floating point comparison ("is" vs "==") inconsistency (on 32) Product: D Version: unspecified Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: monarchdodra gmail.com --- Comment #0 from monarchdodra gmail.com 2012-10-01 14:21:50 PDT --- From http://forum.dlang.org/group/digitalmars.D.learn //---- import std.stdio; import std.math; property double getFloat() { return sqrt(1.1); } void main() { writeln(getFloat() == getFloat()); writeln(getFloat() is getFloat()); } //---- x32 Produces http://dpaste.dzfl.pl/e0e0bbae : false true x64 Produces http://dpaste.dzfl.pl/c1c7a415 : true true While one may argue that the comparison *may* return false, the difference in behavior between "==" and "is" not expected behavior (unless I'm missing something...? ). PS: the behavior difference is consistent http://dpaste.dzfl.pl/2ee9ae4e : //---- import std.stdio; import std.math; property double getFloat() { return sqrt(1.1); } void main() { writeln(getFloat() == getFloat()); writeln(getFloat() is getFloat()); writeln(getFloat() is getFloat()); writeln(getFloat() == getFloat()); writeln(getFloat() is getFloat()); writeln(getFloat() == getFloat()); writeln(getFloat() == getFloat()); writeln(getFloat() is getFloat()); } //---- false true true false true false false true //---- On a side note, I find it strange that "==" return false in such a consistent manner. It might be over-sensitive to extended precision? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8745 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au --- Comment #1 from Don <clugdbug yahoo.com.au> 2012-10-02 01:03:51 PDT --- The idea that for floating point, 'is' and '==' should be the same, is wrong. See bug 3632 for further discussion. I suspect this is a duplicate of the issues raised there. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8745 --- Comment #2 from monarchdodra gmail.com 2012-10-02 01:19:17 PDT --- (In reply to comment #1)The idea that for floating point, 'is' and '==' should be the same, is wrong. See bug 3632 for further discussion. I suspect this is a duplicate of the issues raised there.I read the thread, it mostly relates to how comparison is done in regards to NaN and 0. Here, we are dealing with a "normal" float. It mentions doing an "isIdentical" call if you really want binary comparison: //---- void main() { writeln(isIdentical(getFloat(), getFloat())); writeln(getFloat() is getFloat()); writeln(getFloat() == getFloat()); } //---- true true false //---- :/ So, to get this straight, I got a and b. "a is b" and "a is is identical to b" but "a != b" ? (!) Is that really the intended behavior? If so, can you explain what I am seeing? I'm more confused than trying to request a change of behavior, really. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8745 Rainer Schuetze <r.sagitario gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.sagitario gmx.de --- Comment #3 from Rainer Schuetze <r.sagitario gmx.de> 2012-10-02 11:16:06 PDT --- I haven't checked the disassembly, but I guess the problem of the failing comparison is caused by storing one value to memory as double (and doing some rounding on it along the way), while the other is still available on the FPU stack with real-precision. You might get different results when enabling optimizations. The "is" comparison is a bitwise comparison, so it will probably actually write both values to memory before the comparison, applying the same rounding to both results. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8745 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |maxim maxim-fomin.ru Resolution| |DUPLICATE --- Comment #4 from Maxim Fomin <maxim maxim-fomin.ru> 2012-10-16 09:04:44 PDT --- *** This issue has been marked as a duplicate of issue 8476 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 16 2012