@Alejandro Jakubi as said in this and another thread this problem is fixed. But you are suggesting something else. Note that in the output you show by simplify/size you have w * conjugate(w) -- that is a non-simplified product, and as such it is not good as output of a simplify command. The output after the fix in fact is as the one you show by simplify/size but with that w * conjugate(w) also simplified.

Besides that there is simplify/size itself being discovered. To have in mind: when writing it tried thoroughly to avoid performing any mathematical operation - nothing - only collect coefficients (including of frozen subexpressions) and at most decomposition of fractional powers, that can be done fast. Anything else would ruin the performance of this wonderful routine, that was originally developed for, and is systematically in use in all the Maple DE, Physics and MathematicalFunctions code, and it is not used by simplify by default only because of backwards compatibility debates.  

And one idea to keep in mind: wouldn't it be beautiful if *every* output, not just the one of simplify, would always be preprocessed with simplify/size? Exception made only (from the top of my head) of the output of collect, factor and expand. I am talking of a kind of a setting. One that you could turn ON/OFF optionally, say as simply as typing > on;, or >off; and voila the thing activated/deactivated :) No? :) I think so, and work everyday with this feature implemented - it becomes addictive. At every release I consider adding it to the system. Perhaps ... It would need some tunning but mostly facing a significant break with so many years of (for me boring or frequently wallpaper) computer algebra output.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
The comparison you mention consists of mainly 3 pages, of which less than 1/2 is about mathematical features (starting at 'Graph theory' and finishing at 'Cayley tables'), so to begin with there are obvious and significant omissions.

To mention but a few in areas I am more familiar with, the new Maple 17 functionality in Physics, Differential Equations and Differential Geometry - not mentioned at all in the comparison - is not only not available in Mathematica 9 or previous ones, but it is also probably 5 to 10 years of development ahead of what you see in Mathematica. This is the opposite of what is claimed in that comparison advertisement. Moreover, this distance is favorable to Maple, consistently, since year 2000, and consistently increasing every year. For Differential Equations the difference started shockingly (that is the word) in 1997 at least and Mathematica just never recovered.

Independent of these stark omissions, regarding the half page of mathematics that is mentioned in that comparison, either the person who wrote it does not understand the topics, or distorted the facts.

For example, quoting literally from this comparison you mention, it says that Maple 17: "a) introduced Visualization: visualize branch cuts, b) this Maple's functionality is not equivalent to Mathematica's automatic branch cut detection—it allows you to request a visualization of the branch cuts of individual functions but does not detect branch cuts in functions that you try to plot, c) that Mathematica introduced this in 2007". Statement c) is supposed to indicate that Mathematica introduced this functionality before Maple.

Both statements a) and b) about Maple are incorrect and the implication of statement c) is false.

Maple introduced visualization of cuts with its plots:-plotcompare not in Maple 17 but already in 2002, so 5 years before Mathematica and in a way still not seen in Mathematica 9; the Maple visualization is not restricted to cuts of individual functions, and of course the Maple plotting routines detect the branch cuts of the expressions you try to plot. See for instance the examples in the help page for ?plotcompare. But more important, Maple 17: a) introduced *algebraic representations* for the branch cuts of *algebraic expressions* not just individual functions, and this functionality does not exist at all in Mathematica - in fact it is new research work, see references in ?FunctionAdvisor,branch_cuts - and b) Maple introduced *algebraic representations* for branch cuts of individual functions already in 2003, with the FunctionAdvisor project, and neither those algebraic representations for the cuts even of individual functions, nor anything like the FunctionAdvisor project, ever existed in Mathematica, also not in the new Mathematica 9.

