E.g. for the Legendre transformation.

A workaround is using combine:

combine(abs(z)^Re(a)*abs(z)^(Im(a)*I));
	abs(z)^(Re(a)+Im(a)*I)

The geometry package was intended for this purpose, but instead of being improved, its development was quite of frozen long time ago. Yet, something basic as segments with labeled end points can still be easily ploted:

with(geometry):
point(A,-3,5), point(B,-1,8), point(C,3,6), point(DD,8,-4);
draw([dsegment(AB,[A,B]),dsegment(BC,[B,C]),dsegment(CDD,[C,DD]),
dsegment(DDA,[DD,A])],printtext=true);

The geometry package was intended for this purpose, but instead of being improved, its development was quite of frozen long time ago. Yet, something basic as segments with labeled end points can still be easily ploted:

with(geometry):
point(A,-3,5), point(B,-1,8), point(C,3,6), point(DD,8,-4);
draw([dsegment(AB,[A,B]),dsegment(BC,[B,C]),dsegment(CDD,[C,DD]),
dsegment(DDA,[DD,A])],printtext=true);

There is a problem here:

w3:=abs(z)^Re(a)*abs(z)^(Im(a)*I);
simplify(w3);

                              Re(a)      (Im(a) I)
                   w3 := | z |      | z |


                         Re(a)      (Im(a) I)
                      | z      | z |          |

I do not understand what was intended with this strange transformation, as the generic case does not have such problem:

simplify(abs(z)^alpha*abs(z)^beta);
                              (alpha + beta)
                         | z |

In your example it becomes:

tstData:= [z=-2*I, a=+I]:
eval(w3, tstData); 
eval(simplify(w3), tstData); 

                                   I
                                  2

                                   I
                                | 2  |
Or numerically:
eval(w3, tstData): evalf(%);
eval(simplify(w3), tstData): evalf(%);

                    0.7692389014 + 0.6389612763 I

                             1.000000000

The point here is Jacques' comment about static types in Maple. It is pretty obvious that for a concept to be useful for a wide range of programming languages many system peculiarities should be omited.

For this purpose it is much more helpful to start from the half filled glass view instead of the half empty glass view. You will always have time later to go into details and complications.

Doing so you would have realized that the analogy applies to the cases where no uniquification and re-ordering occurs like

convert([a,b,c],set);
                              {a, b, c}

(and it is not relevant for defining the character of static type).

 I hope that Jacques could post some useful hindsights on this issue.

This bug is also present in the latest version of MultiSeries:-limit from gfun 3.41.

I follow now your meaning but do not agree with your conclusion. Changing an object from type 'Matrix' into type 'Array' does not seem to me different than changing a container object of type 'list' into 'set', both surface/kernel types. If the latter transformation is a change of static type, I think that the same holds for the former.

By the way, I have not described a static type but transcribed other's descriptions and I am trying to see how they apply to Maple (if they can be applied).

I mean exactly what I have said: types defined in the library, like type/Matrix that could be interpreted as static (types defined in the kernel were the subject of the previous paragraph). And for examples of what I describe as the independence of the type from the values asigned to the objects they contain (type integer, float, symbol, etc) consider:

type(<<1,2>,<3,4>>,Matrix);
                                 true

type(<<1.1,2.2>,<3.3,4.4>>,Matrix);
                                 true

type(<<a,b>,<c,d>>,Matrix);
                                 true

Your examples deal, I think, with type-dependent overloading of the dot operator, which is another issue.

This phrase "'static' typing, which means typing at 'compile time'" makes me wonder how does this concept apply to Maple non-compiled usage. I see also this sentence:

In static typing, types are associated with variables not values.

As I am not aware of any documentation on this subject, some guesses follow, by interpretation of these statements.

The kernel routines are compiled, and ?type states:

The simplest types are the surface types. These are generally defined in the Maple kernel, and represent superficial or top-level properties of expressions.

and ?type/surface states:

Most of the system types are surface types since these are encoded in the top node of the expression tree. Thus
type({ .. }, set);
type([a] + [b,c], algebraic);
Both return true regardless of the types of the components of the set in the first case, and regardless of the types of the terms of the sum in the second.

So, it sounds like surface types are static.

