Making an assumption on f doesn't seem to work, but making an assumption on F does:

> F:= f(r,z):
  conjugate(F*exp(I*delta*z)) assuming F::real;

f(r,z)*exp(-I*conjugate(delta*z)) Or you could use evalc, which by default assumes that all symbolic variables are real, and all unknown functions of real arguments are real:

> evalc(conjugate(F*exp(I*delta*z)));

f(r,z)*cos(delta*z)-I*f(r,z)*sin(delta*z) Or you could define a procedure `conjugate/f` to tell Maple how to conjugate f. I need to do a restart here if conjugate has already been called on an expression containing f, as otherwise there seem to be remember-table entries that will mess this up.

> restart;
  F:= f(r,z);
  `conjugate/f`:= proc(r,x) f(r,x) end proc;
  conjugate(F*exp(I*delta*z));

f(r,z)*exp(-I*conjugate(delta*z))

Making an assumption on f doesn't seem to work, but making an assumption on F does:

> F:= f(r,z):
  conjugate(F*exp(I*delta*z)) assuming F::real;

f(r,z)*exp(-I*conjugate(delta*z)) Or you could use evalc, which by default assumes that all symbolic variables are real, and all unknown functions of real arguments are real:

> evalc(conjugate(F*exp(I*delta*z)));

f(r,z)*cos(delta*z)-I*f(r,z)*sin(delta*z) Or you could define a procedure `conjugate/f` to tell Maple how to conjugate f. I need to do a restart here if conjugate has already been called on an expression containing f, as otherwise there seem to be remember-table entries that will mess this up.

> restart;
  F:= f(r,z);
  `conjugate/f`:= proc(r,x) f(r,x) end proc;
  conjugate(F*exp(I*delta*z));

f(r,z)*exp(-I*conjugate(delta*z))

There's a good reason for that: your matrix is the sum of two matrices of rank 1 (one where all rows are the same and one where all columns are the same), so it has rank at most 2.

There's a good reason for that: your matrix is the sum of two matrices of rank 1 (one where all rows are the same and one where all columns are the same), so it has rank at most 2.

Actually evalr doesn't prevent round-off issues, because it just does its floating-point computations with the current Digits. For example:

evalr(INTERVAL(0..1.0)/3.0);

INTERVAL(0. .. 0.3333333333)

Actually evalr doesn't prevent round-off issues, because it just does its floating-point computations with the current Digits. For example:

evalr(INTERVAL(0..1.0)/3.0);

INTERVAL(0. .. 0.3333333333)

I didn't have any < in my posting. The first Maple input was just

DEtools[rifsimp](convert([eq_0, eq_1, 
   q(t) = (D@@6)(x[0])(t)], diff));

The Maple result wasn't rendered well by the Mapleprimes software, I don't know why: it looks like it got all the content but then for some strange reason reprinted most of it in text. The second was

Q := subs(%[Solved], q(t));

and I didn't bother including the output, which was Q := (104832*x[0](t)^3*x[1](t)-64*x[0](t)-224000* x[0](t)^4*x[1](t)-104832*x[0](t)^3*x[1](t)^2 -34944*x[0](t)^3-640*x[0](t)*x[1](t)^2+320* x[0](t)*x[1](t)+640*x[0](t)*x[1](t)^3-320*x[0](t) *x[1](t)^4+3648*x[0](t)^2+112000*x[0](t)^4 *x[1](t)^2+34944*x[0](t)^3*x[1](t)^3+21888 *x[0](t)^2*x[1](t)^2-141120*x[0](t)^5+60480 *x[0](t)^6+64*x[0](t)*x[1](t)^5-14592*x[0](t)^2 *x[1](t)+141120*x[0](t)^5*x[1](t)+3648*x[0](t)^2 *x[1](t)^4+112000*x[0](t)^4-14592*x[0](t)^2 *x[1](t)^3)/(x[1](t)^11+462*x[1](t)^5-1-330 *x[1](t)^4-11*x[1](t)^10-462*x[1](t)^6+11 *x[1](t)+330*x[1](t)^7-165*x[1](t)^8+55 *x[1](t)^9-55*x[1](t)^2+165*x[1](t)^3)

