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

On Sep 4, 2014, at 4:08 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> On 9/4/14, 9:42 AM, Tab Atkins Jr. wrote:
>> Inverting a matrix is a well-defined operation
> 
> When operating on real numbers.
> 
> Sadly, computers typically operate on IEEE floats/doubles, not on real numbers.  And with those, the result can depend strikingly on the exact algorithm used to compute the inverse, especially for near-singular matrices.
> 
>> which similarly had a unique and well-defined solution (but the simple algorithm wasn't
>> obvious).
> 
> There is no such thing as "unique and well-defined solution" when dealing with floating point, unless you fix the algorithm.
> 
> And I mean _really_ fix.  For example, floating point addition is not associative, and floating point multiplication does not distribute over floating point addition, so you have to be very careful when defining floating point algorithms if you really want them to produce the same output in multiple implementations.

I agree with all you said. The question is, do we want to specify the algorithm in detail and every implementation has to follow it by word? This of course applies to the other transform functions as well. Currently we reference the math for each transformation function from CSS Transforms. Optimizations are up to the implementation which will cause variances. This is currently the case for SVGMatrix and CSS transformations. I doubt that we will reach consensus for a fixed, specified algorithm in CSS. Some browsers might not even be able to influence the way transformation functions are applied. I would like to align DOMMatrix with CSS Transforms here.

Greetings,
Dirk

> 
> -Boris
>

Received on Thursday, 4 September 2014 18:42:19 UTC