Re: comments on Matrix

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?
>
>
>>
>> 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?
>

My phrasing was unclear above. I mean that anything based on exact
comparisons will give jumpy results by nature, because in practice people
will have matrix variable whose value at a given time is the result of many
anterior operations, and whether all of the matrix coefficients are equal
to 0 / 1 exactly or not (i.e. the expected 0 could be 1e-16) will be
completely implementation-defined. So having APIs that return true of false
based on such tests is risky, because their result when called on such
matrices will depend on exact matrix coefficients which are
implementation-defined.


>
>
>>
>> 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
>>
>
>