You see ...

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This one actually got fixed June/19 before you posted. The problem you mention is the same one mentioned in http://www.mapleprimes.com/questions/148559-Problem-With-Code-Calculation-In-Maple-17 (I gave some details there). In short, simplify/conjugate, a very old routine (previous to 1994), got entirely rewritten.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Carl,
There is a line (showstat(`simplify/conjugate`, 11)), in place since 1994 as far as I can see, that is problematic in that it introduces significant algebraic complication (see reply by Alejandro) while trying to simplify f*conjugate(f) = abs(f)^2. Until Maple 15 inclusive, the result of that attempt was discarded whenever it didn't result in 'less conjugate(..)' around, and thus the algebraic complication it would introduce was not noticed. But then the logic underlying these lines 11 to 13 fails in an example like f*conjugate(f) + conjugate(f), where replacing the first term by abs(f)^2 does not lead to 'less conjugate(..)' around - you still have conjugate(f); this got fixed in Maple 16, but then the result of this line 11 not always ends discarded in M16 till today ... and then you have the snow ball I see with the example posted in this thread. Of course the problem is that line 11..13 in that  the simplification f*conjugate(f) -> abs(f)^2 can be done more economically and avoiding these algebraic swelling problems. It is easy to fix. Unfortunately I do not see a workaround for you without editting the code. I am not sure the fix can still go into 17.01.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Carl,
There is a line (showstat(`simplify/conjugate`, 11)), in place since 1994 as far as I can see, that is problematic in that it introduces significant algebraic complication (see reply by Alejandro) while trying to simplify f*conjugate(f) = abs(f)^2. Until Maple 15 inclusive, the result of that attempt was discarded whenever it didn't result in 'less conjugate(..)' around, and thus the algebraic complication it would introduce was not noticed. But then the logic underlying these lines 11 to 13 fails in an example like f*conjugate(f) + conjugate(f), where replacing the first term by abs(f)^2 does not lead to 'less conjugate(..)' around - you still have conjugate(f); this got fixed in Maple 16, but then the result of this line 11 not always ends discarded in M16 till today ... and then you have the snow ball I see with the example posted in this thread. Of course the problem is that line 11..13 in that  the simplification f*conjugate(f) -> abs(f)^2 can be done more economically and avoiding these algebraic swelling problems. It is easy to fix. Unfortunately I do not see a workaround for you without editting the code. I am not sure the fix can still go into 17.01.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

dsolve has a number of optional arguments that may be of use for you, among others: useInt (instead of int) to avoid computing the integrals entering the solution (that may result in a LambertW function), or 'implicit', to avoid solving for y the implicit form of the solution (solving may result in LambertW). See ?dsolve,details; other times choosing the solving method as explained in that page may also help, typically for nonlinear higher order equations.

So for instance regarding your example, x-y/y' = y, try dsolve(ode, implicit) and you receive x - (_C1 - ln(y)) y = 0.

 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro Jakubi You compute. Things are displayed. Not as you input them. There are then two different processes happening. In Maple, part of the display (typesetting) is also implemented at library level, as if it were a computation. That doesn't mean you compute with display, hey! It also doesn't mean that there would be some kernel connection missing as you suggest.

The idea is simple though. Here is an example of something working in Maple 17:

> PDEtools:-declare(A(x,y));
             A(x, y) will now be displayed as A

> A(x,y);
                                    A

So you input A(x, y) and it is displayed as A. Is the above equal to A or A(x, y)? Check it with lprint

> lprint(%);
                                  A(x, y)

So the display is one thing, and the object behind this display is another one. Now, you compute with the object behind, not with the display, of course, so if you input > %; it refers to A(x, y), not to the letter A with no dependency.

This display is implemented at library level, as a "computation", in Maple language. Hence you can reproduce the display itself, without the object behind it. How? In this case invoking the print/A function that produces it

> `print/A`(x, y);
                                    A

Note that this time there is no object behind, it is pure display:

> lprint(%);
Typesetting:-mcomplete(Typesetting:-mi("A"), Typesetting:-mrow(Typesetting:-mi("A"), Typesetting:-mo("⁡"), Typesetting:-mfenced(Typesetting:-mi("x"), Typesetting:-mi("y"))))

Of course you do not intend to compute with display. And why not just 'A' for output of `print/A`? Because we want copy and paste working. That is what mcomplete provides within display: if you mark the A returned by `print/A`(x, y) above, copy, and paste into a new line, you receive A(x, y), not A nor the Typesetting structure.

Summaryzing: 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 (there is no kernel connetion missing whatsover). Implementing this with mcomplete resolves the copy and paste issue. 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.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 

 

 

 