And may be that this concept of static types could be stretched to some types defined in the standard library. E.g. container types like type/Matrix, independent of the values asigned to the objects they contain.

Now, names are not declared a static type, and their types will depend on what was assigned to them. However, protected names, in particular system ones, have a fixed value as long as the protection holds. Can their types also be labeled as static?

So, something like the rest would be purely dynamic types. But I do not understand what do you mean by the statement that their system is Turing-complete. Something like a universal Turing machine can be simulated by Maple type routines alone?

And I wonder about the actual comparison method that allows saying that A is more strongly typed than B.

Another problem in the simplification is that the two-argument arctan is not automatically normalized by the symmetry arctan(-b,a) = -arctan(b,a) that holds when -Pi < arctan(b, a) < Pi, and corresponds to the reflexion by the real axis. Apparently, this transformation is neither implemented in simplify nor FunctionAdvisor. This transformation is implemented only by pieces, and in terms of the single-argument arctan:

arctan(-b,a) assuming a>0,b::real;
                             -arctan(b/a)

arctan(-b,a) assuming a<=0,Or(b<0,b>0);
                     -arctan(b/a) - signum(b) Pi

The sign normalization is handled by arctan/normal for the single-argument arctan:

`arctan/normal`(-b);
                              -arctan(b)

but this routine has not been adapted to the two-argument case. So, it seems that at present this transformation has to be introduced by hand:

evalc((a+b*I)^k+(a-b*I)^k):
collect(%,exp):
subs(arctan(-b,a)=-arctan(b,a),%):
simplify(%);
                     2    2 (k/2)
                 2 (a  + b )      cos(k arctan(b, a))

Another problem in the simplification is that the two-argument arctan is not automatically normalized by the symmetry arctan(-b,a) = -arctan(b,a) that holds when -Pi < arctan(b, a) < Pi, and corresponds to the reflexion by the real axis. Apparently, this transformation is neither implemented in simplify nor FunctionAdvisor. This transformation is implemented only by pieces, and in terms of the single-argument arctan:

arctan(-b,a) assuming a>0,b::real;
                             -arctan(b/a)

arctan(-b,a) assuming a<=0,Or(b<0,b>0);
                     -arctan(b/a) - signum(b) Pi

The sign normalization is handled by arctan/normal for the single-argument arctan:

`arctan/normal`(-b);
                              -arctan(b)

but this routine has not been adapted to the two-argument case. So, it seems that at present this transformation has to be introduced by hand:

evalc((a+b*I)^k+(a-b*I)^k):
collect(%,exp):
subs(arctan(-b,a)=-arctan(b,a),%):
simplify(%);
                     2    2 (k/2)
                 2 (a  + b )      cos(k arctan(b, a))

Your code is an interesting step towards the objective of inspecting dependencies.

I wonder why you have chosen to descend 2 levels in the search, i.e. why not 1 or 3 say. Is is just heuristics? Or because the results more or less match the corresponding information available in the internal documentation? (I am assuming that such documentation about which routines are assumptions aware exist, and in fact I think that it should be public).

By the way, the list in ?simplify seems quite outdated as the output of

LibraryTools:-PrefixMatch("simplify");

contains 280 items in Maple 13.01. May be that many of them are just auxiliary routines, but something like a fourth of them do not seem so (and in fact the list in ?simplify,details contains 19 items).

Your code is an interesting step towards the objective of inspecting dependencies.

I wonder why you have chosen to descend 2 levels in the search, i.e. why not 1 or 3 say. Is is just heuristics? Or because the results more or less match the corresponding information available in the internal documentation? (I am assuming that such documentation about which routines are assumptions aware exist, and in fact I think that it should be public).

By the way, the list in ?simplify seems quite outdated as the output of

LibraryTools:-PrefixMatch("simplify");

contains 280 items in Maple 13.01. May be that many of them are just auxiliary routines, but something like a fourth of them do not seem so (and in fact the list in ?simplify,details contains 19 items).

As said, some threads suddenly deviate into new topics, occasionally much more interesting than the original one. Or even branch into several distinct subthreads. And, as just replying is much easier than starting a new thread, that is what most posters do. So, somewhat confusing threads arise, occasionally with valuable material somewhere inside.

In my opinion, it would be great a  facility for moving such thread sections into new "single topic" threads.