Re: [Matlisp-commit] [matlisp-git]matlisp branch matlisp-cffi updated. 2012-02-23-57-g6173362
Raymond Toy <[email protected]> Mon, 19 Mar 2012 22:08:47 -0700
| Newsgroups | gmane.lisp.matlisp.devel |
|---|---|
| Message-ID | <CAG14z1GZWG9G9mgUSOtZ97fbXDfcuB9ti8Nuz1mUPoNYB0PoGg@mail.gmail.com> |
--===============8598884894305068304== Content-Type: multipart/alternative; boundary=20cf303bfe2478439504bba5abf4 --20cf303bfe2478439504bba5abf4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 18, 2012 at 8:47 PM, Akshay Srinivasan < [email protected]> 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 --20cf303bfe2478439504bba5abf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sun, Mar 18, 2012 at 8:47 PM, Akshay = Srinivasan <span dir=3D"ltr"><<a href=3D"mailto:[email protected]= om">[email protected]</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"im">On 03/18/2012 11:15 PM, Raymond Toy wrote:<br> > On 3/17/12 4:09 AM, Akshay Srinivasan wrote:<br> ><br> > -matlisp-commit<br> > +matlisp-devel<br> >> ;;Create a 4x4 matrix with random entries<br> >> (defvar d (make-complex-matrix 4 4))<br> >><br> >> (dotimes (i 4)<br> >> =A0 (dotimes (j 4)<br> >> =A0 =A0(setf (matrix-ref-2d d i j)<br> >> =A0 =A0 =A0 =A0 =A0(complex-coerce (complex (cl:random 10) (cl:ran= dom 10))))))<br> > There's a rand() function, but it currently doesn't work becau= se<br> > :row-stride is unbound.<br> ><br> > Is there a reason why these are unbound? =A0 Isn't there some suit= able<br> > default for this, assuming we're creating a regular full matrix?<b= r> </div>The defaults for :row-stride and :col-stride should be ((ncols mat), = 1)<br> for row-major and (1, (nrows mat)) for col-major. I can probably add<br> this into :before initialize-instance method, but I don't think that= 9;s a<br> good thing.<br></blockquote><div><br>It seems to me that if I do (make-inst= ance 'real-matrix :nrows rows :ncols cols) I shouldn't have to spec= ify the strides unless I really want to.=A0 There should be some default.= =A0 Either column-major or row-major. <br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im"><= br> ><br> >> ;;Submatrix of d starting at (1, 1) or size (2, 2)<br> >> (defvar e (sub! d 1 1 2 2))<br> > We should pick a better name than sub!, like maybe sub-matrix!. =A0And= <br> > what does the ! mean here? =A0The intention for "!" is to me= an a<br> > destructive operation so does sub! destructively modify d to make a<br= > > submatrix? =A0And what would that actually mean? =A0If it's not de= structive,<br> > then don't use "!".<br> ><br> </div>Yes, it is a bad naming convention. Can we pick some other character = to<br> indicate that the store is shared ? The "!" was meant to indicate= that<br> the store is essentially the same, but this contradicts with the usual<br> Lisp convention.<br> <div class=3D"im"><br> > It seems that e and d now both refer to the same storage. =A0So if I<b= r> > modify e, d will magically change? =A0That's expected, but once e = is<br> > created, it becomes very easy to lose track of the fact that it is a<b= r> > submatrix of d, especially at the repl. =A0I think we need to make the= <br> > relationship more explicit. =A0Maybe create a new class that is a subc= lass<br> > of matrix (or whatever) that adds a slot that holds a reference to the= <br> > matrix. =A0Kind of like how in lisp you can have displaced arrays, and= you<br> > can tell it's displaced and can chase down all the way to the fina= l,<br> > non-displaced array if you want to.<br> </div>That sounds reasonable, shouldn't be too hard to do.<br></blockqu= ote><div><br>I think if you do this, then you don't need any special na= ming convention.=A0 sub-matrix creates a submatrix of the given matrix, and= the type (submatrix) tells us instantly that something is shared.=A0 And w= e can, if we want to, chase down what matrix we're a submatrix of.=A0 I= can imagine submatrices of submatrices of ....<br> <br>Actually, we wouldn't even have to share the actual store.=A0 Just = specialize the matrix-ref methods to do the right thing.=A0 But for speed, = it's probably better to share the store slot.<br><br>I didn't think= through all of this yet, though.=A0 But I think it's a requirement tha= t we somehow be able to find out what "parent" matrix is of the s= ubmatrix.=A0 Otherwise, it will be a great source of obscure bugs like when= you unexpectedly share list structure.<br> =A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class=3D"im"><br> ><br> > But don't get me wrong. =A0Real submatrices are really, really coo= l!<br> ><br> > BTW, can you merge the master branch to the matlisp-cffi branch? =A0Th= ere<br> > are a few changes that I need to build correctly. =A0I tried myself, b= ut<br> > there's a conflict which I'm not confident in resolving on my = own.<br> </div>Yes this is done now. I didn't get any conflicts though ?<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo= te><div><br>My fault probably.=A0 I thought I did clean out my branch befor= e doing that.=A0 Anyway, I've pulled the latest matlisp-cffi so I'l= l try it out again.<br> <br>Thanks,<br><br>Ray<br></div></div> --20cf303bfe2478439504bba5abf4-- --===============8598884894305068304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure --===============8598884894305068304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Matlisp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matlisp-devel --===============8598884894305068304==--