<div dir="ltr">Liam, <br><br>Sorry for being obtuse, but I am having trouble transfering the permutation array from one letm to another using either (setf (data or (setf (maref... . The error is <br><br>There is no primary method for the generic function<br>
#<STANDARD-GENERIC-FUNCTION (SETF MAREF) (9)><br>when called with arguments<br> (1 #<PERMUTATION #(211470320 0) {10031FB8A1}> 0).<br> [Condition of type SB-PCL::NO-PRIMARY-METHOD]<br><br>I am including the LU decomposition code that I am trying to get to work. What am I doing wrong?<br>
<br>(defun lu-closure (mat)<br> (multiple-value-bind<br> (dim lu per)<br> (letm ((mat* (matrix-double-float mat))<br> (dim (array-dimension mat 0))<br> ;; for the commented out code two lines down<br>
;; (per1* (permutation dim))<br> (per* (permutation dim)))<br> (lu-decomp mat* per*)<br> ;; tried to test transferring per* to per*<br> ;; (setf (data per1*) (data per*))<br> ;; (dotimes (i dim)<br>
;; (setf (maref per1* i) (maref per* i)))<br> (values dim (data mat*) (data per*)))<br> (lambda (command &rest args)<br> (case command<br> (:lu lu)<br> (:dim dim)<br> (:per per)<br> (:invert<br>
;; cannot set per*<br> (letm ((lu* (matrix-double-float lu))<br> ;; tried also (per* (permutation per))<br> (per* (permutation per))<br> (inv* (matrix-double-float dim dim)))<br> (setf (data per*) per)<br>
(lu-invert lu* per* inv*)<br> (data inv*)))<br> (:solve<br> ;; untested<br> (letm ((lu* (matrix-double-float lu))<br> (per* (permutation dim))<br> (rhs* (first args))<br>
(x* (vector-double-float dim)))<br> (setf (data per*) per)<br> (lu-solve lu* per* rhs* x*)<br> (data x*)))))))<br><br>Thanks,<br><br>Mirko<br><br><div class="gmail_quote">On Wed, Aug 6, 2008 at 7:14 PM, Liam Healy <span dir="ltr"><<a href="mailto:lhealy@common-lisp.net">lhealy@common-lisp.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Mirko,<br>
<br>
If you can't enclose everything dynamically within a letm, then using<br>
#'data to get the CL array is the way to go. You need to then<br>
recreate the GSLL object with another letm when needed. You'll just<br>
wrap in a letm when you need to call GSL functions. You can do the<br>
same now, but it requires using #'data to pull out the CL array. When<br>
you need to use it again, don't try to reuse the gsl-data object, make<br>
a new one based on the CL array you pulled out previously.<br>
<br>
Liam<br>
<br>
(P.S. You can macroexpand your letms and see how it works with<br>
allocation and freers, but I recommend you stay away from that<br>
approach. You can work outside a letm now, but it's not fun, and the<br>
ffa-based GSLL won't permit it.)<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On Wed, Aug 6, 2008 at 12:50 PM, Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>> wrote:<br>
> good news/bad news: the data command seems to preserve the values of the<br>
> m-variables. But for some reason, the pointer field of those variables is<br>
> now null. So, while the data is still accessible from the closure, it<br>
> cannot be used with gsl because the pointer information used by gsl to<br>
> access it is missing.<br>
><br>
> I think that I am looking for the following type of functionality: we create<br>
> an LU decomposition within a closure, and than can apply it for multiple<br>
> solutions, inverse, determinant, etc. Here is a sample idea (untested):<br>
><br>
> (defun lu-closure (mat)<br>
> (letm ((mat* (matrix-double-float mat))<br>
> (dim (array-dimension mat 0))<br>
> (per* (permutation dim)))<br>
> (lu-decomp mmat* per*)<br>
> (lambda (command &rest args)<br>
> (case command<br>
> (:invert (letm ((inv* (matrix-double-float dim dim)))<br>
> (lu-invert mmat* per* inv*)<br>
> (data inv*)))<br>
> (:solve (letm ((rhs* (first args))<br>
> (x* (vector-double-float dim)))<br>
> (lu-solve mmat* per* rhs* x*)<br>
> (data x*)))))))<br>
><br>
> (One could of course, just return and save the matrix and permutation<br>
> vector, and apply them subsequently. I'm not sure which is the more lispy<br>
> way)<br>
><br>
> Mirko<br>
><br>
><br>
><br>
> ---------- Forwarded message ----------<br>
> From: Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>><br>
> Date: Wed, Aug 6, 2008 at 11:12 AM<br>
> Subject: Fwd: keeping m-variables in closures<br>
> To: <a href="mailto:gsll-devel@common-lisp.net">gsll-devel@common-lisp.net</a><br>
><br>
><br>
> Actually something else may be going on here, because the m-variable x can<br>
> be accessed later on. I thought that maybe calls to lu-solve may<br>
> obliterate mmat and mrhs but that does not seem to be the case - I commented<br>
> those calls out, but mmat and mrhs are still nils.<br>
><br>
> Mirko<br>
><br>
><br>
> ---------- Forwarded message ----------<br>
> From: Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>><br>
> Date: Wed, Aug 6, 2008 at 11:01 AM<br>
> Subject: keeping m-variables in closures<br>
> To: <a href="mailto:gsll-devel@common-lisp.net">gsll-devel@common-lisp.net</a><br>
><br>
><br>
> Hello folks<br>
><br>
> (the following is not a showstopper, but I am just curious).<br>
><br>
> I am trying to define a closure (still doing LU decompositions and matrix<br>
> solutions), and would like to keep some of the variables around for further<br>
> processing. Here is one example<br>
><br>
> (defun parallel-plate-equilibrium (eps0 T0 eps1- eps1+ eps2 T2<br>
> &key (q1 0d0))<br>
> (letm ((dim 5)<br>
> (mat (make-array (list dim dim)<br>
> :element-type 'double-float<br>
> :initial-contents<br>
> (list (list 1d0 (1- eps0) 0d0 0d0 0d0)<br>
> (list (1- eps1-) 1d0 0d0 0d0 (0- eps1-))<br>
> (list 0d0 0d0 1d0 (1- eps1+) (0- eps1+))<br>
> (list 0d0 0d0 (1- eps2) 1d0 0d0)<br>
> (list (0- eps1-) 0d0 0d0 (0- eps1+) (+ eps1- eps1+)))))<br>
> (mmat (matrix-double-float mat))<br>
> ;; (mmat0 mmat)<br>
> (rhs (make-array dim<br>
> :element-type 'double-float<br>
> :initial-contents (list (st4 T0 eps0) 0d0 0d0<br>
> (st4 T2 eps2) q1)))<br>
> (mrhs (vector-double-float rhs))<br>
> (per (permutation dim))<br>
> (res (vector-double-float dim))<br>
> (0-vec (vector-double-float (make-array dim<br>
> :initial-element 0d0)))<br>
> (x (vector-double-float dim)))<br>
> (lu-decomp mmat per)<br>
> (lu-solve mmat per mrhs x)<br>
> (data x)<br>
> (lambda (command)<br>
> (case command<br>
> ;; these two will fail because mmat, mrhs, mmat0 are nil<br>
> ;; (:solve (lu-solve mmat per mrhs x))<br>
> ;; (:check (gemv :notrans 1d0 mmat0 x 0d0 0-vec))<br>
> (:mat mat)<br>
> (:rhs rhs)<br>
> (:temp (expt (/ (aref (data x) 4)<br>
> +sigma+)<br>
> 0.25))<br>
> (:fluxes (data x))))))<br>
><br>
><br>
> However, it seems that gsll's variables are discarded once the letm form is<br>
> done (as per documentation, and also with macroexpansion). But the code for<br>
> letm mentions some "freers", which gave me hope that I can specify the freer<br>
> as NIL. But I could not figure that one out quite yet. So, is it possible<br>
> to save some of gsll's variables for later use?<br>
><br>
> Thanks,<br>
><br>
> Mirko<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Gsll-devel mailing list<br>
> <a href="mailto:Gsll-devel@common-lisp.net">Gsll-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel</a><br>
><br>
><br>
</blockquote></div><br></div>