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