From: Raymond T. <toy...@gm...> - 2012-03-18 17:46:07
|
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? Can we also fix the issue in mtimes and the autoswap thing? I'm not exactly sure what you're trying to do, but if you explain it to me, I can probably help with that. > ;;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 "!". 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. 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. Thanks for your work, Ray |
From: Akshay S. <aks...@gm...> - 2012-03-19 03:49:45
|
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. The store index is now given by: head + row-stride * i + col-stride * j > Can we also fix the issue in mtimes and the autoswap thing? I'm not > exactly sure what you're trying to do, but if you explain it to me, I > can probably help with that. Hmm, I'm not sure what it's doing either. I haven't touched mtimes yet, so its very likely the same version which is in master, the *1x1*-.. is now unbound, which will probably lead to errors. > >> ;;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. > > 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 ? Akshay |
From: Raymond T. <toy...@gm...> - 2012-03-20 05:08:53
|
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 |
From: Akshay S. <aks...@gm...> - 2012-03-20 07:05:31
|
> 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. Apparently this is the way it was supposed to work (I take my words back :) I think the initarg for {row,col}-stride was changed from zero, which makes it throw up a unbound error. I've fixed this now. > > >> >>> ;;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 .... Hmm, but if one would want to copy the submatrix, we'd have to call it something else. Or we can make sure that we never copy anything by default, I'm more in favour of this. Akshay |