Hi,
Assuming your question is: "Given the components of A_ijmn and C_ij^kl, compute the components of B^mnkl that satisfy A_ijmnB^_mnkl=C_ij^kl", an alternative to Torre's suggestion of using DifferentialGeometry, so using Physics and standard tensor indicial notation instead, is as follows:

1) Define the tensors A_ijmn and C_ij^kl, (see 4th paragraph of ?Physics,Define to define A and C specifying their components as Arrays).

2) Construct your tensor equation the same way you posted, as in eq := A_ijmnB^_mnkl=C_ij^kl and transform this equation into a system of equations for the components of B^_mnkl using Physics:-Library:-TensorComponents(eq), see ?Physics,Library, section for TensorComponents. Call this system of equations sys. The solving variables are the components of B, so vars := Library:-TensorComponents(B^_mnkl).

3) Solve the system the usual way, sol_B := solve(sys, vars)

That is all. The advantage of this approach is that it involves algebraic manipulations using the standard Maple commands and tensorial indicial notation so requiring no additional knowledge. If you have any trouble reproducing these steps please post the example concretely - for that purpose you can upload a worksheet with your reply here in Mapleprimes, and we continue from there.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 PS: where you wrote A_ijmn to represent the covariant components, in Maple you enter A[i,j,m,n]. Contravariant indices are prefixed by ~, say ~j instead of j.

Download DeclareCopyAndPast.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

PS: for some reason some of the output of the uploaded mw appear with "?". In the attached mw things are displayed correctly.

Hi

The simplification of hypergeometric functions is a complicated problem, although computer algebra systems nowadays have powerful algorithms to reduce to a special case involving more famlilar functions *when that is possible*. Of course it is not always possible. Calling your hypergeometric function of pFq, the convert(pFq, StandardFunctions) mentioned by Carl is one way of trying a simpler expression.

There is something more general though: FunctionAdvisor(specialize, pFq). That will give you not only what convert/StandardFunctions can give you but also the different specializations for the parameters within pFq (for instance, your t ) such that the pFq could be rewritten in terms of other functions of all available kinds.

With your example, that is pFq = hypergeom([1/t, 1/t], [(t+1)/t], z), for specialized values of t (these specializations may or not be what you need) I see various equivalent mathematical representations of pFq involving one or many of ChebyshevT, ChebyshevU, GAMMA, HeunC, HeunG, HeunGPrime, JacobiP, LerchPhi, MeijerG, Psi, arccos, arccosh, arccsc, arccsch, arcsec, arcsech, arcsin, arcsinh, arctan, ln, sin.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

Note first that conjugate does not split into Re and Im. It is simplify that, under certain circumstances, splits into Re and Im; and I am saying that your example in this thread shows a case where the splitting is mostly undesired, not really a simplification.

But there are other cases where this splitting into Re and Im by simplify are, generally speaking, understood as a simplification: when occurrences of z and conjugate(z) in an expression can be combined into 1)  only Re(z) in the expression, or 2) only Im(z), or 3) only Re(z)*Im(z) plus reducing the degree of occurrences of conjugate(z). The cases 1) and 2) are more or less natural simplifications. Case 3) is trickier, here is an example:

> conjugate(z)^2 - z^2;

> simplify(%, conjugate);
                                  -4 I Re(z) Im(z)

This output looks to me simpler than the input conjugate(z)^2 - z^2. On top of these considerations, Maple always performed this "simplification" above, regardless of whether some people may prefer to see conjugate(z)^2 - z^2. In a situation like this, changing previous behavior is inconvenient, makes things that worked in previous releases to stop working in the next one.

On the other hand, as said, some 'simpilfications' are really not simplifications - at all - for basically any reasonable person. In situations like these it is of course OK to change the behavior, it becomes an improvement. Your example is in this class, and also I rewrote simplify/conjugate recently. I'm still busy with other stuff but will see soon how the rewritten simplify/conjugate can be tweaked a bit more to do a better job with examples like yours, while keeping previous desired behavior (items 1), 2) and 3) above) working.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download 4Vectors.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Carl Love 

Carl, there is only one definition of integrating factor. "Suppose the equation is of the form ode and has an integrating factor mu: then mu*ode is a total derivative, i.e.: mu ode = d/dx F(y(x), x)". This is also the first sentence you read in the help page ?DEtools[intfactor]

You see you can rewrite mu ode as (mu*f)*(ode/f), and so as soon as you change the form of the equation (now it is ode/f), it also changes the integrating factor (now it is mu*f). That explains the results you see in Maple that you posted above in this thread.

The wikipedia and mathworld articles are weak in that all their examples have the highest derivative isolated (equivalent to multiplying ode by some f such that the coefficient of the highest derivative is equal to 1), which is what seems to have confused you. Note that in the equation posted by "nm" the coefficient of the highest derivative is t^2 - t. 

The fact that you can rewrite the integrating factor of a given ODE in infinitely many manners (I mean: without changing ODE) is easy to understand: suppose you have an expression G(y(x), x) that on the solutions y(x) of your ODE becomes a constant. Then d/dx G(y(x),x) = 0 on the solutions y(x) of ODE. But then if mu ODE is a total derivative, so is mu * G(x, y(x)) * ODE because its d/dx is equal to d/dx G * (mu ODE) + G * d/dx(mu ODE) = 0 + G * d/dx(mu ODE) = 0.

In other words: both mu and mu * G(x, y(x)) are integrating factors of ODE. You know, given y(x) (the solution of ODE) we can write infinitely many functions G(x, y(x)) = constant.

In summary: For any ODE you can write integrating factors in infinitely many diffeerent ways. The output of Maple's intfactor is correct. The integrating factor posted by 'nm' is not correct (it is missing a factor). 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Andriy

