Uh.  OK & still many thanks for the gsll package :-)

On Sat, Aug 9, 2008 at 7:59 PM, Liam Healy <lhealy@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@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@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@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@gmail.com>
>> > Date: Wed, Aug 6, 2008 at 11:12 AM
>> > Subject: Fwd: keeping m-variables in closures
>> > To: gsll-devel@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@gmail.com>
>> > Date: Wed, Aug 6, 2008 at 11:01 AM
>> > Subject: keeping m-variables in closures
>> > To: gsll-devel@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@common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>> >
>> >
>
>