From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 20 Mar 2013 19:59:29 -0700
Message-ID: <CAGN7qDAviybDjMEt4E4-OcAWARCAhRnpThnpvOzDVhvxTXM9bQ@mail.gmail.com>
To: Benoit Jacob <jacob.benoit.1@gmail.com>

```On Wed, Mar 20, 2013 at 6:34 PM, Benoit Jacob <jacob.benoit.1@gmail.com>wrote:

>
>
> 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.

Authors will not see that internal member. This would be purely up to the
internal implementation. (Not that that would be without controversy :-) )
It might not even be a boolean, the matrix class could have a pointer to a
3d or 4d matrix and is2D() could simply check the class type.
```
Received on Thursday, 21 March 2013 02:59:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:44 UTC