Note that what I said was eval( %, the-letter-O = the-number-0). This is useful to get rid of an O() term in a series expansion. It works because numeric constants in Maple are also constant-functions, so that 2(e) = 2 for any expression e (and 0(whatever) = 0). use _=0 is just a short-hand for use some-short-but-unlikely-to-be-used-name = something-harmless. use in this context is what would be called a 'let binding' in most other languages, with the caveat that Maple's evaluation rules for it are non-standard (i.e. it does syntactic substitution which can lead to duplicated computations, unlike in most other languages). This is a common idiom in ML, where one often sees let _=expr in expr2 where expr is evaluated merely for the side-effects it produces. What Joe is using 'use' for is for side-effect it produces too: it produces a 'scope' to put multiple statements in! And, Shivnorr, congrats on getting your silver leaf.

Yes, the leading term of ans2^(2*a*xbar/sigma2) is the correct leading term of the asymptotic expansion. 1. the - is really a :- (colon dash) which is another method to get at elements from packages. MultiSeries:-asympt and MultiSeries[asympt] are essentially the same thing. 2. the result is correct. The error on sorting exponents still occurs of you drop the "op(1,...)" call. But since we know it is positive, then it won't change what the leading term is (up to that exponent).

Yes, the leading term of ans2^(2*a*xbar/sigma2) is the correct leading term of the asymptotic expansion. 1. the - is really a :- (colon dash) which is another method to get at elements from packages. MultiSeries:-asympt and MultiSeries[asympt] are essentially the same thing. 2. the result is correct. The error on sorting exponents still occurs of you drop the "op(1,...)" call. But since we know it is positive, then it won't change what the leading term is (up to that exponent).

I guess the conclusion from all these rather clever posts is that parse has a very silly limitation that really ought to be lifted!

is should be used to check complex properties of symbolic expressions -- not types of values! I have seen is() abused like this in other pieces of code, and then people wonder why Maple seems so slow. A call to type here will be over 100 times faster. While experimenting at the top-level, that does not make a big difference, but in an inner loop, it really does.

is should be used to check complex properties of symbolic expressions -- not types of values! I have seen is() abused like this in other pieces of code, and then people wonder why Maple seems so slow. A call to type here will be over 100 times faster. While experimenting at the top-level, that does not make a big difference, but in an inner loop, it really does.

In particular at the 'defaulttype' option. This should be sufficient. Another possibility is to grab the locals, and using a seq with the declare= option. The hacker way involves ToInert and FromInert, where you insert explicit declaration for each local. Since that sounds like fun, here: proc(p::procedure)     eval(FromInert(p), _Inert_LOCALSEQ = proc() _Inert_LOCALSEQ(op(map(proc(mm) if mm::specfunc(anything,_Inert_DCOLON) then mm else _Inert_DCOLON(mm, _Inert_NAME("float",_Inert_ATTRIBUTE(_Inert_NAME("protected")))) end if end proc, [args]))) end); end;

In particular at the 'defaulttype' option. This should be sufficient. Another possibility is to grab the locals, and using a seq with the declare= option. The hacker way involves ToInert and FromInert, where you insert explicit declaration for each local. Since that sounds like fun, here: proc(p::procedure)     eval(FromInert(p), _Inert_LOCALSEQ = proc() _Inert_LOCALSEQ(op(map(proc(mm) if mm::specfunc(anything,_Inert_DCOLON) then mm else _Inert_DCOLON(mm, _Inert_NAME("float",_Inert_ATTRIBUTE(_Inert_NAME("protected")))) end if end proc, [args]))) end); end;

There ought to be a way for us to "officially" submit bug reports. I guess emailing to support@maplesoft.com is still the best way to do that. Will you do the honours Tim?

There ought to be a way for us to "officially" submit bug reports. I guess emailing to support@maplesoft.com is still the best way to do that. Will you do the honours Tim?

So the output you have is the echo of your input, and then a pretty-print of the actual results of running that command. [You can suppress the printing of the input as well as having the output line-printed via interface calls, which usually results in output simpler to manipulate]. What happens here is that the silly pretty-printer, I guess in Standard, has decided that the output is too big and will 'elide' it for you! This seems like a bug. This is a useful feature when in interactive use, but clearly when output is re-directed, this is no longer the case, so elision should be turned OFF. You can get around this bug by explicitly turning off elision (or using the TTY version for batch computations).

So the output you have is the echo of your input, and then a pretty-print of the actual results of running that command. [You can suppress the printing of the input as well as having the output line-printed via interface calls, which usually results in output simpler to manipulate]. What happens here is that the silly pretty-printer, I guess in Standard, has decided that the output is too big and will 'elide' it for you! This seems like a bug. This is a useful feature when in interactive use, but clearly when output is re-directed, this is no longer the case, so elision should be turned OFF. You can get around this bug by explicitly turning off elision (or using the TTY version for batch computations).

Is to work with F(x) = diff(f(x),x) as the 'main' variable. Then the integral condition becomes a boundary condition!

Is to work with F(x) = diff(f(x),x) as the 'main' variable. Then the integral condition becomes a boundary condition!

So I think the answer to his question is "no, not in Classic, but it is possible in Standard".