Re: comments on Matrix

On Mar 21, 2013, at 8:14 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:

> 
> 
> 2013/3/21 Dirk Schulze <dschulze@adobe.com>
> 
> On Mar 21, 2013, at 6:01 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> 
> >
> >
> > 2013/3/21 Rik Cabanier <cabanier@gmail.com>
> >
> >
> > On Wed, Mar 20, 2013 at 8:38 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> >
> >
> > 2013/3/20 Rik Cabanier <cabanier@gmail.com>
> >
> >
> > On Wed, Mar 20, 2013 at 6:29 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> >
> >
> > 2013/3/20 Rik Cabanier <cabanier@gmail.com>
> >
> >
> > On Tue, Mar 19, 2013 at 6:38 PM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
> > Hi,
> >
> > Seeing that a matrix API was being discussed (https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html), I thought I'd take a look and chime in.
> >
> > Here are the first few things that scare me, glancing at the current draft:
> >
> > 1. Some functions like inverse() throw on singular matrices. The problem is it's impossible to define very firmly what singular means, in floating-point arithmetic --- except perhaps by prescribing a mandatory order in which the arithmetic operations inside of inverse() are performed, which would be insane --- so saying that inverse() throws on singular matrices means in effect that there are realistic matrices on which it is implementation-defined whether inverse() throws or not. The consensus in all the serious matrix libraries that I've seen, for closed-form matrix inversion, is to just blindly perform the computation --- in the worst case you'll get Inf or NaN values in the result, which you will have anyway on some input matrices unless you mandate unduly expensive checks. More generally, I would never throw on singular-ness in any function, and in the case of 4x4 matrices and closed-form computations I wouldn't attempt to report on singular-ness otherwise than by inf/nan values.
> >
> > Are you suggesting that the user should check all the values to make sure that the matrix inversion didn't fail? That seems very expensive.
> > Can you point us to an algorithm for inversion that you think the spec should include?
> >
> > No, I'm saying that we should _not_ check anything, or if we do (say in a separate "checked inverse" method), it should be in a graceful way e.g. an output boolean parameter, not throwing an exception which by default halts the program. That's what I meant by "The consensus[...] is to just blindly perform the computation --- in the worst case you'll get Inf or NaN values in the result" above.
> >
> > That's certainly tempting! I can see how that's easier (and less disrupting).
> >
> > I checked 2 of our internal libraries, as well as Cairo, Skia and Flash and they all refuse to calculate the matrix if it's not invertible. So, not all matrix libraries do as you suggest.
> > SVGMatrix is also documented to throw.
> > These are all matrix classes designed for graphics so I *think* it makes sense to follow what they did.
> >
> > I had dedicated matrix libraries in mind, rather than the casual incidental matrix computation in something like Cairo.
> >
> > So, are you saying the matrix class should not throw?
> >
> > Yes. Matrices are just a generalization of numbers (which are 1x1 matrices). Numbers don't throw --- not even 1/0 or 0/0. Matrices should not, either.
> That is not correct. Mathematically, a matrix is different from a number.
> 
> I just phrased a personal opinion there, with which you may disagree, but that viewpoint has served me well as far as I'm concerned. 
>  
> Even if a one element matrix has special additional behaviors over a multi element matrix. This is not an argument for a special treatment. Especially for inverse() I do care more about backward compatibility to SVGMatrix[1]. There is content activity using it.
> 
> Earlier in this thread someone asked me to clarify what I meant by basic mistakes in SVGMatrix. That would be one. Throwing defaults to killing the program, and that shouldn't happen by default as a result of floating-point imprecision.
>  
> As Rik mentioned in previous postings, this is not much different to the treatment of transformation matrices in graphics libraries anyway. Again, we are not talking about matrices in general, but matrices used in computer graphics. And items of NaN and Infinity just theoretically make sense.
> 
> I'm afraid there might be a misconception that graphics would have its own requirements on matrix computations that would make it stand apart from scientific software doing matrix computations. I don't think that's the case. In my experience, when graphics code did things differently than scientific matrix libraries, that was typically a consequence if its author being more skilled in graphics than in matrix math.

I would be very carefully with such a generalized statement.

Greetings,
Dirk

> 
> Benoit
> 
>  
> 
> Greetings,
> Dirk
> 
> [1] http://www.w3.org/TR/SVG/coords.html#__svg__SVGMatrix__inverse
>

Received on Thursday, 21 March 2013 15:28:32 UTC