prevent to continue computing with the object that is behind that input, of course.  

@Alejandro Jakubi Note I am saying "this approach could be implemented within Typesetting for the purpose of having powers of the new subscripted atomic variables displayed more correctly". I.e.: display. See how a Physics:-Ket displays and no, you do not compute with the display. Within Typesetting, also within the old print/foo, the display is totally independent of the object being displayed. That is why copy & paste doesn't work with print/foo: you paste "display". But now with Typesetting:-mcomplete - an internal mechanism, not documented for that reason, subject to changes in next releases, etc. still, it is a proof of concept that there is an easy way to resolve the issue posted already in Maple 17.0x.

I do not advertise unimplemented features - doesn't matter to me what Wolfram does, neither I see him as the paradigm; nor I think he really advertise unimplemented features ... but that is to the side, a topic I'm not interested enough to spend time on it. PrintTools is just a natural thing to think to address the limitations of print/foo after the advent of TypeTools addressing the equivalent problem regarding type/foo. ExpandTools, SimplifyTools, etc. But all these were mentioned other times as well by other people.

Anyway, until the limitations of `command/foo` are addressed, we can still use them for what they do well, and in the case of `print/foo` use it with mcomplete to provide the copy and paste functionality.

Regarding development with constant user feedback: the idea is old and many of use think that is good, but the exact implementation of it is not straightforward. Anyway, MaplePrimes - and now it seems we have a moderator that helps - is a forum that can be used concretely for this purpose of a collaborative developing environment. You need to have in mind however that if we are going to reply to all the different opinions expressed and derivations of them (e.g. in this thread) we would - honestly - have little time to do any development.


Edgardo S. Cheb-Terrab
Physics, Maplesoft

@erik10 There are ways of doing this, more than one, though the internal mechanisms for typesetting, as most internal mechanisms, are not documented. Here is one of them that works fine in Maple 17: enter 

> Typesetting:-mcomplete(Typesetting:-Typeset(v[satellite]^2), Typesetting:-Typeset(v__satellite^2));

                     ... display is as the one for v[satellite]^2 ....

Try now copy and paste: you receive v__satellite^2 as desired. So, for instance, this approach could be implemented within Typesetting for the purpose of having powers of the new subscripted atomic variables displayed more correctly, as it is the case of powers of the old indexed variables. 

By the way the print/foo mechanism already uses Typesetting:-mcomplete for similar purposes in a number of places (e.g. in DifferentialGeometry and Physics) and in this way also providing correct copy & paste, that doesn't work with print/foo otherwise. (Independent of that, print/foo would be conveniently replaced by something analogous to the TypeTools package - would be a sort of PrintTools ... and in doing so one could address more general display requests than just functions as print/foo does.)

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 

 

Hi

In order to help you - could you please post the example that produced that error message?

Edgardo S. Cheb-Terrab

Physics, Maplesoft

 

@acer: Yes, it could be done, as Alejandro says, and if that were done it would by coding the formulas in the conversion network (the real core place where math function relations are currently coded) and making Beta call this network, as it is done in other math functions implemented more recently.

So we are again facing step one: this knowledge is not properly placed in the library in this moment - that is what needs to be done in the first place.

And then, as Alejandro recalls, I mentioned other times that there is a non-resolved issue, inherited, about when would a math function should return its special cases (all? some? which? none?). Depending on the function and the computation you are doing, you may or may not want these special cases automatically returned. The problem is still tackable (not perfectly, but reasonably) - I proposed a plan in 1999, but the attempts to do that collided with varied obstacles. At this point, when more people are more open to radical changes removing old remoras, perhaps it's just a matter of taking action. And still there is this other issue about time, combined with amount of people working in the so-many-projects and the will-always-be-imperfect mechanism for prioritizing things.

One step at a time. Fixing the conversion network is easy. Taking advantage of that, fixing the simplify subroutines to work properly is also easy. At that point, I'd say that the whole "math functions versus special cases" thing is still not a top priority if compared with so many other things requiring attention. BTW the `is` thing is still another issue - reporting things directly as bugs when you think so, definitely helps. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Just revising this old post - the simplification weaknesses you mentioned were fixed - things work as expected in Maple 16.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Just revising this old post, but for item 2), in Maple 16 everything works as you mentioned in your original post, that is:

