Hi guys, About the error handling issue. I was just giving some feedback on Rajaditya's proposal draft and his code, and noticed the use of the BOOST_UBLAS_CHECK macro for reporting the singularity of the matrix involved. And now I see that Dhruv has also adopted this. I have a big problem with this approach, and I'd like to get that issue cleared up before anyone gets too involved into developing code for numerical methods in uBlas. The BOOST_UBLAS_CHECK macro is essentially behaves as an assert() macro, in the sense that it is only enabled on debug builds, and kind of crashes the program if the condition fails. Where it differs from assert() is that when exceptions are not disabled (globally, or only for ublas) it will throw an exception instead, and otherwise it will call std::abort(). Now, as a replacement for assert(), it has some pros and some cons, but that's not what I want to discuss. For the purposes of this discussion, this macro is equivalent to assert(). The main problem I have is with using this to report a singularity or similar conditions (like bad numeric conditioning, or numeric rank-deficiency). The problem really is that such conditions are *not* bugs, i.e., they are not things that should ever crash a program, even during debugging. Such conditions occur all the time, and not by mistake nor due to a bug. To me, it is *completely unacceptable* to have a behaviour like calling std::abort() on such a condition. Here is a very common real life example. Let's say I have some non-linear system of equations that I'm trying to do something with (e.g., run an optimization on, compute some control gain matrices, or just solve it). Typically, that will involve computing a Jacobian matrix for that system of equations, and inverting it or, equivalently, solving a linear system with it. However, there is a very real possibility that at some specific points of linearization, the Jacobian matrix will be singular (numerically-speaking), which doesn't mean that I want my overall program to crash or my algorithm to stop, because in most cases, if I detect this singularity, I can cope with it somehow (e.g., pseudo-invert it, transpose it, add matrix damping to it, etc...). I have written code like this more often that I can count. I consider it to be a part of the contract of any matrix numerical method to *gracefully* report a singularity condition or similar conditions so that an alternative method can be used instead. Code that simply crashes under those circumstances is completely worthless, nobody is going to want to use that. When I do a search for the other uses of the BOOST_UBLAS_CHECK macro, I find that pretty much everywhere that it is used, it is used as one would properly use assert(), that is, to report problems like out-of-bounds indices or mismatching matrix sizes and things like that. This is fine because all of these things can only really be the result of a bug (wrong bounds on a for-loop, wrong dimensions of matrices, etc...). And these are the only situations in which this macro should ever be used, it should be considered as a substitute for assert(), nothing more. For reporting singularities or similar conditions, there are really only two options, either throw an exception or return an error code, but only one of those two must be used consistently throughout uBlas. I personally prefer to work with exceptions, but I know that in this application domain it can be a very hard sell (especially with people wanting to use this in embedded systems). So, that really only leaves us with error-codes. That's what I would recommend. As the maintainer, David, you get to make that call. But this needs to be cleared up at some point before anyone of these guys starts working on their GSoC project(s), if accepted, of course. Cheers, Mikael. -- Sven Mikael Persson, M.Sc.(Tech.) PhD Candidate and Vanier CGS Scholar, Department of Mechanical Engineering, McGill University,