Inverses get used *a lot*. I would argue that they are only 'advanced'
in that there are many lines of code in an implementation - they are a
common operation when setting up transforms or working with
transforms. For example, reverse-projecting from an onscreen point
into a point on the surface of a transformed object. If you drop them
from this matrix object, users of the matrix object will just end up
implementing determinants themselves.
I will agree that the m.inverse().transformPoint() pattern is
inefficient, but in any scenario where many points are being
transformed, can't the user do the inverse once and then transform all
the points by it? Maybe I'm misunderstanding and you are talking about
non-rendering scenarios.
On Tue, Jun 3, 2014 at 12:52 PM, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> I also think that now that determinant() is being removed, is a good time
> to revisit my Objection #4 which I don't think has been addressed at all:
> please remove inverse() too.
>
> Indeed, without its companion determinant() method, the inverse() method is
> now standing out as by far the most advanced and footgun-ish feature in
> this API, and the concerns that I expressed about it in Objection #4
> earlier in this thread still stand.
>
> With inverse() removed, the feature set would look more consistent as it
> would then purely be about creating and composing (multiplying)
> transformations.
>
> Benoit
>
>
> 2014-06-03 13:23 GMT-04:00 Rik Cabanier <caban...@gmail.com>:
>
>>
>>
>>
>> On Tue, Jun 3, 2014 at 6:06 AM, Benoit Jacob <jacob.benoi...@gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> 2014-06-03 3:34 GMT-04:00 Dirk Schulze <dschu...@adobe.com>:
>>>
>>>
>>>> On Jun 2, 2014, at 12:11 AM, Benoit Jacob <jacob.benoi...@gmail.com>
>>>> wrote:
>>>>
>>>> > 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.
>>>>
>>>> Looking at use cases, then determinant() is indeed often used for:
>>>>
>>>> * Checking if a matrix is invertible.
>>>> * Part of actually inverting the matrix.
>>>> * Part of some decomposing algorithms as the one in CSS Transforms.
>>>>
>>>> I should note that the determinant is the most common way to check for
>>>> invertibility of a matrix and part of actually inverting the matrix. Even
>>>> Cairo Graphics, Skia and Gecko’s representation of matrix3x3 do use the
>>>> determinant for these operations.
>>>>
>>>
>>> I didn't say that determinant had no good use case. I said that it had
>>> more bad use cases than it had good ones. If its only use case if checking
>>> whether the cofactors formula will succeed in computing the inverse, then
>>> make that part of the inversion API so you don't compute the determinant
>>> twice.
>>>
>>> Here is a good use case of determinant, except it's bad because it
>>> computes the determinant twice:
>>>
>>> if (matrix.determinant() != 0) { // once
>>> result = matrix.inverse(); // twice
>>> }
>>>
>>> If that's the only thing we use the determinant for, then we're better
>>> served by an API like this, allowing to query success status:
>>>
>>> var matrixInversionResult = matrix.inverse(); // once
>>> if (matrixInversionResult.invertible()) {
>>> result = matrixInversionResult.inverse();
>>> }
>>>
>>> Typical bad uses of the determinant as "measures of invertibility"
>>> typically occur in conjunction with people thinking they do the right thing
>>> with "fuzzy compares", like this typical bad pattern:
>>>
>>> if (matrix.determinant() < 1e-6) {
>>> return error;
>>> }
>>> result = matrix.inverse();
>>>
>>> Multiple things are wrong here:
>>>
>>> 1. First, as mentioned above, the determinant is being computed twice
>>> here.
>>>
>>> 2. Second, floating-point scale invariance is broken: floating point
>>> computations should generally work for all values across the whole exponent
>>> range, which for doubles goes from 1e-300 to 1e+300 roughly. Take the
>>> matrix that's 0.01*identity, and suppose we're dealing with 4x4 matrices.
>>> The determinant of that matrix is 1e-8, so that matrix is incorrectly
>>> treated as non-invertible here.
>>>
>>> 3. Third, if the primary use for the determinant is invertibility and
>>> inversion is implemented by cofactors (as it would be for 4x4 matrices)
>>> then in that case only an exact comparison of the determinant to 0 is
>>> relevant. That's a case where no fuzzy comparison is meaningful. If one
>>> wanted to guard against cancellation-induced imprecision, one would have to
>>> look at cofactors themselves, not just at the determinant.
>>>
>>> In full generality, the determinant is just the volume of the unit cube
>>> under the matrix transformation. It is exactly zero if and only if the
>>> matrix is singular. That doesn't by itself give any interpretation of other
>>> nonzero values of the determinant, not even "very small" ones.
>>>
>>> For special classes of matrices, things are different. Some classes of
>>> matrices have a specific determinant, for example rotations have
>>> determinant one, which can be used to do useful things. So in a
>>> sufficiently advanced or specialized matrix API, the determinant is useful
>>> to expose. DOMMatrix is special in that it is not advanced and not
>>> specialized.
>>>
>>
>> I agree with your points. Let's drop determinant for now.
>> If authors start to demand it, we can add it back in later.
>>
> _______________________________________________
> 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