1) " Both covariant and contravariant indices … ": In Maple 16, contravariant indices were introduced, entered prefixed by ~, and displayed as superscripts. 

2) "The package needs multiple types of independent indices within a given spacetime … ": This is not according to the design of the package, where there is only one kind of spacetime indices, but can be implemented as gauge indices that behave as spacetime ones; not in place yet.

3) "Lot more examples are needed to denote the use of X and Y spacetimes … ": These examples are in the page ?Physics,Examples.

4) "The metric tensor can be defined only in Euclidean and Pseudo-Euclidean spacetimes … ": Not anymore -- in Maple 16 you can work with general/arbitrary curved spacetime metrics. In connection, Christoffel symbols and related commands were added to  Physics.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Just checking these old posts - 1), 2) and 3) work fine, as expected, in Maple 16

Edgardo S. Cheb-Terrab

Physics, Maplesoft

Just to note that despite the non-polynomial objects found in 'eqs', both kinds of exact solutions (independent or dependent on t) exist for this problem. Here is one solution and its verification for all variables independent of t: > simplify(eval(sys, {B = 1, a = 0, b = b, g = 1, k = RootOf(2*_Z^2+1), w = w})); {0 = 0} Here is one solution allowing for instance w to depend on t: > simplify(eval(sys, {B = -1/2, a = 1/2, b = b, g = -1/2, k = k, w = 1/3*(3*ln(t)+6*ln(2)+2*ln(-k^2/(-6*t-6*t^(-1/2*b+1)+6*b*t^(-1/2*b+1)+1)))/ln(t)})); {0 = 0} I noticed yet another one with b and w depending on t but its verification is not straightforward: {B = -1/2, a = 1/8/t^(1/2), b = 2*(-1+4*t^(1/2))*LambertW(-ln(t)*g*(8*t-t^(1/2)-16*t^(3/2))*(8*g*t^(1/ 2)+3-8*t^(1/2))*t^g/(192*t^2-144*t^(3/2)+36*t-3*t^(1/2)))*(8*g*t^(1/2) +3-8*t^(1/2))*t^(3/2)/(3*t+8*g*t^(3/2)-8*t^(3/2))/ln(t)/(t^(1/2)-4*t), g = g, k = k, w = 1/3*(8*t^(1/2)*ln((-1+4*t^(1/2))*(8*t-t^(1/2)-16*t^(3/2))*(8*g*t^(1/2) +3-8*t^(1/2))*k^2*t^(g+2)*ln(t)*g/(((768+3072*g^2-6656*g)*t^(11/2+g)+( -480*g+64*g^2+288)*t^(9/2+g)+3*t^(g+7/2)-768*t^(11/2)-3*t^(7/2)-288*t^ (9/2)+(-768-768*g^2+2688*g)*t^(5+g)+(32*g-48)*t^(4+g)+(-4096*g^2+6144* g)*t^(6+g)+768*t^5+48*t^4)*LambertW(-ln(t)*g*(8*t-t^(1/2)-16*t^(3/2))* (8*g*t^(1/2)+3-8*t^(1/2))*t^g/(192*t^2-144*t^(3/2)+36*t-3*t^(1/2)))+8* ((-64*g+64)*t^(11/2+g)+(-12*g+30)*t^(9/2+g)+3/8*t^(g+7/2)+(-72+48*g)*t ^(5+g)+(-11/2+g)*t^(4+g))*ln(t)*g))-8*LambertW(-ln(t)*g*(8*t-t^(1/2)-1 6*t^(3/2))*(8*g*t^(1/2)+3-8*t^(1/2))*t^g/(192*t^2-144*t^(3/2)+36*t-3*t ^(1/2)))*t^(1/2)+(32*ln(t)+48*ln(2)-8*ln(3))*t^(1/2)-3*ln(t))/ln(t)}

Edgardo S. Cheb-Terrab
Physics, Maplesoft