From: Rik Cabanier <cabanier@gmail.com>

Date: Wed, 20 Mar 2013 16:44:38 -0700

Message-ID: <CAGN7qDCR1ERrp2yd3DRuB6EhuiDAx8evnyFhwAST=LYRXXd1Aw@mail.gmail.com>

To: Benoit Jacob <jacob.benoit.1@gmail.com>

Cc: public-fx@w3.org

Date: Wed, 20 Mar 2013 16:44:38 -0700

Message-ID: <CAGN7qDCR1ERrp2yd3DRuB6EhuiDAx8evnyFhwAST=LYRXXd1Aw@mail.gmail.com>

To: Benoit Jacob <jacob.benoit.1@gmail.com>

Cc: public-fx@w3.org

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?Received on Wednesday, 20 March 2013 23:45:06 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 19:49:44 UTC
*