MaplePrimes - answers and comments on Question, Encapsulated transformation of expression to compiled function

suggestion

Axel Vogt — Tue, 22 Nov 2011 19:32:19 Z

do not have Maple at my hands, now

But the compiler can not handle integrals and as you wrote it
in lower case Maple would come up with incomplete gamma,
I think.

However that may be a function, that the compiler does not know

Anyway I just would try to give the function expression directly
and not by the steps you use, so I can see what happens (and
what are the domains for my inputs)

Remove evaln

Preben Alsholm — Tue, 22 Nov 2011 19:54:08 Z

You will see one problem when you do

f:=proc(expr::evaln)
unapply(expr,y::float,a::float, b::float)
end proc:

f(H);

f2:=proc(expr)
unapply(expr,y::float,a::float, b::float)
end proc:

f2(H);

So remove the type check expr::evaln.

As for the original question replace int() by evalf(Int()):

myint:= proc(u::float)::float;
evalf(Int(exp(x^6), x=0.0..u))
end proc:

'createcomp' I don't quite understand.

Get rid of ::evaln

james1482 — Wed, 23 Nov 2011 01:58:56 Z

I'll elaborate a little on good advice already given. If you remove the ::evaln modifier in your definition of the procedure func_encaps it seems to work just fine.

By adding ::evaln to the parameter specification in your definition of func_encaps you have caused that procedure to pass the name H to the unapply call within it. This in turn produces a procedure (essentially) equivalent to

proc( y::float, a::float, b::float ) global H; return H end;

which is almost certainly not what you intended. This procedure can be compiled but, since the global name H does not evaluate to a numeric value at runtime, you get the error you see.

It is almost always a bad idea to add ::evaln (or, likewise, ::uneval) to a procedure argument specification. These modifiers force the procedure to use special evaluation rules, whcih are meant to be used only in unusual circumstances.

Hope this helps.

James McCarron, Maplesoft

func_encaps

Axel Vogt — Wed, 23 Nov 2011 14:26:26 Z

@icegood , ok, I have have not recognized it, sorry.

I think the problem with your code is, how Maple understands
- the parameters a and b within the body
- the usage of the modifier, as james 1482 points out

I guess the compiler treats a and b as symbols (=not declared
variables in a C code)

Step-by-Step here would mean

enc:= (...)
local p
p:= unapply(...)
# Compiler:-Compile # deactivate for debuging
end proc;

Now t:= enc(H), and H something simple, say H:=y+a+b.

What do you expect for t(Y,A,B) and what do you actually get?
And why?

Only if you know that it makes sense to compile.

for example

Axel Vogt — Thu, 24 Nov 2011 00:45:11 Z

enc:=proc(expr)
# risky: assumes that y,a,b are THE indets of expr ...
local p;
p:= codegen[makeproc](expr, [y::numeric,a::numeric,b::numeric]); 
#p:= codegen[prep2trans](p);
Compiler:-Compile(p, [y,a,b]);
end proc;

H:= ((as in your example above))

t:=enc(H);

t(1.0,2,3);
                         4.28730926684034230

to axel

icegood — Tue, 22 Nov 2011 20:14:02 Z

It really cannot thats why such calls should be encapsulated in fuctions (not in expressions thought unfortunately)

For example this one works:

myint:= proc(a);
return int(exp(x^6), x=0.0..a);
end proc:

createcomp:=proc (f) local exprfunc::symbol;
return Compiler:-Compile(f);
end proc:

zzz:=(y::float,a::float, b::float)->myint(a): #intermediate encapsulation

s:=createcomp(zzz);

Warning, the function names {myint} are not recognized in the target language

That what i can get! zzz compiled to external call of myint. While int directly will not even will be compiled because of syntax error (.. in arguments range for definite integral). But i don't need that actually. The question is actually then how to divide expression into 'compilible' and noncompilible parts.