Not sure what more you might be after. Was wmsical an IBM RT running AIX 2.2, as seen here? And you gave a uucp bang path. So your mail came through utoronto? Full path was usually what, utai!watmath!wmsical or uunet!watmath!wmsical ?

acer

Does anyone else think that having package member routines get displayed as subscripted names in 2D Math output is unhelpful and misleading?

acer

It was an educated guess, to choose that assumption. It looked a little like a distribution function, or something similar for which it might be plausible, and I suspected that Maple's int() might have trouble (due to branch issues) handling the 3/2-fractional power otherwise.

Note that `int` (as well as `simplify`) knows something about how to use assumptions. So you may also succeed in one step with,

int(expr,v=0..infinity) assuming m/(Pi*k*T)>0

acer

It was an educated guess, to choose that assumption. It looked a little like a distribution function, or something similar for which it might be plausible, and I suspected that Maple's int() might have trouble (due to branch issues) handling the 3/2-fractional power otherwise.

Note that `int` (as well as `simplify`) knows something about how to use assumptions. So you may also succeed in one step with,

int(expr,v=0..infinity) assuming m/(Pi*k*T)>0

acer

> p:=t^6+t^3+1:

> P:=subs(t=y^(1/3),p);
                                      2
                                P := y  + y + 1

And so on, taking all three cube roots of the two complex solutions of P=0.

acer

> p:=t^6+t^3+1:

> P:=subs(t=y^(1/3),p);
                                      2
                                P := y  + y + 1

And so on, taking all three cube roots of the two complex solutions of P=0.

acer

Surely by fprime the instructor meant the first derivative of f with respect to x. Ie, D(f0), which you assigned to f1. Sometimes the notation f' is used.

f0:=x->x/(sqrt(x^2 + cos(x-1))):
f1:=D(f0):

Joe's shown you an automated way to repeatedly call fsolve and avoid the roots previously found. It's easier than doing things like the following.

plot(f1,-8..8);
plot(f1,-6..-1);
fsolve('f1'(x),x=-6..-4);
fsolve('f1'(x),x=-2..0);
plot(f1,3..8);
fsolve('f1'(x),x=3..4);
fsolve('f1'(x),x=6..8);

acer

Surely by fprime the instructor meant the first derivative of f with respect to x. Ie, D(f0), which you assigned to f1. Sometimes the notation f' is used.

f0:=x->x/(sqrt(x^2 + cos(x-1))):
f1:=D(f0):

Joe's shown you an automated way to repeatedly call fsolve and avoid the roots previously found. It's easier than doing things like the following.

plot(f1,-8..8);
plot(f1,-6..-1);
fsolve('f1'(x),x=-6..-4);
fsolve('f1'(x),x=-2..0);
plot(f1,3..8);
fsolve('f1'(x),x=3..4);
fsolve('f1'(x),x=6..8);

acer

Robert asked not to solve this. Hopefully I edited out an indefinite solution quickly enough.

acer

Robert asked not to solve this. Hopefully I edited out an indefinite solution quickly enough.

acer

Sorry, Robert.

acer

Sorry, Robert.

acer

Posting the same question in eight or so different forums here on mapleprimes may not endear you.

I posted two examples as a reply in another forum.

acer

Ok, so now there is no internal limit hit on the number of parameters that you pass, which is good. I did not know of a limit on the number of (integer?) parameters in so-called "wrapperless" external calling. Interesting.

The runtime exception that you see now might be something completely different, caused perhaps by any number of things, eg. not passing integers by reference when the C code expects it, calling convention issues (cdecl), something wrong in th code, etc, etc.

I've had generally good experiences with define_external and using the WRAPPER options to produce a C wrapper. I don't think that it's all broken.

But of course runtime exceptions can be hard to diagnose (especially from a distance). If you used the WRAPPER option then there should be a file named something like mwrap_myproc.c on you machine. That might help your diagnosis.

acer

Ok, so now there is no internal limit hit on the number of parameters that you pass, which is good. I did not know of a limit on the number of (integer?) parameters in so-called "wrapperless" external calling. Interesting.

The runtime exception that you see now might be something completely different, caused perhaps by any number of things, eg. not passing integers by reference when the C code expects it, calling convention issues (cdecl), something wrong in th code, etc, etc.

I've had generally good experiences with define_external and using the WRAPPER options to produce a C wrapper. I don't think that it's all broken.

But of course runtime exceptions can be hard to diagnose (especially from a distance). If you used the WRAPPER option then there should be a file named something like mwrap_myproc.c on you machine. That might help your diagnosis.

acer