- From: Benoit Jacob <jacob.benoit.1@gmail.com>
- Date: Wed, 20 Mar 2013 21:29:59 -0400
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: public-fx@w3.org
- Message-ID: <CAJTmd9pRWhC3jXZh_tS6-Ss8guPzFAQ-r32Nw5KV3aM4haBonQ@mail.gmail.com>

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