Underlying data structure

[beberman]

If we are going to refactor to use the builtin vector method then I would consider doing a full refactor of all the underlying classes in this system.

The system should support arbitrary tensors of any number of dimensions if you want to make this useful for more general computations.

The system should also support a wider class of specific matrix types - in particular diagonal, tridiagonal, upper tridiagonal etc.

My suggestion would be that the underlying type be based on vector for storage, a permutation operator that can be bound, and a ref that takes an index list.

So
(defclass tensor ()
((data - as a vector)
(dimensions - list)
(permutation - a list of integers or nil)))

Then a core reference function
(defmethod ref ((index ref) (tensor tensor))
which checks if permutation is nil/ non nil. If nil it just computes the required offset into the data given the dimensions and the index

If non-nil it first applies the permutation to the index then computes the offset.

For specialized matrixes we override this function and return 0 if the index is outside the range.

So then matrix is just
(defclass matrix (tensor)
)

with
(defgeneric make-matrix (&key &otherkeys)
(:method (&key row column) building a default)
(:method (&key row column type) building a specific type))

(defmethod transpose ((m matrix))
; this just sets the permutation to nil if it exists otherwise it sets it to '(1 0))
)

Then the generic matrix multiplies will work with all types if it uses ref underneath and specialized ones can be written to minimize the lookups as needed.

[snunez1]

Apologies, I didn't see this until now...

I need to think about this, especially in light of my recent usage of LLA and matrix libraries whilst doing some GPT type work.

My initial thought is that we'd have to justify the non-compatibility of using a specialised matrix/tensor class. One of the big frustrations I have with existing libraries is that they all want to pile on with their own version of a matrix class, leading to mutual incompatibility. Transferring to/from cl:array just to use their library is clumsy and inefficient.

I'd be inclined to explore what we can do with the base cl array. Tamas Papp had discussed this somewhere, and using pinned arrays (that aren't subject to garbage collection) and BLAS to go to/from row/column format doesn't impose too great a penalty.

I think it's hard to underestimate how much we get by remaining compatible with standard CL arrays. For example do we want to rewrite array-operations to be compatible with a new format?

To add to the mix, from a practical perspective, heterogeneous matrix operations is something I'd love to have. There's magma, from the same folks that wrote openblas that might be worth a look. Wrapping that would be very nice for anyone actually doing linear algebra work (as opposed to library development).

As I write this I wondered what the point is (even I was confused about this before). Do we really want 'lisp-only' implementations? If so, why? I don't think with the resources at hand we can hope to come close to what Magma does, and perhaps a better approach is to do in lisp what we can easily do (like array-operations) and then call out to third-party libraries for the 'hard' stuff, like a particular decomposition. I guess I'm coming to the view that a practically useful library for doing linear algebra from common lisp is necessarily going to be a mix of lisp and C/CFFI implementations (like Python is). As an academic exercise, a pure-lisp implementation might be interesting, but for actually getting work done I don't think it's practical.

Sounds like we need to have a chat.

[beberman]

Thanks for the response - let's move this to the discussion area. Perhaps other's would like to provide thoughts also. #5