Recall there is a difference between `*` and `.`, the latter is used for the scalar product of Bras and Kets and operators, while you can use `*` to represent the operation without computing it. Note also that phi is commutative and you use it as such when performing the product, but afterwards you replace it by a noncommutative object a Ket. That is not a good strategy: the order of the operands gets swapped in this case, normalizing the product taking advantage that 'phi is commutative'.

In summary: before multiplying, enter Setup(op = phi) or Setup(noncommutativeprefix = phi) to state that phi is not commutative, then perform H . phi as you do in your worksheet, then enter eval(H, [phi = Ket(psi, 1, 0, 1, 1, 0, 0), f = 1, `*` = `.`]) (so as you did, but including now the equation `*` = `.`), in order to introduce a Ket replacing phi and perform the scalar product. That resolves your 1st problem.

Regarding your second question: conjugate is present in your H, and split into Re and Im within simplify/conjugate, because in this example that leads to a partial simplification. Although at first sight I would say that partial simplification is just of no value in this case and complicates the expression. Until that is reviewed, I would suggest you replacing conjugate by something else like Conjugate, then perform the scalar product (that is where simplify/conjugate is called), and at the end remove Conjugate reintroducing conjugate. If I tweak simplify/conjugate before that I will let you know but this week I'm rather busy with other stuff.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

What is what you are finding strange in intfactor's result? It is correct: try mutest(intfactor(ode), ode) and it returns zero. You can test this result manually too. Regarding the integrating factor you show, simplify(exp(int( (t^2+2*t-2)/(t^2-t),t))), it is not correct. Multiplying the ODE by it you do not get an exact equation. Try testing it with DEtools[mutest].

Independent of that, note that the integrating factor can depend on as many variables as the differential order plus 1 (all the derivatives up to the ODE order minus one, plus the unknown y(x) and the independent variable x) and as such you can write an integrating factor for an ODE in infinitely many different manners. Some of that is explained in ?DEtools[intfactor] and in ?DEtools[redode] that computes the ODE reducible by a given integrating factor; see also PDEtools[DeterminingPDE] to compute the PDE system satisfied by it.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Andriy 

To avoid having to sort products many times, use the optional argument 'evaluateexpression'. The 'too many levels of recursion' was happening only when assigning to geometrical coordinates (z is part of the cartesian coordinates). When working with Physics:-Vectors, you cannot assign to these coordinates. It is fixed now: if you do not have Vectors loaded, you can assign any of the geometrical coordinates without problem. I just posted a new update in the Maplesoft webpage "Maple Physics: Research & Development" with only this fix.

From your post it remains: 1) why it is not sorting the second A in ABAC - I will revise this in the next iteration, and 2) why do whe have A . A and A * A.

The answer to 2) is debatable. As you say, A * B looks as good as A . B to represent their product, there is indeed no difference whatsoever in meaning between these two constructions, and we could have implemented everything with a single product operator. I still preferred to distinguish between non commutative generic products and scalar products of Kets or Kets and operators. This distinction is useful at least in two ways: using `*` you can express your quantum computations and then replacing by `.`, as in eval(expression, `*` = `.`), you can execute them, also having A . B, you can insert a Projector (see ?Physics:-Projector) in between and have the operation performed exactly as expected. The inconvenience of using `*` and `.` is that for a computer these two constructions are different, and this 'computer language difference' forces us to take care of it within the code or interactively. I will think if there is a way to diminish the inconvenience to a minimum.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

I gave a look at your worksheet: a DE system for x,y,z, this system is exactly solvable, then you solve for x,y,z another system of three functions f, h, k equal to 0. No text. I is not clear to me what you are asking, nor why are you setting f, h and k equal to zero or what would be the relation between that and the system sys where none of f, h or k are equal to zero. I guess that is why you received no feedback. In order to receive more concrete feedback I suggest you repost explaining your problem more clearly. 

Independent of that, there is in Maple a nice package for plotting Poincare sections of dynamical systems - check ?DEtools[poincare] and to see this at work see ?Poincare,examples.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

In Maple 17, also some releases before that, you can use the Physics:-Vectors package. For examples of its use in Vector Analysis problems like the ones you are mentioning, see for instance the 1st section of the help page ?Physics[examples].

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

This issue got fixed in the latest update of Physics (Sep/26), available for download as usual in the "Maple Physics: Research & Development" updates page. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

The old 'tensor' package is not maintained anymore and is being deprecated: tensors are now implemented in the Physics package, in a more natural way, including covariant derivatives, see ?Physics[D_]. So my suggestion would be for you to try that - if it doesn't work then could you please post the details, e.g. upload a worksheet with them, so that we can help you more concretely.

Edgardo S. Cheb-Terrab
Physics, Maplesoft 

To solve an equation in terms of  Bessel functions, you can indicate the solving method dsolve(ode, [Bessel]) (see ?dsolve[details]). In most cases that would be equivalent to using Frobenius series then rewriting the series in terms of Bessel functions. You can do that with any of the three equations you show. The one solved in terms of sin and cos you can express that solution in terms of Bessels using convert(solution, Bessel, include = all) (see ?convert[to_special_function]).

Regarding Frobenius series solution, you can formulate such a solution around a regular singularity of the quation (check ?DEtools[singularities]). Given the location of such a singularity, you can use ?DEtools[formal_sol] to see the first terms around that location, or also dsolve with its series option, or when a closed form summation solution can be computed you can directly use ?dsolve[formal_solution] as Preben mentioned, optionally indicating the location of the singularity.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Andriy, Carl

Download unabletoreproduce.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft