From: Benoit Jacob <jacob.benoit.1@gmail.com>

Date: Wed, 20 Mar 2013 21:34:56 -0400

Message-ID: <CAJTmd9qKFeYNOZrb=B9QVW7JXYxRRjsAvrrU4K8G4qJHDK8jPQ@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: public-fx@w3.org

Date: Wed, 20 Mar 2013 21:34:56 -0400

Message-ID: <CAJTmd9qKFeYNOZrb=B9QVW7JXYxRRjsAvrrU4K8G4qJHDK8jPQ@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: public-fx@w3.org

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. BenoitReceived on Thursday, 21 March 2013 01:35:23 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 22 June 2015 03:33:49 UTC
*