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.
>
inverse() is one of the methods from SVGMatrix so it can't be removed.
In addition, it's a matrix method that is used quite often (and not just to
transform points) in the real world.
We could remove invert() or make the name less confusing.
> 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
