Thanks Acer. Your second method is easier and I tried it by making a dll of sub.

My Maple code is below.

sub1:=proc(n,x,ans)
local i,f,res;
f:=Vector(n);
f[1]:=x[1]+x[2];
f[2]:=x[1]-x[2];
res:=1;
for i from 1 to n do res:=res*f[i]; od:
ans:=evalf(res):
end:

n:=2;
x:=<1,2>;
sub:=
define_external('sub',
'FORTRAN',
'n'::integer[4],
'x'::ARRAY(datatype=float[8]),
'usersub'::PROC('subn'::integer[4],'subx'::float[8],'subres'::float[8]),
'WRAPPER',
'res'::float[8],
LIB="c:/test/sub.dll"):

sub(n,x,sub1,ans);

It doesn't work without WRAPPER and with WRAPPER, it gives an error

Error, compiler command cl -LD -Gz -Gy -I""C:\Program Files\Maple
13\extern\include"" -Femwrap_sub.dll mwrap_sub.c /link /export:MWRAP_sub
"C:\Program Files\Maple 13\bin.win/maplec.lib" returned error code 1 and
reported:
 

Is there supposed to be a cl compiler?

 

 

 

According to help, "For a non-negative integer n, the HermiteH(n, x) function computes the nth Hermite polynomial." So I would (perhaps naively) expect the result to be a polynomial. Why force the user to use the totally non-obvious and unnecessary command simplify(%,'HermiteH'); {from the help on HermiteH(n, x)) to get the obvious result? To me, it's yet another example of Maple being too smart for its own good, and making the user work hard to get a simple result. I've used Maple for a long time but still get caught out by this sort of crazy design decision.

Thanks for your elegant solution, John. My only comment is that p should be replaced by expand(p) because the input may not always be in expanded form. [In practice, there are many inputs to split that are calculated by the main routine, and they can be quite complicated.] For example, if p := (c1 + c2*x + c3*y + c4*x*y)*(c5+c6*x^5*y); your split gives the wrong answer. My solution with `has` is not good and gives wrong answers for single terms and I replaced it with a modified version of acer's as follows. split:=proc(z::polynom(anything,[x,y])) local C,t,res,tmpvar,tmpc1,tmpc2; if (z = 0) then RETURN(0) fi; tmpvar:=tmpc1*x*y+tmpc2*x^2*y^2: C:=[coeffs(expand(z+tmpvar),[x,y],'t')]; res:=add(C[i]*INT(degree(t[i],x),degree(t[i],y)),i=1..nops(C)); res:=eval(subs(tmpc1=0,tmpc2=0,res)); end proc: tmpvar is introduced to ensure that there are always at least 2 terms. It's not elegant but it works. The problem is that 't' is treated as a index variable (t[1], t[2], etc) for more that one term in z but as an ordinary variable if there is only one term in z. I wish Maple was consistent here. It's these little quirks (the expand issue is another) in Maple that I find frustrating.

I managed to fix the problem. The new version is split := proc(z::polynom(anything,[x,y])) local C,t; if (not has(z,x) and not has(z,y)) then z*INT(0,0); elif (not has(z,y)) then C:=[coeffs(expand(z),[x],'t')]; add(C[i]*INT(degree(t[i]),0),i=1..nops(C)); elif (not has(z,x)) then C:=[coeffs(expand(z),[y],'t')]; add(C[i]*INT(0,degree(t[i])),i=1..nops(C)); else C:=[coeffs(expand(z),[x,y],'t')]; add(C[i]*INT(degree(t[i],x),degree(t[i],y)),i=1..nops(C)); fi: end proc: It checks if z is only a constant or a function of x or y only. It also uses expand(z) because z may not be in expanded form on entry.

Acer If z = c*x split gives the wrong answer c1*INT(0, 0) instead of the correct c1*INT(1, 0). The same thing happens for z = c*y. Is it possible to fix this? Thanks.

Acer Split doesn't work is z = c1. In this case, it returns c1[1]*INT(0, 0) rather than the correct c1*INT(0, 0). Is it possible to fix this? Thanks.

Thanks again acer - that's exactly what I wanted.

Thanks acer. That's basically what I want except I would like split(z) to return an expression that is the sum of the terms rather than a list of terms themselves. So for the second example split(z) should return c1*INT(0,0) + c2*INT(1,0) + c3*INT(0,1) + c4*INT(1,1) Is this possible? Thanks.