www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2388] New: type of NaN given by real.nan not specified

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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