Re: [boost] [boost.ublas] [gsoc'15]

Subject: Re: [boost] [boost.ublas] [gsoc'15]
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2015-03-13 02:59:26

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,