Re: comments on Matrix

On Wed, Mar 20, 2013 at 4: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?
>>
>>
>>>
>>> 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.
>

Yes, many implementations have fudge factors where something close to 0 is
treated as such. Definitely hard to specify!
Maybe the 2D'ness of a matrix can be implied by its construction and if you
apply 2d or 3d matrices or operations to it?