#3070: floor(0/0) should not be defined
---------------------------------+------------------------------------------
Reporter: carette | Owner: squadette
Type: bug | Status: new
Priority: lowest | Milestone: 7.6.1
Component: Prelude | Version: 6.10.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by tristes_tigres):
Re: simonpj
I am not sure that it is appropriate to call my limited knowledge of
numerical analysis "serious expertise". But I do have some suggestions,
for what it's worth, where Haskell handling of FP could be improved.
To start from the bug under discussion, I think that the suggestions to
throw errors on round(0.0/0.0) are somewhat misguided and defeat the
purpose of having NaNs in the first place.
a) Inserting an "if" check will slow down (disrupt processor pipeline)
every time round/ceil/floor/etc is called, even though NaNs may occur in
tiny fraction of the cases
b) Throwing exception on encountering NaN may lead to termination of the
program, with many possibilities of bad things happening. It is possible
that the result of invalid operation may not be actually needed, and
occurred in some code left over in production by mistake (see the
notorious case of Ariane 5 rocket blowing over FP exception, where
precisely this happened). Clearly, this is undesirable outcome.
So how the bug can be corrected properly? By separating rounding and type
conversion. It is IMHO a design error to conflate the two. Rounded
floating point number is very typically used in further FP computations (I
already gave an example - fdlibm sine/cosine functions). So there ought
to be something like
ceilingf :: (Real a) => a -> a
floorf :: (Real a) => a -> a
truncatef :: (Real a) => => a -> a
roundf :: (Real a) => => a -> a
The existing round/floor/ceil may be implemented by adding type conversion
step (if they should be implemented at all, which I am not sure about,
other than for backward compatibility with existing software). It is this
step where exception on NaN may be properly raised,as per IEEE 754 sec.7.1
There're possible further improvements to NaN handling beyond fixing this
bug, too.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3070#comment:21>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
