Hi
Thanks for pointing this out, this is indeed a bug, and it is now fixed. The fix is available for download for everyone at the Maplesoft R&D Differential Equations and Special Functions webpage (the special functions updates are bundled with the Physics updates).

By the way, I didn't try the Mathematica app you mention but if it evaluates this to 311/312, that result is wrong. The correct result is the one mentioned by Preben Alsholm: 71/72.

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

@John Fredsted 
Where is Physics:-`^` used in your question? What copy and paste are you referring to? Generally speaking: a) yes, Physics:-`^` is used when you enter powers, because there may be noncommutative operands at play, but as soon as the command detects they are not present, it returns the power expressed using :-`^`, that is the standard power operator that only handles commutative operands, so it is not expected to appear in the output of a GR computation (unless you use noncommutative operands ...) nor in the output of copy and paste, unless you are delaying the power surrounding  with quotes, as in 'A^B' or the like.

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

@deniscr 
I thought your question was about how to enter the parameter E: it is TransformTetrads who enters the parameter, it uses the letter E, and if E is already in use it uses E__1, if it is in use it uses E__2, and so on.
If your question is about "how to give E a value after it was entered in the worksheet by TransformTetrads", the answer is to use the subs or the eval commands, as in subs(E = 5, <here you refer to the output_of_TransformTetrads for instance using `%` or the equation number>), or eval with the same arguments swapped, or just assign E := 5 and use the output of TransformTetrads that automatically will take E = 5.

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

@illuminates 

Psigma[mu] is a tensor (4-vector), you can work with it as with any other tensor, and if uppercaselatin represents spacetime indices and you defined p as a tensor (Define(p)), then Psigma[A] p[A] is a valid tensorial expression with contracted indices. Try for instance SumOverRepeatedIndices(Psigma[A] p[A]) and you see the four Pauli matrices around

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

@illuminates 
In the help, search for 'labels' and you will see the third entry is about equation labels; scan the page with your eyes looking for enumerated items, the one with number 3 is the answer to your question: use Ctrl + L (or Command+L in the mac) to open a window where you write the number (not the opening and closing parenthesis - just the number), then press enter and in that way you insert an equation label. I find these equation labels one of the best features of the Maple GUI.

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

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