@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

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

Hi Without the actual input that resuls in 10 min evaluation it is not possible to say what the problem could be. How about you post the worksheet that contains all the input lines?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Without the actual input that resuls in 10 min evaluation it is not possible to say what the problem could be. How about you post the worksheet that contains all the input lines?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Junji Regarding 1.: in > phi[a,b](X)*phi[alpha,d](X)*g_[e,a]*LeviCivita[e,f,alpha,d]: you have phi[alpha, d]. According to what you have set (see your post), alpha is a spacetime index but not d. In maple the notation [a,b] is used to index objects, not necessarily to represent spacetime tensors, so both indexations (spacetime and whatever else) can be represented. As we do it by hand, the idea is then that you set a convention to represent spacetime indexes (in your mind, then using Physics:-Setup in the worksheet), and then stick to your convention. But you are using two different types of indices. Trying to understand what is what you had in mind when entering phi[alpha, d] (correct me if I am wrong please) I guess that you intended to use, simultaneously, spacetime and space-only tensor indexes, as we sometimes do with paper and pencil. Unfortunately this functionality (two different kind of tensor indexes handled at the same time) is still not in place. It is in the to-do list of improvements with high priority though. Until that is in place, the error message displayed when you Simplify(%); Error, (in Check) found phi with 1 tensor indices, [alpha], contradicting a previous definition with 2 such indices. You can use Define with the 'clear' or 'redo' options to discard the previous definition. Is correct and according to the documentation. Regarding 2: the issue is a bit more subtle, but easy to understand. In computer algebra systems, some operations are automatically simplified as a way of normalizing things, almost always to permit basic zero recognition. This is not related to the Physics package. For example: if you enter sin(-x) it returns -sin(x). Although for sin(-x) the output is "session independent", in some other cases the output is "session dependent". Therefore, if in a worksheet you have a subs operation acting on session dependent output, if as you say you re-execute the session, that subs line may or not work (Murphy's law applies here ..) because the target of the subs operation may have changed, as you say. Of course this is annoying. But progress is happening: in Maple 12 (elements in a set are returned almost always in the same order) and more in Maple 13 (elements in a list are sorted almost always in the same order). Independent of that, the library code for Physics could be tweaked further (it is already) to try to keep the indexes unchaged as much as possible (provided that there is no relevant impact in performance - note that product operations are verified for consistency on background on the fly). I'll add this example you posted to the todo list. Regarding 3. In handwriting computations it is unclear to me what would be the meaning of A[mu](X)/(d_[mu](A[mu](X),[X])); where I see a dummy repeated two times (all in all the index appears three times). Perhaps you are conventioning (in your mind) that "repeated indexes in the numerator" are considered different than "any indexes in the denominator" (and the same exchanging numerator by denominator)? Until the convention you have in mind is clarified and eventually implemented, the error message is correct and according to the documentation: A[mu](X)/(d_[mu](A[mu](X),[X])); Simplify(%); Error, (in Check) found repeated indices of the denominator in the numerator Regarding 4. This is a weakness bug in the Simplify code, to be fixed.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Edgardo S. Cheb-Terrab
Physics, Maplesoft

You are correct, simplify/Heun is not there. There is a general approach in simplify for special functions though; I'm adding Heun functions there now.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

You are correct, simplify/Heun is not there. There is a general approach in simplify for special functions though; I'm adding Heun functions there now.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This is an implementation oversight - call it bug if you prefer - Heun functions were introduced in the system after the conversion network got developed. The implementation details are tricky but in short: the setup of the network includes knowledge regarding "from which functions" can a conversion exists. For Bessel functions an update telling, that from HeunB and HeunC that conversion is possible, is missing in Maple12 and before.

To make it more concrete: if that information were in place, the network would have found that through pFq it is possible to convert to BesselI; try this convert(HeunB(alpha,0,0,0,z), compose, hypergeom, BesselI); and you see it working. The problem is fixed in the version of Maple under development

Edgardo S. Cheb-Terrab
Physics, Maplesoft