<div dir="ltr">Uh. OK & still many thanks for the gsll package :-)<br><br><div class="gmail_quote">On Sat, Aug 9, 2008 at 7:59 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;">It looks like there might be a problem in the implementation of permutations.<br>
I'll take a look at that when doing the ffa port.<br>
<font color="#888888"><br>
Liam<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
On Fri, Aug 8, 2008 at 1:14 PM, Mirko Vukovic <<a href="mailto:mirko.vukovic@gmail.com">mirko.vukovic@gmail.com</a>> wrote:<br>
> Liam,<br>
><br>
> Sorry for being obtuse, but I am having trouble transfering the permutation<br>
> array from one letm to another using either (setf (data or (setf (maref... .<br>
> 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.<br>
> 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>
> On Wed, Aug 6, 2008 at 7:14 PM, Liam Healy <<a href="mailto:lhealy@common-lisp.net">lhealy@common-lisp.net</a>> wrote:<br>
>><br>
>> 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>
>><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>><br>
>> 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<br>
>> > 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<br>
>> > 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<br>
>> > 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<br>
>> > 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<br>
>> > 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<br>
>> > matrix<br>
>> > solutions), and would like to keep some of the variables around for<br>
>> > 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-<br>
>> > 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<br>
>> > is<br>
>> > done (as per documentation, and also with macroexpansion). But the code<br>
>> > for<br>
>> > letm mentions some "freers", which gave me hope that I can specify the<br>
>> > freer<br>
>> > as NIL. But I could not figure that one out quite yet. So, is it<br>
>> > possible<br>
>> > to save some of gsll's variables for later use?<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Mirko<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<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>
><br>
><br>
</div></div></blockquote></div><br></div>