If I remember correctly, you posted this somewhere else ... Anyway, the reply I gave: this is a weakness in asympt, not in FunctionAdvisor. So try asympt(EllipticE(z, k), k) and you see where the time is taken.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Hi

It helps if you could please post the worksheet (note also that the images with formulas are not visible).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@vv 

What you got from Maple is what you asked to it. Look closer: when g is a rigid instruction mapping as the one you posted 

g := a -> int(f(x+a),x=a..2*a) 

by entering g(x) you can only expect the letter a replaced by the letter x, regardless of mathematics. You entered a programming instruction (the arrow operator). Anything else in the output different from replacing a by x would be just wrong, a corruption of the programming language.

Now, if what you wanted is what you refer to as 'mathematically correct substitution', then the g procedure you use should have been written differently, for instance as in

g := a -> eval(int(f(x+_a), x = a .. 2*a), _a = a)

so that eval could take care of the 'mathematically correct substitution' you expect, precisely because eval is the command that takes into account mathematical meaning at the time of making substitutions, instead of performing rigid blind substitutions (as subs or the mapping g that you posted do). 

Hope this clarifies your question?

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft
Editor, Computer Physics Communications

Hi, I'm not an expert in this but, in view that to post you need to open an account first, wouldn't a Captcha (http://www.captcha.net) at the time of opening an account resolve most if not all of this issue? 

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft
Editor, Computer Physics Communications

@mskalsi 

Use instead casesplit(DetSys, [{xi, tau, phi}, f]). Again, give a look at the help page for casesplit; there you will find useful details on how to rank the functions (e.g. so that you also obtain a splitting into cases w.r.t f(u) including the related constraint equations for it), work with parameters, etc.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@mehdi jafari 

The Physics package is a large one, it has 67 commands, one of which - Physics:-Library - is actually a programming library specialized in physics with other 151 commands, one of which - Library:-PhysicsType - is actually a package of types specialized for programming in physics with 81 types. One of these type is 'Tensor'.

So suppose you define some coordinate system as when entering Coordinates(X). Then entering type(d_[mu](psi(X)), Library:-PhysicsType:-Tensor) returns true. Likewise, if you Define(A[mu]) (i.e. define A to represent a tensor) then type(A[mu], Library:-PhysicsType:-Tensor) returns true, while the same for B[mu] returns false because B[mu] is not defined as a tensor (so being indexed is not sufficient to be a tensor). Etc.

From the number of Physics commands, programming commands in its Library, and types in its PhysicsType subpackage, you realize that using the Physics framework requires giving a look at the documentation. All the above is documented. Check D_ for covariant derivative, the page for d_, and the page for Physics:-Library, and within there how to list the Physics types. The help page for Physics,Examples has a section on tensors and relativity that can jump-start you. All the tensor notation in the context of the Physics package is indicial. There are commands to work with tensor components and also with abstract tensorial expressions (i.e. involving A[mu], not just its components).

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@mehdi jafari 

Of course there are things I am not aware of, but I am aware of this one. The thing is, however, and at the same time easy and difficult to understand, that a computer algebra system is something alive, as alive as it can get, changing and growing every single day in many many directions. So, there will always - just always - be too many things to be done, and yet a finite number of people working on them. It requires a pretty "zen" attitude to see the big picture (which is also never the whole picture) and remain calm, just prioritizing things in some way (which is also never perfectly done). I'm not sure I am passing well the idea ... nor whether you are open to think about this outside of the framework of "what you want". Anyway.

Having said all that, it is true as well - of course - that prioritizing in software is something directly related to listening to people (which nevertheless not always say things that sound reasonable). And I personally worked in making various functions sensitive to assumptions years ago (GAMMA, pochhammer and the Ei functions are but a few examples from the top of my head). And in this exact moment, I am deeply involved in developing more "Mathematical Functions" stuff (upcoming post in Appell double hypergeometric functions in a few days ...). If I find some time I will see that more mathematical functions - starting with the elementary ones - take into account assumptions on their arguments.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft
Editor, Computer Physics Communications

@Preben Alsholm 

Yes, simplify with assume equality is not eval, but the issue here is another one. Try for instance GAMMA(a+b+c) assuming a+b+c = 0 and you see it working as eval. Why the difference? Because some functions test the their arguments for assumptions and others don't - GAMMA does, exp doesn't. In principle, all of them should test for assumptions on their parameters before returning, and if exp were doing that we would have exp(a+b+c) assuming a+b+c = 0 returning 1.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical functions, Maplesoft

"... when destroying all quantum operators, the pre-defined commutation rules still apply, which should not be the case."

Indeed, the mechanism for removing hanging algebra rules after removing previous definitions of quantum operators had a problem in the case of tensor quantum operators. Nicely spotted Pascal!

As usual, the fix is available to everybody in the Maplesoft R&D Physics webpage.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

PS: I see also that your post doesn't quite fit within the Mapleprimes framework, I need to scroll horizontally in order to read a whole line. You can fix this by setting your Maple preferences (options) -> Export -> Math linebreakingwidth to 6.5. Then, when you post a worksheet, the wrapping will happen within the Mapleprimes framework.

@PhysicsTom 

What is the version of Maple you are using? Under Product, you posted Maple 2015, but I tried now with it and it works fine, although the first line, defining 'g' in terms of 'A Y Y' takes too much time also in Maple 2016 - that deserves a closer look this week; but as said the rest works fine.

Note the day after: the reason it takes time defining 'g' in terms of 'A Y Y' is that 'A Y Y' involves 260 symbolic constants (the components of A[mu, nu, alpha, beta]) and, when you define 'g' (the metric), the defining process in this particular case involves computing the determinant and the inverse of 'g', then simplifying the result 'in size', and all that is what takes time due to the large size of the expressions involved. I'll adjust the option to set the tensor simplifier (Setup(tensorsimplifier) in Maple 2016 + R&D Physics library) to handle this situation more efficiently.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Bachatero 

The update for the Physics package is distributed in the  Maplesoft R&D Physics webpage. There, below the "Download the research version of Physics", you read a date; in this moment: "Files updated on July 28, 2016", and the first zip, Physics.zip is for Maple 2016. There you also have the latest update for Maple 2015 (that includes most of the Physics developments done for Maple 2016) and the latest update for Maple 18 (that includes most of the Physics developments for Maple 2015).

I heard of some people having trouble with this page in connection with caches in the browsers - maybe that is the problem you experienced? If so try flushing the cache, or with a different browser.

Best

Edgardo

@Bachatero 

Sorry that I can't help with that. Unfortunately, it is very difficult to fix things retroactively, ie to make a fix work also for previous releases. The issue is that every package - in this case Physics - changes in sync with (relying on) other changes that happen in the library. Making a fix work retroactively thus would require also change the old library in other parts, which in turn would require making more changes in more other parts, etc. It is almost impossible.

Having said that, you can install the Physics update for Maple 2016 in a Maple 2015 installation, and many things will work (all those not relying on other changes). So depending on the computation you want to do, you may want to try - just be aware that some things will behave unexpectedly strange or just won't work.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.
Editor, Computer Physics Communications

@Bachatero 

So, now d_[mu](Dagger(Phi(X)) returns in terms of diff whenever mu is a numerical index, covariant or contravariant, and regardless of whether the spacetime is flat or curved.

As usual, the adjusted Physics library is available for download to everybody at the Maplesoft R&D Physics webpage, and only works in Maple 2016.

In case you are curious, the underlying issue: although with paper and pencil Dagger(Phi) or conjugate(Phi) is not a composite function, the computer algebra representation is, and so the code needs to decide (conventionally) on a canonical form (say diff@Dagger or Dagger@diff), an issue that of course does not exist with paper and pencil. In connection with that convention, d_ was returning without proceeding further to avoid contradicting it. In the case of a numerical index, however, the computation can be performed to the end regardless of that convention so there is no point in holding the computation.

By the way: there are no "programmer boys" at Maplesoft. Unless you want to call me a boy :) :) :) If the Physics package were stuff that could be done by programmers without understanding of the mathematical methods used in physics, we would probably have had it in place and finished a long time ago, and also in the competition, where still today nothing even partially similar exists. Somehow the same is the story of the Maple differential equation programs, the FunctionAdvisor, and of some newer special functions, the conversion network for mathematical functions, the assuming command, etc. No programmer boys.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.
Editor, Computer Physics Communications

@Bachatero 

This is a different problem, not related to the display of Phi(X) instead of the expected Phi, but about the design: why d_[1](Phi(X)) is automatically converted to diff but not d_[1](Dagger(Phi(X))). I will revise this and write here again.

And thanks for pointing to these issues. One thing is to put code together, another entirely different is to have the feedback that permits polishing this code again and again, as much as necessary.

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Bachatero 

You are correct - I will give a look at this and write again here soon.

Edgardo S. Cheb-Terrab 
Physics, Differential Equations and Mathematical Functions, Maplesoft