On Sun, Jun 1, 2014 at 3:11 PM, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> > > > 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. > Yeah, we had discussion on that. 'by' is not ideal, but it is much shorter than 'InPlace'. Do you have a suggestion to improve the name? > 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. > Unfortunately, we're stuck with the API names that SVG gave to its matrix. The only way to fix this is to duplicate the API and support both old and new names which is very confusing, > 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. > It is a constant struggle. We need to strike a balance between mathematicians and average authors. Stay with it and prepare to repeat yourself; it's frustrating for everyone involved. If you really don't want to participate anymore, we can get to an agreement here and I can try to convince the others. > 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. > isIdentity() indeed suffers from rounding errors but since it's useful, I'm hesitant to remove it. In our rendering libraries at Adobe, we check if a matrix is *almost* identity. Maybe we can do the same here? > 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. > I don't know why the determinant method was added and I would be fine with removing it > >> >> >>> 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
