Re: [geometry] Define algorithm for inverse() method on DOMMatrix

On Thu, Sep 4, 2014 at 1:41 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hi,
>
> It was brought up[1] that the inverse() method for DOMMatrix[2] does not specify the used algorithm. The bug report mentions different ways to compute the inverse of a matrix. Some include computing the determinant which was removed from the spec recently on request because of its potential numeric instability. The editors intentionally left the choice of the used algorithm to the user agents. There might be implementation details influencing the decision.
>
> With this email I seek for input from implementers: Should the editors continue to let implementations chose the used algorithm? Do implementations want or even need a specific algorithm? If implementations do want or need the algorithm, do you have a preference?

Inverting a matrix is a well-defined operation, so I don't think an
algorithm *needs* to be defined for it.  However, it's often helpful
to have a reference algo, either inline or pointed to; I got this
feedback for some of the mathy stuff in gradients, which similarly had
a unique and well-defined solution (but the simple algorithm wasn't
obvious).

If there's a particularly good inversion algorithm that doesn't suffer
from, e.g., numerical instability, I think it's a good idea to include
or point to.  Even if they all have weaknesses, if the algorithm in
wikipedia is particularly bad, I think it's a good idea to include or
point to a decent one.  If wikipedia is fine, then I don't think
there's too much need, but I certainly wouldn't object to the
inclusion of one either.

~TJ

Received on Thursday, 4 September 2014 13:43:31 UTC