Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch matlisp-cffi updated. 2012-02-23-57-g6173362

[Raymond T. <toy...@gm...>]

On Sun, Mar 18, 2012 at 8:47 PM, Akshay Srinivasan <
aks...@gm...> 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.

Thanks,

Ray