Re: comments on Matrix

On Mar 21, 2013, at 6:01 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:

> 
> 
> 2013/3/21 Rik Cabanier <cabanier@gmail.com>
> 
> 
> On Wed, Mar 20, 2013 at 8:38 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> 
> 
> 2013/3/20 Rik Cabanier <cabanier@gmail.com>
> 
> 
> On Wed, Mar 20, 2013 at 6:29 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> 
> 
> 2013/3/20 Rik Cabanier <cabanier@gmail.com>
> 
> 
> On Tue, Mar 19, 2013 at 6:38 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> Hi,
> 
> Seeing that a matrix API was being discussed (https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html), I thought I'd take a look and chime in.
> 
> Here are the first few things that scare me, glancing at the current draft:
> 
> 1. Some functions like inverse() throw on singular matrices. The problem is it's impossible to define very firmly what singular means, in floating-point arithmetic --- except perhaps by prescribing a mandatory order in which the arithmetic operations inside of inverse() are performed, which would be insane --- so saying that inverse() throws on singular matrices means in effect that there are realistic matrices on which it is implementation-defined whether inverse() throws or not. The consensus in all the serious matrix libraries that I've seen, for closed-form matrix inversion, is to just blindly perform the computation --- in the worst case you'll get Inf or NaN values in the result, which you will have anyway on some input matrices unless you mandate unduly expensive checks. More generally, I would never throw on singular-ness in any function, and in the case of 4x4 matrices and closed-form computations I wouldn't attempt to report on singular-ness otherwise than by inf/nan values.
> 
> Are you suggesting that the user should check all the values to make sure that the matrix inversion didn't fail? That seems very expensive.
> Can you point us to an algorithm for inversion that you think the spec should include?
> 
> No, I'm saying that we should _not_ check anything, or if we do (say in a separate "checked inverse" method), it should be in a graceful way e.g. an output boolean parameter, not throwing an exception which by default halts the program. That's what I meant by "The consensus[...] is to just blindly perform the computation --- in the worst case you'll get Inf or NaN values in the result" above.
> 
> That's certainly tempting! I can see how that's easier (and less disrupting).
> 
> I checked 2 of our internal libraries, as well as Cairo, Skia and Flash and they all refuse to calculate the matrix if it's not invertible. So, not all matrix libraries do as you suggest.
> SVGMatrix is also documented to throw. 
> These are all matrix classes designed for graphics so I *think* it makes sense to follow what they did.
> 
> I had dedicated matrix libraries in mind, rather than the casual incidental matrix computation in something like Cairo. 
> 
> So, are you saying the matrix class should not throw?
> 
> Yes. Matrices are just a generalization of numbers (which are 1x1 matrices). Numbers don't throw --- not even 1/0 or 0/0. Matrices should not, either.
That is not correct. Mathematically, a matrix is different from a number. Even if a one element matrix has special additional behaviors over a multi element matrix. This is not an argument for a special treatment. Especially for inverse() I do care more about backward compatibility to SVGMatrix[1]. There is content activity using it. As Rik mentioned in previous postings, this is not much different to the treatment of transformation matrices in graphics libraries anyway. Again, we are not talking about matrices in general, but matrices used in computer graphics. And items of NaN and Infinity just theoretically make sense.

Greetings,
Dirk

[1] http://www.w3.org/TR/SVG/coords.html#__svg__SVGMatrix__inverse

Received on Thursday, 21 March 2013 14:48:09 UTC