I didn't have any < in my posting. The first Maple input was just

DEtools[rifsimp](convert([eq_0, eq_1, 
   q(t) = (D@@6)(x[0])(t)], diff));

The Maple result wasn't rendered well by the Mapleprimes software, I don't know why: it looks like it got all the content but then for some strange reason reprinted most of it in text. The second was

Q := subs(%[Solved], q(t));

and I didn't bother including the output, which was Q := (104832*x[0](t)^3*x[1](t)-64*x[0](t)-224000* x[0](t)^4*x[1](t)-104832*x[0](t)^3*x[1](t)^2 -34944*x[0](t)^3-640*x[0](t)*x[1](t)^2+320* x[0](t)*x[1](t)+640*x[0](t)*x[1](t)^3-320*x[0](t) *x[1](t)^4+3648*x[0](t)^2+112000*x[0](t)^4 *x[1](t)^2+34944*x[0](t)^3*x[1](t)^3+21888 *x[0](t)^2*x[1](t)^2-141120*x[0](t)^5+60480 *x[0](t)^6+64*x[0](t)*x[1](t)^5-14592*x[0](t)^2 *x[1](t)+141120*x[0](t)^5*x[1](t)+3648*x[0](t)^2 *x[1](t)^4+112000*x[0](t)^4-14592*x[0](t)^2 *x[1](t)^3)/(x[1](t)^11+462*x[1](t)^5-1-330 *x[1](t)^4-11*x[1](t)^10-462*x[1](t)^6+11 *x[1](t)+330*x[1](t)^7-165*x[1](t)^8+55 *x[1](t)^9-55*x[1](t)^2+165*x[1](t)^3)

I suspect he was talking about the transcendental case. When Joel Moses was working on Macsyma, the algebraic case and the mixed algebraic-transcendental case were still open problems.

I assume X1 and X2 are supposed to be independent. You realize, I hope, that y1 = y2 in this case.

> with(Statistics):
  X1:= RandomVariable(Uniform(-1,1));
  X2:= RandomVariable(Uniform(-1,1));
  Y1:= min(5+X1,5+X2);
  Y2:= min(5+X1,5+X2);
  Z:= Y1^(1/2)*log((40-Y2)*(80+2*Y2-3*Y1));

For some strange reason, Maple gives up on the distribution of Z. This may be a bug; however, a closed-form solution is clearly not to be expected.

> CDF(Z,t);

FAIL This one is certainly a bug:

> CharacteristicFunction(Z,t);

0 But the expected value can be obtained OK:

> ExpectedValue(Z);

-416384/75+320/3*5^(1/2)*2^(1/2)*arctanh(1/10*3^(1/2)*5^(1/2)) +70144/25*2^(1/2)*3^(1/2)+1600/3*5^(1/2)*2^(1/2)*ln(-3^(1/2) *5^(1/2)+10)-1600/3*5^(1/2)*2^(1/2)*ln(10+3^(1/2)*5^(1/2)) -1600/3*5^(1/2)*2^(1/2)*ln(10-5^(1/2)*2^(1/2))+1600/3*5^(1/2) *2^(1/2)*ln(5^(1/2)*2^(1/2)+10)-12800/3*5^(1/2)*ln(10-5^(1/2)) -96/5*ln(3)+12800/3*5^(1/2)*ln(5^(1/2)+10)-320/3*5^(1/2) *2^(1/2)*arctanh(1/10*5^(1/2)*2^(1/2))+1280/3*5^(1/2) *arctanh(1/10*5^(1/2))-192/5*ln(2)+24/5*2^(1/2)*3^(1/2) *ln(37)+24/5*2^(1/2)*3^(1/2)*ln(17)+48/5*2^(1/2)*3^(1/2) *ln(2)-48/5*ln(19)-1280/3*5^(1/2)*arctanh(1/20*2^(1/2) *3^(1/2)*5^(1/2))+12800/3*5^(1/2)*ln(20-2^(1/2)*3^(1/2) *5^(1/2))-12800/3*5^(1/2)*ln(2^(1/2)*3^(1/2)*5^(1/2)+20)

