All this is certainly true. But there is still a valid concern: Numerical tasks often allow to predict whether an error might occur or not. Let's say you know that you have a normal matrix N and want to calculate (1+N*N)^-1. Of course the matrix is invertible and therefore it is reasonable to provide two distinct implementations: invMat :: Mat -> Maybe Mat invMat = ... -- |Like 'invMat' but gives an error in case the matrix is not invertible. invMat' :: Mat -> Mat invMat' = fromJust . invMat Kind regards Torsten -----Ursprüngliche Nachricht----- Von: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] Im Auftrag von Henning Thielemann Gesendet: Dienstag, 24. März 2009 21:34 An: Xiao-Yong Jin Cc: haskell-cafe@haskell.org Betreff: Re: Exception handling in numeric computations (was Re: [Haskell-cafe]Use unsafePerformIO to catch Exception?) On Tue, 24 Mar 2009, Xiao-Yong Jin wrote:
invMat :: Matrix -> Matrix
You won't be able to invert all the matrix, mathematically. And computationally, even a larger set of matrix might fail to be inverted because of the finite precision. It is relatively easier and more efficient to spot such a problem within this 'invMat' function. Because testing the singularity of a matrix is equally hard as invert it. So all I can do when 'invMat' spot a singular matrix are
a) Return Either/Maybe to signal an error.
This is the way to go.
b) Wrap it in a monad.
Either and Maybe are monads. These monads behave like exceptions in other languages. I like to call these exceptions.
c) Define a dynamic exception and throw it.
You cannot throw an exception in code that does not return Maybe, Either, IO or such things. You can only abuse 'undefined' and turn it into a defined value later by a hack. Think of 'undefined' as an infinite loop, that cannot detected in general. GHC is kind enough to detect special cases, in order to simplify debugging. But this should be abused for exceptional return values.
The problem is that there will be many functions using such a function to invert a matrix, making this inversion function return Either/Maybe or packing it in a monad is just a big headache. It is impractical to use method (a), because not every function that uses 'invMat' knows how to deal with 'invMat' not giving an answer.
How shall it deal with 'undefined' then? 'undefined' can only be handled by a hack, so Maybe or Either are clearly better.
invMat :: Matrix -> NumericCancerMonad Matrix
It hides the exceptional nature of numerical computations very well, but it is cancer in the code. Whenever any function wants to use invMat, it is mutated. This is just madness.
No it makes explicit what's going on. This is the idea of functional programming. You have nice Applicative infix operators in order to write everything in a functional look anyway. In contrast, I think it is mad that there is no function of type mulInt :: Int -> Int -> Maybe Int which allows us to catch overflows without using hacks. This function could be easily integrated in a compiler, since the CPUs show by a flag, that an overflow occurs. In most high level languages this is not possible, and thus programming in an overflow-proof way needs additional computations.
You don't want to make all the code to be monadic just because of singularities in numeric calculation. Therefore, in my opinion, method (c) is my only option.
Then better stick to MatLab. :-( _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe