Re: comments on Matrix

2013/3/20 Rik Cabanier <cabanier@gmail.com>

>
>
> On Wed, Mar 20, 2013 at 4:29 PM, Benoit Jacob <jacob.benoit.1@gmail.com>wrote:
>
>>
>> My phrasing was unclear above. I mean that anything based on exact
>> comparisons will give jumpy results by nature, because in practice people
>> will have matrix variable whose value at a given time is the result of many
>> anterior operations, and whether all of the matrix coefficients are equal
>> to 0 / 1 exactly or not (i.e. the expected 0 could be 1e-16) will be
>> completely implementation-defined. So having APIs that return true of false
>> based on such tests is risky, because their result when called on such
>> matrices will depend on exact matrix coefficients which are
>> implementation-defined.
>>
>
> Yes, many implementations have fudge factors where something close to 0 is
> treated as such. Definitely hard to specify!
>

With or without a fudge factor, any mapping from matrices to boolean values
is discontinuous, and people will run into the discontinuity. If a boolean
must be returned (I would say at most in a separate "checked inverse"
function) then I'd rather have it be on exactly 0 determinant than with a
fudge factor, because introducing a fudge factor there would only serve to
increase the likeliness to run into the discontinuity.



> Maybe the 2D'ness of a matrix can be implied by its construction and if
> you apply 2d or 3d matrices or operations to it?
>
>
That would be consistently reliable. But the moment you add more internal
data into your Matrix class than just the matrix coefficients, you depart
further away from "canonicalness" and it becomes harder to keep consensus
i.e. different people will have differing opinions on what extra data
members Matrix should have. In my experience designing matrix libraries
that alone was a solid enough reason to avoid doing that. YMMV.

Benoit