On Sun, Mar 18, 2012 at 8:47 PM, Akshay Srinivasan <akshaysrinivasan@gmail.com> wrote:
On 03/18/2012 11:15 PM, Raymond Toy wrote:
> On 3/17/12 4:09 AM, Akshay Srinivasan wrote:
> -matlisp-commit
> +matlisp-devel
>> ;;Create a 4x4 matrix with random entries
>> (defvar d (make-complex-matrix 4 4))
>> (dotimes (i 4)
>>   (dotimes (j 4)
>>    (setf (matrix-ref-2d d i j)
>>          (complex-coerce (complex (cl:random 10) (cl:random 10))))))
> There's a rand() function, but it currently doesn't work because
> :row-stride is unbound.
> Is there a reason why these are unbound?   Isn't there some suitable
> default for this, assuming we're creating a regular full matrix?
The defaults for :row-stride and :col-stride should be ((ncols mat), 1)
for row-major and (1, (nrows mat)) for col-major. I can probably add
this into :before initialize-instance method, but I don't think that's a
good thing.

It seems to me that if I do (make-instance 'real-matrix :nrows rows :ncols cols) I shouldn't have to specify the strides unless I really want to.  There should be some default.  Either column-major or row-major.

>> ;;Submatrix of d starting at (1, 1) or size (2, 2)
>> (defvar e (sub! d 1 1 2 2))
> We should pick a better name than sub!, like maybe sub-matrix!.  And
> what does the ! mean here?  The intention for "!" is to mean a
> destructive operation so does sub! destructively modify d to make a
> submatrix?  And what would that actually mean?  If it's not destructive,
> then don't use "!".
Yes, it is a bad naming convention. Can we pick some other character to
indicate that the store is shared ? The "!" was meant to indicate that
the store is essentially the same, but this contradicts with the usual
Lisp convention.

> It seems that e and d now both refer to the same storage.  So if I
> modify e, d will magically change?  That's expected, but once e is
> created, it becomes very easy to lose track of the fact that it is a
> submatrix of d, especially at the repl.  I think we need to make the
> relationship more explicit.  Maybe create a new class that is a subclass
> of matrix (or whatever) that adds a slot that holds a reference to the
> matrix.  Kind of like how in lisp you can have displaced arrays, and you
> can tell it's displaced and can chase down all the way to the final,
> non-displaced array if you want to.
That sounds reasonable, shouldn't be too hard to do.

I think if you do this, then you don't need any special naming convention.  sub-matrix creates a submatrix of the given matrix, and the type (submatrix) tells us instantly that something is shared.  And we can, if we want to, chase down what matrix we're a submatrix of.  I can imagine submatrices of submatrices of ....

Actually, we wouldn't even have to share the actual store.  Just specialize the matrix-ref methods to do the right thing.  But for speed, it's probably better to share the store slot.

I didn't think through all of this yet, though.  But I think it's a requirement that we somehow be able to find out what "parent" matrix is of the submatrix.  Otherwise, it will be a great source of obscure bugs like when you unexpectedly share list structure.

> But don't get me wrong.  Real submatrices are really, really cool!
> BTW, can you merge the master branch to the matlisp-cffi branch?  There
> are a few changes that I need to build correctly.  I tried myself, but
> there's a conflict which I'm not confident in resolving on my own.
Yes this is done now. I didn't get any conflicts though ?

My fault probably.  I thought I did clean out my branch before doing that.  Anyway, I've pulled the latest matlisp-cffi so I'll try it out again.