Alasdair, Kurt and Waldek, I think I have found a reasonable way to avoid making too many assumptions in the Lisp code concerning the representation of data. The basic idea is the pass a function written in Spad to each Lisp wrapper function. I refer to this function as 'per' after the macros rep and per introduced by Aldor and used in some places in the Spad code for type-safe conversions from to and from internal representations.
Please see: https://github.com/billpage/gsla I have inserted some of the relevant code below. ; gsl.lisp: ... ; The first parameter of each routine below, is a function 'per' written ; in Spad which must convert the internal representation of returned ; values to an appropriate external representation. The purpose of 'per' ; is to minimize the number of assumptions in the Lisp code concerning the ; representation of values. ; The internal representation is that obtained directly from GSLL and ; modified if necessary to be either atomic and compatible with Spad or a ; List of such returned values. When the output of GSL is multivalued the ; output of 'per' is usually of type Record. ; The rest of the parameters must be either atomic and compatible with Spad ; or a List of such input values. The input values are modified if necessary ; to be compatible with GSLL. (defun gslintegrationqng (per f a b) (apply (|mkLispFunction3| per) (multiple-value-list (gsl:integration-qng (|mkLispFunction1| f) a b)))) ... -- gsl.spad ... integrationQng: (DF -> DF,DF,DF) -> Record(result:DF, abserr:DF, neval:Integer) ++ \spad{\integrationQng} applies the Gauss-Kronrod 10-point, ++ 21-point, 43-point and 87-point integration rules in succession ... integrationQng(f,a,b) == GSLINTEGRATIONQNG( -- convert returned values to Spad representation (v1:DF,v2:DF,v3:Integer):Record(result:DF, abserr:DF, neval:Integer)+->[v1,v2,v3], f,a,b)$Lisp Bill. > Bill Page wrote: >> This works: >> >> ; gsl.lisp >> ... >> ; Return multiple values as a vector (can be interpreted as Axiom Record) >> (defun integration-qng-vector (f a b) >> (apply #'vector (multiple-value-list (integration-qng f a b)))) >> > On 29 October 2015 at 12:59, Waldek Hebisch <[email protected]> wrote: > > Note: this is for records of length > 2. Records of lennght 2 are > represented as Lisp pairs, the same as unions. In fact, without > knowing Spad type it is impossible to distinguish record from > union: > ... > Yes. Let me just remark that the code above is fine for > experimentation. In long term we should not sprinkle > assumptions about representation of vectors all around. > So probably we should create something to create > records. Note that currently representation of record > only depends on its lenght (number of fields), but in > principle could depend on type. So one possibility > is to add real 'construct' function to Record and > get it if needed via lookup. Another it to > provide function that given type and values would > create record of given type. > > Maybe extra remark why I am making fuss here: in the past > FriCAS used quite different representation of two dimensional > arrays. We could change representation because it was only > used via small number of functions and macros. > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
