[GHC] #9530: min / max do not always return the other argument when one of the arguments is NaN
GHC
ghc-devs at haskell.org
Sun Aug 31 23:46:28 UTC 2014
#9530: min / max do not always return the other argument when one of the arguments
is NaN
-------------------------------------+-------------------------------------
Reporter: jrp | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Prelude | Version: 7.8.3
Resolution: | Keywords:
Operating System: MacOS X | Architecture: Unknown/Multiple
Type of failure: Incorrect | Difficulty: Easy (less than 1
result at runtime | hour)
Test Case: | Blocked By: 9276
Blocking: | Related Tickets: 9276
Differential Revisions: |
-------------------------------------+-------------------------------------
Comment (by jrp):
Thanks. I'll have a more detailed look. I can't, however, see any good
reason for having min / max asymmetrical in their arguments, whether the
result is to be NaN or the other argument.
The standard seems to agree. It says (at 5.3.1) that
'''''minNum(x, y) is''' the canonicalized number x if x<y, y if y<x,
'''the canonicalized number if one operand is a number and the other a
quiet NaN.''' Otherwise it is either x or y, canonicalized (this means
results might differ among implementations). When either x or y is a
signalingNaN, then the result is according to 6.2.
6.2: ''... For an operation with quiet NaN inputs, other than maximum and
minimum operations, if a floating-point result is to be delivered the
result shall be a quiet NaN which should be one of the input NaNs. ...''
(I am ignoring signalling NaNs here as they don't seem to be relevant to
Haskell.)
As things stand, Haskell sometimes returns NaN and sometimes the other
argument, depending on the order in which the arguments are presented. I
can't see how this can be right, What am I missing?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9530#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list