newRPL: Simplified matrices proposal

[Claudio L.]

(06-01-2015 10:24 PM)Paul Dale Wrote:  This approach is likely to run into difficulties when you start implementing the matrix functions. What algorithms will you use to invert a matrix? There are lots of them for numeric matrices with a variety of different characteristics (speed, stability, easy reuse). For symbolic, far less so.

Then consider things like Eigen solutions and singular value decompositions? Nice numeric solutions, pretty horrible symbolically.

Yes, yes, and yes. It could get nasty, I know.

(06-01-2015 10:24 PM)Paul Dale Wrote:  You are going to have to distinguish numeric matrices somewhere along the line, if not the various special form numerics (row, tri-diagonal, triangular, blocked).

Yes, I thought that checking if a matrix is numeric is relatively quick and only needs to be done once before starting the solver. For diagonal, trangular, etc. having a different prolog won't help me either, so there's no advantage, I'll have to scan element by element.
It should be possible to do the more generic methods, and simply check if the matrix is numeric, and use more optimized methods then, without too much overhead.

Even if I used different types, then I would be trading the speed of checking if it's numeric for the mess of the "cross" routines, that need support for 2 types of objects and all their cross-operations between them (vector * matrix, vector * vector, matrix * vector, etc. would all be different routines dealing with the difference in internal format between objects).

(06-01-2015 10:24 PM)Paul Dale Wrote:  Still, delaying these decisions so the user is oblivious to them might be beneficial.

That's what I'm thinking. It's easier for the user, and also easier for me to code the algorithms knowing all matrices and all vectors have the exact same in-memory format.
There's 2 main things in my proposal:
a) Having vectors and matrices mixed, which I think is very beneficial for both user and developer. For example, the link array has the offsets stored by rows, so a 1xN vector has offsets 1..N stored contiguous and ordered in memory. A column vector (Nx1 matrix) has also 1..N offsets stored in the same order, contiguous in memory, so when I say "one vector will be transposed..." it's only to give it some math feeling, the routine just multiplies elements 1 through N without caring, which is both fast and easy to implement.

b) Having multiple object types within the same matrix. The main reason NOT to do this (as Werner pointed out) was to have all objects of uniform size. Once that falls apart, it no longer matters if they have different types. Also, in newRPL the basic operations between different object types are already dealt with overloaded operators, so algorithms will be relatively clean and oblivious of object type (at least that's what I hope).