It is a JPEG file. Frankly, this site deserves TeX typesetting, using MathJax or the like.

@roman_pearce 

I agree, a GUI should be much better than the CLI. But a better GUI, the succesor of the Classic interface, not Standard.

@roman_pearce 

I agree, a GUI should be much better than the CLI. But a better GUI, the succesor of the Classic interface, not Standard.

@acer 

No blanket assertion. Note above that I have kept open the question: "Or perhaps they can, but this is not documented", expecting earlier your comment "It can be done in Maple 17...". Actually, I "knew" about this fact (I think that you have access to check the evidence). And between quotes as I have not checked it properly, and I have no time for that. So, I wanted your independent confirmation :)

About the rest, I think that we are in full agreement.

@acer 

No blanket assertion. Note above that I have kept open the question: "Or perhaps they can, but this is not documented", expecting earlier your comment "It can be done in Maple 17...". Actually, I "knew" about this fact (I think that you have access to check the evidence). And between quotes as I have not checked it properly, and I have no time for that. So, I wanted your independent confirmation :)

About the rest, I think that we are in full agreement.

@acer 

No, I do not agree with you. First, creating an interface for output of some computation is an equally relevant programming task (actually the subject of the OP's question). So, handling it fully programmatically is as important as for the original computation. This means, the problem is not with embeded components per se, but with their disparate nature or implementation wrt the "historical" (C) sector of the Maple system in that it does not allow creating them programmatically, or making a safe backup for these objects. These characteristics combined poses a greater risk on using them, and I am just warning about this fact. This warning is fully justified and is on topic, even in the context of a particular solution involving them.

On the other hand, writing a post or submitting a SCR on such an issue that is at the core of the design strategy of the current Maplesoft management would be a waste of resources, so making it no sense, in my opinion.

@acer 

No, I do not agree with you. First, creating an interface for output of some computation is an equally relevant programming task (actually the subject of the OP's question). So, handling it fully programmatically is as important as for the original computation. This means, the problem is not with embeded components per se, but with their disparate nature or implementation wrt the "historical" (C) sector of the Maple system in that it does not allow creating them programmatically, or making a safe backup for these objects. These characteristics combined poses a greater risk on using them, and I am just warning about this fact. This warning is fully justified and is on topic, even in the context of a particular solution involving them.

On the other hand, writing a post or submitting a SCR on such an issue that is at the core of the design strategy of the current Maplesoft management would be a waste of resources, so making it no sense, in my opinion.

For me, the problem with Embedded components is that they cannot be created programmatically. Or perhaps they can, but this is not documented. And the component properties set into their form cannot be saved to text form by exporting the worksheet to the Maple input mpl file format, as far as I know. So, in my opinion, the user runs the risk of loosing that part if the Standard worksheet gets corrupted (what happens too frequently for my taste).

For me, the problem with Embedded components is that they cannot be created programmatically. Or perhaps they can, but this is not documented. And the component properties set into their form cannot be saved to text form by exporting the worksheet to the Maple input mpl file format, as far as I know. So, in my opinion, the user runs the risk of loosing that part if the Standard worksheet gets corrupted (what happens too frequently for my taste).

@Carl Love 

Axel's conjecture can be explicitly checked by tracing assume:

> J:=Int(Int(sqrt(x^2+y^2),x=y..sqrt(2*y-y^2)),y=0..1):
> vJ:=value(%):
> trace(assume):
> simplify(vJ);
--> enter assume, args = y::RealRange(0,1)
                           _EnvInside_assume := true
                                   obj := []
                                   prop := []
                         term := [y], [RealRange(0, 1)]
                                   obj := [y]
                           prop := [RealRange(0, 1)]
...

On the other hand, if you mean the following by mapping simplify, we see that it receives the integrand and the range as "disconected" arguments. Hence, assume is not being called:

> trace(assume):
> trace(simplify):
> map(simplify,vJ);
{--> enter simplify, args = -1/2*y^2*2^(1/2)*csgn(y)-1/2*y^2*ln(y+2^(1/2)*csgn(
y)*y)+1/2*(-y*(y-2))^(1/2)*2^(1/2)*y^(1/2)+1/2*y^2*ln((-y*(y-2))^(1/2)+2^(1/2)*
y^(1/2))
                       _Env_simplify_check_table := false
memory used=35.5MB, alloc=64.3MB, time=0.75
      2  1/2                2              2                  1/2
-1/2 y  2    csgn(y) + 1/4 y  ln(2) - 1/2 y  ln((2 csgn(y) + 2   ) y)
                   1/2  1/2  1/2
       (-y (y - 2))    2    y           2                1/2    1/2  1/2
     + ------------------------- + 1/2 y  ln((-y (y - 2))    + 2    y   )
                   2
<-- exit simplify (now at top level) = -1/2*y^2*2^(1/2)*csgn(y)+1/4*y^2*ln(2)-1
/2*y^2*ln((2*csgn(y)+2^(1/2))*y)+1/2*(-y*(y-2))^(1/2)*2^(1/2)*y^(1/2)+1/2*y^2*
ln((-y*(y-2))^(1/2)+2^(1/2)*y^(1/2))}
{--> enter simplify, args = y = 0 .. 1
                       _Env_simplify_check_table := false
                                   y = 0 .. 1
<-- exit simplify (now at top level) = y = 0 .. 1}

@Carl Love 

Axel's conjecture can be explicitly checked by tracing assume:

> J:=Int(Int(sqrt(x^2+y^2),x=y..sqrt(2*y-y^2)),y=0..1):
> vJ:=value(%):
> trace(assume):
> simplify(vJ);
--> enter assume, args = y::RealRange(0,1)
                           _EnvInside_assume := true
                                   obj := []
                                   prop := []
                         term := [y], [RealRange(0, 1)]
                                   obj := [y]
                           prop := [RealRange(0, 1)]
...

On the other hand, if you mean the following by mapping simplify, we see that it receives the integrand and the range as "disconected" arguments. Hence, assume is not being called:

> trace(assume):
> trace(simplify):
> map(simplify,vJ);
{--> enter simplify, args = -1/2*y^2*2^(1/2)*csgn(y)-1/2*y^2*ln(y+2^(1/2)*csgn(
y)*y)+1/2*(-y*(y-2))^(1/2)*2^(1/2)*y^(1/2)+1/2*y^2*ln((-y*(y-2))^(1/2)+2^(1/2)*
y^(1/2))
                       _Env_simplify_check_table := false
memory used=35.5MB, alloc=64.3MB, time=0.75
      2  1/2                2              2                  1/2
-1/2 y  2    csgn(y) + 1/4 y  ln(2) - 1/2 y  ln((2 csgn(y) + 2   ) y)
                   1/2  1/2  1/2
       (-y (y - 2))    2    y           2                1/2    1/2  1/2
     + ------------------------- + 1/2 y  ln((-y (y - 2))    + 2    y   )
                   2
<-- exit simplify (now at top level) = -1/2*y^2*2^(1/2)*csgn(y)+1/4*y^2*ln(2)-1
/2*y^2*ln((2*csgn(y)+2^(1/2))*y)+1/2*(-y*(y-2))^(1/2)*2^(1/2)*y^(1/2)+1/2*y^2*
ln((-y*(y-2))^(1/2)+2^(1/2)*y^(1/2))}
{--> enter simplify, args = y = 0 .. 1
                       _Env_simplify_check_table := false
                                   y = 0 .. 1
<-- exit simplify (now at top level) = y = 0 .. 1}

@Carl Love 

The code for the command dividend is in the linked comment above.

@Carl Love 

The code for the command dividend is in the linked comment above.

@Preben Alsholm 

It might be interesting trying a wrapper procedure to residue, combining these ideas: 1. an option selecting the method for series (series or MultiSeries:-series), 2. an option for a transformation operation on the result:

Residue:=proc(f,a::(name = algebraic),ser:=s,o:=(x->x))
if ser=s then o(residue(_passed)): 
elif ser=ms then
o(subs(series=MultiSeries:-series,eval(residue))(_passed)):
else residue(_passed):
end if
end proc:

> Residue(1/(2^s-1), s=2*Pi*I*3/log(2));
                                       0

> Residue(1/(2^s-1), s=2*Pi*I*3/log(2),ms);
                                       1
                                ---------------
                                       /6 I Pi\
                                       |------|
                                       \ln(2) /
                                ln(2) 2

> Residue(1/(2^s-1), s=2*Pi*I*3/log(2),ms,simplify);
                                       1
                                     -----
                                     ln(2)

> Residue(1/x^(1/3)/(x^2+2*x*cos(phi)+1), x=-exp(I*phi),ms,
> v->dividend(v,numer(v),[u->u,simplify@(u->convert(u,exp))]));
                                     1/2 I
                           -------------------------
                                        1/3
                           (-exp(phi I))    sin(phi)

On the other hand, as it is uncertain to me the reason for that shift of variable, I am not thinking of tweaking it at this moment.

@Preben Alsholm 

This is a good example showing why documented sources are needed. How to know for sure without? Two conjectures:

1. The  person that wrote this routine copied the formulas "as is" from some book.

2. The code was originally similarly as in your version, but it was later changed to the current version when fixing some bug.

It might be interesting to check the code of this procedure in versions close to 1990 (I do not have them at hand at this moment).