Re: [geometry] Replace isIdentity()?

There are already plenty of examples where theoretically idempotent
operations aren't idempotent due to rounding error.  Off the top of my
head, "Math.sqrt(x)*Math.sqrt(x) === x" generally evaluates to false if x
isn't an integer.

Therefore, I don't think we need to treat matrix identity in any
particularly special regard here.  I would vote to leave isIdentity() in
its most basic and obvious form, that is, testing that the matrix truly is
the identity matrix, and not try to get tricky here about tracking what
transforms have been applied.

I personally think it is actually valuable for programmers to hit these
kinds of problems so that they understand the implications of finite
precision math.

- Kris

On Fri, Jun 6, 2014 at 11:33 PM, Dirk Schulze <dschulze@adobe.com> wrote:

> Hi,
>
> During the discussion on dev-platform@lists.mozilla.org[1] some engineers
> raised concerns to support isIdentity.
>
> To quote Rik:
>
> “"
> […] 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.
> “”
>
> So while the following is stable on a matrix that is already identity:
>
>         matrix.translateBy(10).translateBy(-10);
>
> Certain functions are likely to cause not identity matrices:
>
>         matrix.rotateBy(54.4, 20.5, 20.5).rotateBy(-54.4, 20.5, 20.5);
>
> Note that it rotates by 54.4 degrees and then rotates back by -54.4
> degrees. While both operations should eliminate themself, it could happen
> that the matrix is not identity anymore. The strange part: on further
> transformations it could be identity again. This is because of different
> computational precision and rounding deviations. This is usually worst if
> trigonometric functions are involved. All rotate functions use sin() or
> cos() and are more likely to cause the described behavior.
>