> evalf(%);

17.01371

I assume X1 and X2 are supposed to be independent. You realize, I hope, that y1 = y2 in this case.

> with(Statistics):
  X1:= RandomVariable(Uniform(-1,1));
  X2:= RandomVariable(Uniform(-1,1));
  Y1:= min(5+X1,5+X2);
  Y2:= min(5+X1,5+X2);
  Z:= Y1^(1/2)*log((40-Y2)*(80+2*Y2-3*Y1));

For some strange reason, Maple gives up on the distribution of Z. This may be a bug; however, a closed-form solution is clearly not to be expected.

> CDF(Z,t);

FAIL This one is certainly a bug:

> CharacteristicFunction(Z,t);

0 But the expected value can be obtained OK:

> ExpectedValue(Z);

-416384/75+320/3*5^(1/2)*2^(1/2)*arctanh(1/10*3^(1/2)*5^(1/2)) +70144/25*2^(1/2)*3^(1/2)+1600/3*5^(1/2)*2^(1/2)*ln(-3^(1/2) *5^(1/2)+10)-1600/3*5^(1/2)*2^(1/2)*ln(10+3^(1/2)*5^(1/2)) -1600/3*5^(1/2)*2^(1/2)*ln(10-5^(1/2)*2^(1/2))+1600/3*5^(1/2) *2^(1/2)*ln(5^(1/2)*2^(1/2)+10)-12800/3*5^(1/2)*ln(10-5^(1/2)) -96/5*ln(3)+12800/3*5^(1/2)*ln(5^(1/2)+10)-320/3*5^(1/2) *2^(1/2)*arctanh(1/10*5^(1/2)*2^(1/2))+1280/3*5^(1/2) *arctanh(1/10*5^(1/2))-192/5*ln(2)+24/5*2^(1/2)*3^(1/2) *ln(37)+24/5*2^(1/2)*3^(1/2)*ln(17)+48/5*2^(1/2)*3^(1/2) *ln(2)-48/5*ln(19)-1280/3*5^(1/2)*arctanh(1/20*2^(1/2) *3^(1/2)*5^(1/2))+12800/3*5^(1/2)*ln(20-2^(1/2)*3^(1/2) *5^(1/2))-12800/3*5^(1/2)*ln(2^(1/2)*3^(1/2)*5^(1/2)+20)

> evalf(%);

17.01371

That's strange: I don't see anything about the flat option in the help page for evalindets (or subsindets, for that matter) in Maple 11.

That's strange: I don't see anything about the flat option in the help page for evalindets (or subsindets, for that matter) in Maple 11.

I personally would find it annoying if a script complained about od and fi. I don't think there's anything wrong with those. It's just that when the try, module and use structures came in, nobody wanted to see them ended with yrt, eludom and esu, so the new scheme of "whatever ... end whatever" was adopted. What should be flagged, on the other hand, is the syntactically correct but dangerous practice of using "end" (not followed by "do", "if", "proc" etc.) as the delimiter.

I think what you mean is that it can integrate any function that has an elementary antiderivative. It certainly can't integrate elementary functions whose antiderivatives are not elementary. This one, though, does have an elementary antiderivative. It is an example of the mixed transcendental-algebraic case, because arcsin(x) = -i ln(sqrt(1-x^2) + i x). That is not completely implemented in Maple (or in any other CAS, apparently). Even the purely algebraic case is not completely implemented: see e.g. this article by Manuel Bronstein in comp.soft-sys.math.maple from November 2000. I think what he says there is still true today. Note that Bronstein's example

> int(x / sqrt(x^4 + 10*x^2 - 96*x - 71), x);

is still not handled by Maple: it returns a non-elementary antiderivative involving elliptic functions, rather than the elementary antiderivative -log((x^6+15*x^4-80*x^3+27*x^2-528*x+781) * sqrt(x^4+10*x^2-96*x-71) - x^8 - 20*x^6 + 128*x^5 - 54*x^4 + 1408*x^3 - 3124*x^2 - 10001)/8