Re: comments on Matrix

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.


>
>
> The algorithm for inversion is going to be plain closed-form matrix
> inversion (i.e. by computing the cofactors) as in
> http://en.wikipedia.org/wiki/Invertible_matrix#Inversion_of_3.C3.973_matricesbut 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.
>

I don't know how important this is as it seems like this would only apply
to edge cases.
Are there any w3c specs that define how precise a calculation should
happen? I can see how this would be very important for mathematical
programs but less so for graphics.


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