Re: comments on Matrix

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.

Benoit



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