On Sun, Mar 18, 2012 at 8:47 PM, Akshay Srinivasan <email@example.com>
On 03/18/2012 11:15 PM, Raymond Toy wrote:The defaults for :row-stride and :col-stride should be ((ncols mat), 1)
> On 3/17/12 4:09 AM, Akshay Srinivasan wrote:
>> ;;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?
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
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.
Yes, it is a bad naming convention. Can we pick some other character to
>> ;;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 "!".
indicate that the store is shared ? The "!" was meant to indicate that
the store is essentially the same, but this contradicts with the usual
That sounds reasonable, shouldn't be too hard to do.
> 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.
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.
Yes this is done now. I didn't get any conflicts though ?
> 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.
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.