2014-05-31 0:40 GMT-04:00 Rik Cabanier <caban...@gmail.com>: > Objection #3: >> >> I dislike the way that this API exposes multiplication order. It's not >> obvious enough which of A.multiply(B) and A.multiplyBy(B) is doing A=A*B >> and which is doing A=B*A. >> > > The "by" methods do the transformation in-place. In this case, both are A > = A * B > Maybe you're thinking of preMultiply? >
Ah, I was totally confused by the method names. "Multiply" is already a verb, and the method name "multiply" already implicitly means "multiply *by*". So it's very confusing that there is another method named multiplyBy. Methods on DOMMatrixReadOnly are inconsistently named: some, like "multiply", are named after the /verb/ describing what they /do/, while others, like "inverse", are named after the /noun/ describing what they /return/. Choose one and stick to it; my preference goes to the latter, i.e. rename "multiply" to "product" in line with the existing "inverse" and then the DOMMatrix.multiplyBy method can drop the "By" and become "multiply". If you do rename "multiply" to "product" that leads to the question of what "preMultiply" should become. In an ideal world (not commenting on whether that's a thing we can get on the Web), "product" would be a global function, not a class method, so you could let people write product(X, Y) or product(Y, X) and not have to worry about naming differently the two product orders. > >> Objection #4: >> >> By exposing a inverse() method but no solve() method, this API will >> encourage people who have to solve linear systems to do so by doing >> matrix.inverse().transformPoint(...), which is inefficient and can be >> numerically unstable. >> >> But then of course once we open the pandora box of exposing solvers, the >> API grows a lot more. My point is not to suggest to grow the API more. My >> point is to discourage you and the W3C from getting into the matrix API >> design business. Matrix APIs are bound to either grow big or be useless. I >> believe that the only appropriate Matrix interface at the Web API level is >> a plain storage class, with minimal getters (basically a thin wrapper >> around a typed array without any nontrivial arithmetic built in). >> > > We already went over this at length about a year ago. > Dirk's been asking for feedback on this interface on www-style and > public-fx so can you raise your concerns there? Just keep in mind that we > have to support the SVGMatrix and CSSMatrix interfaces. > My ROI for arguing on standards mailing on matrix math topics lists has been very low, presumably because these are specialist topics outside of the area of expertise of these groups. Here are a couple more objections by the way: Objection #5: The isIdentity() method has the same issue as was described about is2D() above: as matrices get computed, they are going to jump unpredicably between being exactly identity and not. People using isIdentity() to jump between code paths are going to get unexpected jumps between code paths i.e. typically performance cliffs, or worse if they start asserting that a matrix should or should not be exactly identity. For that reason, I would remove the isIdentity method. Objection #6: The determinant() method, being in this API the only easy way to get something that looks roughly like a measure of invertibility, will probably be (mis-)used as a measure of invertibility. So I'm quite confident that it has a strong mis-use case. Does it have a strong good use case? Does it outweigh that? Note that if the intent is precisely to offer some kind of measure of invertibility, then that is yet another thing that would be best done with a singular values decomposition (along with solving, and with computing a polar decomposition, useful for interpolating matrices), by returning the ratio between the lowest and the highest singular value. Either that, or explain how tricky it is to correctly use the determinant in a measure of invertibility, and integrate a code example about that. Benoit > > > >> 2014-05-30 20:02 GMT-04:00 Rik Cabanier <caban...@gmail.com>: >> >>> Primary eng emails >>> caban...@adobe.com, dschu...@adobe.com >>> >>> *Proposal* >>> *http://dev.w3.org/fxtf/geometry/#DOMMatrix >>> <http://dev.w3.org/fxtf/geometry/#DOMMatrix>* >>> >>> *Summary* >>> Expose new global objects named 'DOMMatrix' and 'DOMMatrixReadOnly' that >>> offer a matrix abstraction. >>> >>> *Motivation* >>> >>> The DOMMatrix and DOMMatrixReadOnly interfaces represent a mathematical >>> matrix with the purpose of describing transformations in a graphical >>> context. The following sections describe the details of the interface. >>> The DOMMatrix and DOMMatrixReadOnly interfaces replace the SVGMatrix >>> interface from SVG. >>> >>> In addition, DOMMatrix will be part of CSSOM where it will simplify >>> getting >>> and setting CSS transforms. >>> >>> *Mozilla bug* >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1018497 >>> I will implement this behind the flag: layout.css.DOMMatrix >>> >>> *Concerns* >>> >>> None. >>> Mozilla already implemented DOMPoint and DOMQuad >>> >>> *Compatibility Risk* >>> >>> Blink: unknown >>> WebKit: in development [1] >>> Internet Explorer: No public signals >>> Web developers: unknown >>> >>> 1: https://bugs.webkit.org/show_bug.cgi?id=110001 >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
