@acer 

It could be an oversight, or it could be as designed, e.g. to keep "contagiated" expressions with powers of algebraic numbers in a "simpler" form, involving only sums and products. Without access to the specifications of this design, little could be said on what is the expected behavior after them.

@acer 

It could be an oversight, or it could be as designed, e.g. to keep "contagiated" expressions with powers of algebraic numbers in a "simpler" form, involving only sums and products. Without access to the specifications of this design, little could be said on what is the expected behavior after them.

I hate both, but I think that the '(2^(1/2))^29.403243784' result is a combination of automatic simplification plus floating-point contagion.

I hate both, but I think that the '(2^(1/2))^29.403243784' result is a combination of automatic simplification plus floating-point contagion.

@Carl Love 

Perhaps not useful programatically, but somehow, the interface does catch a warning comming stright from the kernel as in your example, because no warning message is issued here:

interface(warnlevel=0):
proc() option builtin= 1; end proc:

It might be enough if the interface, at catching, writes to an environment variable, or a stream, say.

Another route, quite hackish, would be listening to the localhost TCP stream of the conversation between the kernel and the interface. E.g. for this example, the message from the kernel containing the warning looks like:

.....WARN....+6%""#Q?not~a~built-in~function~(`%1`)6"""".

@Carl Love 

Perhaps not useful programatically, but somehow, the interface does catch a warning comming stright from the kernel as in your example, because no warning message is issued here:

interface(warnlevel=0):
proc() option builtin= 1; end proc:

It might be enough if the interface, at catching, writes to an environment variable, or a stream, say.

Another route, quite hackish, would be listening to the localhost TCP stream of the conversation between the kernel and the interface. E.g. for this example, the message from the kernel containing the warning looks like:

.....WARN....+6%""#Q?not~a~built-in~function~(`%1`)6"""".

@Carl Love 

INTERFACE_WARN is actually a "stream". Streams are somewhat documented e.g. in ?OpenMaple,C,streamCallBack (not the most obvious place, in my opinion). So, as I understand it, it is an interface routine (rather than a library or kernel one), and not surprisingly its output depends on the interface being used. For example, the Maple 17 CLI does not lose connection to the kernel (as Classic and Standard do), but issues an error message:

> print(INTERFACE_WARN(1,"Hello"));
Warning, Hello
> print(INTERFACE_WARN());
Error, invalid WARNING structure
> streamcall(INTERFACE_WARN());
Error, invalid WARNING structure
> INTERFACE_WARN();
Error, invalid WARNING structure

Idem back to Maple 11.02.

This means also that a warning message could have its origin purely in the interface (possibly faking as coming from elsewhere). For instance, in Standard GUI you get:

> streamcall(INTERFACE_WARN(solve,"I cannot solve"));
Warning, (in solve) I cannot solve

While the same input produces an error message in the CLI:

> streamcall(INTERFACE_WARN(solve,"I cannot solve"));
Error, (in solve) invalid WARNING structure 

Even when it gets a WARN message from the kernel (cf. below).

@Carl Love 

INTERFACE_WARN is actually a "stream". Streams are somewhat documented e.g. in ?OpenMaple,C,streamCallBack (not the most obvious place, in my opinion). So, as I understand it, it is an interface routine (rather than a library or kernel one), and not surprisingly its output depends on the interface being used. For example, the Maple 17 CLI does not lose connection to the kernel (as Classic and Standard do), but issues an error message:

> print(INTERFACE_WARN(1,"Hello"));
Warning, Hello
> print(INTERFACE_WARN());
Error, invalid WARNING structure
> streamcall(INTERFACE_WARN());
Error, invalid WARNING structure
> INTERFACE_WARN();
Error, invalid WARNING structure

Idem back to Maple 11.02.

This means also that a warning message could have its origin purely in the interface (possibly faking as coming from elsewhere). For instance, in Standard GUI you get:

> streamcall(INTERFACE_WARN(solve,"I cannot solve"));
Warning, (in solve) I cannot solve

While the same input produces an error message in the CLI:

> streamcall(INTERFACE_WARN(solve,"I cannot solve"));
Error, (in solve) invalid WARNING structure 

Even when it gets a WARN message from the kernel (cf. below).

@ecterrab 

I think that we are converging to an agreement. Let me quote:

You compute. Things are displayed. Not as you input them. There are then two different processes happening.

...the same approach can be used to have the display of v_satellite^2 be the same as that of v[satellite]^2, while you continue computing with v_satellite^2

This is precisely the concept of a pair of expressions (computational , typesetting) that I have written above, in my first reply to Erik.

This tells that what Erik is asking is perfectly doable in current Maple. Not by you because you do not have access to the display of powers, but yes by the people who do have access in case they agree with Erik's suggestion.

This is the point, you say that it is "doable", but it is not done. So, let us hope that the people who do have access will agree implementing it.

@ecterrab 

OK. I agree that Typesetting:-mcomplete looks like an interesting proof of concept (though I have not looked at it yet in enough detail). However, my understanding of Erik's request was that he wants also computing (besides mathematically correct typesetting). E.g. solving for v__satellite in terms of the potential energy and the total mecanical energy,  as in typical elementary mechanics problems. So, if my understanding of his request is correct, the side of the connection with the kernel is still pending.

@acer 

A bit of history here.

@acer 

A bit of history here.

Variable names begining with & are being used for TypeMK names, following the convention for MathML entities. For instance `φ` which typesets φ.

Variable names begining with & are being used for TypeMK names, following the convention for MathML entities. For instance `φ` which typesets φ.

@leaky 

I think that it would be more constructive to write a good procedure for un-rationalizing (rather than go with long strings of nested commands and inverses). Something along this sketch:

unrat:=proc(ex::`&under`(radical,numer))
local n:=numer(ex),d:=denom(ex):
op(0,n)(normal(op(1,n)/d),op(2,n))/d^(1-op(2,n));
end proc:

f:=sqrt(2*x+2)/(x+1):
unrat(f);

                                       1/2
                                      2
                                   ----------
                                          1/2
                                   (x + 1)

Care has to be taken on the validity of the operations.