Making fex and proj_1 into local variables changes the program entirely, I
think. They should be global variables. Maybe saying map('fex ....) etc
would help.
But there is, I suspect, not much to gain in compiling these functions. They
probably will not run faster.
They should run faster than the (compiled) old version, anyway.
There should be no need to make these pairs, though.
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of sen1 at math.msu.edu
> Sent: Tuesday, April 17, 2007 10:26 PM
> To: Stavros Macrakis
> Cc: fateman at cs.berkeley.edu; maxima at math.utexas.edu
> Subject: Re: [Maxima] question about sublist
>
> Sorry, in my last message, I meant to say that, after compilation,
> they produce runtime errors.
>
> -sen
>
>
> On Wed, 18 Apr 2007, sen1 at math.msu.edu wrote:
>
> > Following a suggestion from RJF to use the builtin function 'map', I
> > rewrote the program 'sublist.mac' which is attached. It has both
> > Jaime's routine, called 'j_sublist' and two other routines,
> called 'opp_1'
> > and 'same_1'.
> >
> > The routines opp_1, and same_1 work very fast.
> >
> > But, they won't compile. I tried putting the function
> names 'fex' and
> > 'proj_1' into the local variables of the function 'opp_1'
> The warning
> > disappeared, but it still would not compile.
> >
> >
> > (%i1) load("sublist");
> > Evaluation took 0.00 seconds (00.10 elapsed)
> > (%o1) ./sublist.mac
> > (%i2) xx: xrl(10000)$
> > Evaluation took 0.60 seconds (0.60 elapsed)
> > (%i3) same_1(xx)$
> > Evaluation took 0.52 seconds (0.53 elapsed)
> > (%i4) compile(same_1);
> >
> > Warning-> fex is an undefined global variable.
> > Warning-> proj_1 is an undefined global variable.
> > Compiling gazonk0.lsp.
> > End of Pass 1.
> > End of Pass 2.
> > OPTIMIZE levels: Safety=2, Space=3, Speed=2
> > Finished compiling gazonk0.lsp.
> > Evaluation took 0.00 seconds (0.20 elapsed)
> > (%o4) [same_1]
> > (%i5) same_1(xx)$
> >
> > Maxima encountered a Lisp error:
> >
> > symbol
> >
> > Automatically continuing.
> > To reenable the Lisp debugger set *debugger-hook* to nil.
> >
> > Any ideas?
> >
> > TIA,
> > -sen
> >
> >
> --------------------------------------------------------------
> -------------
> > | Sheldon E. Newhouse | e-mail:
> sen1 at math.msu.edu |
> > | Mathematics Department |
> |
> > | Michigan State University | telephone: 517-355-9684
> |
> > | E. Lansing, MI 48824-1027 USA | FAX: 517-432-1562
> |
> >
> --------------------------------------------------------------
> -------------
> >
> > On Tue, 17 Apr 2007, Stavros Macrakis wrote:
> >
> >> On 4/17/07, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> >>>
> >>> You can do some extra checking, but I think something
> like this will work:
> >>>
> >>> Extract(input):=block([result:[]],
> >>> map(lambda([x,y], if x*y>0 then result:cons(x,result)), input,
> >>> rest(input)),
> >>> reverse(result));
> >>>
> >>
> >> This will always given an error, since "map" requires all its list
> >> arguments
> >> to be the same length.
> >> Perhaps we should have a Lisp-like version of map which
> stops when the
> >> first
> >> list runs out.
> >>
> >> Also, map will construct an unnecessary list (which is
> then thrown away),
> >> but I suppose that is a reasonable trade-off for easier
> programming.
> >>
> >> -s
> >
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>