Re: comments on Matrix

2013/3/20 Rik Cabanier <>

> On Tue, Mar 19, 2013 at 6:38 PM, Benoit Jacob <>wrote:
>> Hi,
>> Seeing that a matrix API was being discussed (
>>, 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.

The algorithm for inversion is going to be plain closed-form matrix
inversion (i.e. by computing the cofactors) as in
instead of mandating implementers to use particular formulas, a good
matrix API would rather carefully avoid being too sensitive to the exact
floating-point values (e.g. by not throwing on singular matrices) because
even mandating formulas won't ensure that the results are the same
everywhere up to the last bit of precision.

>> 2. I am concerned that something like DecomposedMatrix is
>> under-documented and opens a pandora box of adding features.
>> 2a. DecomposedMatrix is under-documented.
> I agree
>> All I can see for documentation is the algorithms given in sections 5 and
>> 6. I would like to see a mathematical description of the components of this
>> decomposition i.e. I shouldn't have to look at code. This is not precisely
>> implied by the sames of the fields in DecomposedMatrix.
>> 2b. DecomposedMatrix is a pandora box of adding features
> I agree. Let's scratch the current pseudo-code.
> If people insist on having a decomposition method, let's offer a couple
> reasonable ones (polar, euler, ....)
>> There are so many different ways of decomposing a matrix that once you
>> start offering something like DecomposedMatrix, people will ask for endless
>> variants, and you'll have to either bloat the API until it's really big or
>> accept that your API only is useful in a small minority of use cases. Just
>> an example, it seems that you chose to call "scaling" scaling coefficients
>> along the X, Y, Z axes. So when users will want to perform a polar
>> decomposition, say matrix = rotation * scaling where scaling is along
>> arbitrary axes (i.e. an arbitrary symmetric matrix), they won't find
>> DecomposedMatrix very useful. If you accept to add such a polar
>> decomposition, then next thing people will ask for polar decompositions on
>> the other side (matrix = scaling * rotation) and if you ask that, then next
>> thing is people will ask for SVD decompositions. Another example is you
>> chose to represent rotations as quaternions, so people will ask you to add
>> also rotation matrices (say for performance of multiplying with vectors)
>> and for angle-axis representation, and for Euler angles... That won't end
>> before your API has evolved into a full-blown matrix library, which will be
>> costly for browser developers to support.
>> 3. Many concepts are not defined (and their mathematical names aren't
>> that specific).
>> Examples "the skew angle in degrees", the "perspective" vector, the order
>> of coefficients in a quaternion (is the unit quaternion 1,0,0,0 or 0,0,0,1
>> in your convention?)
>> 4. Some method names are verbs, yet they do not perform an action on
>> their object. Example: translate(). I would call that translated(), I
>> suppose.
>> 5. Is2D() is going to suffer from the same caveats as discussed above
>> about singular-ness: it is going to be too capricious, in effect its return
>> value will be implementation-defined on realistic matrices. I don't think
>> that a Web-facing API should have such things.
> Could we just say that the matrix is 2d is there's only 0's (and one 1)
> for the z components?
>> 6. More generally I am concerned that it is going to be difficult to find
>> a good compromise between keeping this small and easy for browsers to
>> implement, and making this useful to many people. There are so many things
>> to take care of in a matrix library. Suppose for a moment that this becomes
>> really popular. People are going to benchmark browsers running matrix
>> computations using this API. That will add pressure on browser developers
>> to make this run as fast as possible, yet this API is inherently unfriendly
>> to optimizing performance: from simple things like counting in degrees, to
>> deeper things such as the fact that this API forces to split nontrivial
>> matrix calculations into multiple calls (e.g. .scale().translated()....)
>> and that means that making this run as fast as possible, i.e. without
>> useless temporaries, will require dedicated support from the JS compiler
>> (to achieve the same temporaries-removing tricks that C++ matrix libraries
>> achive using expression templates). This is serious stuff --- performance
>> gains can be 2x on real-world operations. So this will really be a chore
>> for browser developers to maintain, and I haven't even started talking
>> about SIMD... Meanwhile, with things like asm.js, high-performance JS is
>> closing in on "native" performance, and since a JS matrix library
>> implicitly exposes the entire expression trees to the JS compiler, they can
>> automatically benefit from generic JS compiler optimizations for things
>> like the above-mentioned temporaries-removal, and more. Moreover, this
>> allows one to pick any existing high-quality C++ matrix library -- there
>> are many! -- rather than having to use a one-size-fits-all Web standard
>> library. In fact I expect that people will do that anyway, so that any
>> official standard Web matrix library, I am afraid, is at risk of being
>> another little-used Web API incurring overhead onto browser developers.
>> Benoit

Received on Thursday, 21 March 2013 01:30:27 UTC