#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):
I've already wrote a few things over at closed as duplicate ticket, and
would like to add the comment re the discussion above. It is quite correct
that explicit checking for undefined operations like 0.0/0.0 is adversely
affecting performance. What is worse, it affects the performance even the
vast majority of operations, where NaN would not arise. And that is
precisely why NaNs were introduced - so that you don't have to check for
invalid operations, but carry on computations to the conclusion, and if it
blew up along the way, you'll see it, and see exaclty what parts were
affected, since the result of every operation involving NaNs is also NaN.
The IEEE 754 standard authors even thought of providing a way to indicate
the source of NaN - the special bit pattern indicating NaN has some
"vacant" range, that an implementation may use to indicate thse source.
In general, it is a real pity that Haskell floating point design is so not
thoghtful - it could have been a great tool for numerical analyst. For
instance, the big thing that Haskell got wrong is that FP operations are
not pure in the sense of being fully determined by their operands. IEEE754
provides for rounding direction flags, and those can be use to check the
stability of numerical algorithms experimentally. But how to fit this into
Haskell type system - that's pretty fundamental question.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3070#comment:18>
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
