digitalmars.D.bugs - [Issue 2388] New: type of NaN given by real.nan not specified
- d-bugmail puremagic.com (18/18) Oct 03 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2388
- d-bugmail puremagic.com (11/11) Oct 03 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2388
- d-bugmail puremagic.com (30/30) Oct 06 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2388
- d-bugmail puremagic.com (16/16) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2388
http://d.puremagic.com/issues/show_bug.cgi?id=2388 Summary: type of NaN given by real.nan not specified Product: D Version: 1.035 Platform: PC OS/Version: All Status: NEW Keywords: spec Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: kamm-removethis incasoftware.de DMD gives you a quiet not-a-number for float.nan and some code relies on it. The spec page on properties should say so. We noticed this because LLVM defaults to a signaling NaN and that made the unittest of tango.math.IEEE fail with LLVMDC. --
Oct 03 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2388 bugzilla digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX I deliberately left it unspecified. The signalling/quiet distinction has not proved to be useful, and has generally dropped out of favor. Any reliance on the distinction should be removed from the unit tests. --
Oct 03 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2388 clugdbug yahoo.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Status|RESOLVED |REOPENED Resolution|WONTFIX | There would, however, be significant value in specifying what the payload of real.nan (and real.init) is. If it were specified, we could distinguish uninitialised variables from machine nans. Eg, on X86, the result of multiplying infinity by zero (or any other prohibited operation) is 0x1.7FFFFFp+NaN. If real.init was guaranteed to be different to this, then the I/O functions could display something like "nan(init)" for uninitalized variables, and "nan(ind)" for prohibited operations giving an indeterminate result. Identification of a machine nan is CPU-specific, but is trivial in all cases. IEEE 754-2008 (finally approved a few weeks ago!) includes the statement: --- Languages should provide an optional conversion of NaNs in internal format to external character sequences that appends to the basic NaN character sequences a suffix that can represent the NaN payload (see 8.2). The form and interpretation of the payload suffix is language defined. The language should require that any such optional output sequences be recognized as input in conversion of external character sequences to internal formats. --- So the use of NaN payloads is now officially mandated. Reopening this as an enhancement. I recommend a payload with the MSB set and all other bits zero. --
Oct 06 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2388 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX 16:40:20 PST --- That's a great idea, but it falls down in practice due to the varying behavior XMM and x87 opcodes have when being used to simply copy floating point values. Sometimes the Signalling Nan bit is left alone, sometimes it is converted to a Quiet Nan. Going on a quixotic quest to try to compensate for such erratic behavior results in bloated, slow code, and the marginal benefit is not worth it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 22 2012