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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2388


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Comment #1 from bugzilla@digitalmars.com  2008-10-03 14:33 -------
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.


-- 

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                     |




------- Comment #2 from clugdbug@yahoo.com.au  2008-10-06 06:09 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2388


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2012-01-22 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: -------