Hi

Quoting wikipedia, "In quantum field theory a product of quantum fields, or equivalently their creation and annihilation operators, is usually said to be normal ordered (also called Wick order) when all creation operators are to the left of all annihilation operators in the product.". That is what Maple does if you call Physics:-Normal, and Physics:-Expand calls Physics:-Normal, and expand calls Physics:-Expand. Hence Normal(am1*ap2) -> ap2*am1.

Besides QFT, the reason for normalizing in computer algebra is zero recognition, for example am1*ap2 - ap2*am1 does not return zero, because the normalization (it could but it) is not happening through `*`, so that you can work with them in the order you want, but then there must be a way to normalize this expression noting that it is equal to zero, and that is what you achieve with all of Normal, Expand, expand, Simplify, simplify.

All this makes sense to me.

As you say you can also program your own operators but If all you want is to expand expressions without normalizing them (ie without identifying subexpressions that are qual to zero) it may be simpler for you to program the expansion of products of sums of these operators instead of programming the operators themselves.

Edgardo S. Cheb-Terrab
Physics, Maplesoft 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download FundiffAnticommutati.mw

Hi

I only read your post now - note you can always send me an email through this forum. I revised now my posts of years ago in connection with an email I received today from people working in Orsay - same question. Then gave a look on the web. 

I understand there is no solving method whatsoever in what this guy presented in these papers. The paper also presents a claim about a new method to solve a problem not solved before, but then does not show one single example of the method working. 

Abel equations are a difficult problem. Progress happened between 1998 and 2004  (see the page ?dsolve,references) but I've seen nothing beyond what we presented there, that is mainly the AIR class and an algorithm to solve it systematically that is implemented in Maple within its dsolve command. In recent years we added some new solvable classes that are of type AIA (as explained in the papers listed in ?dsolve,references), typically one or two at each new Maple release, but that is it.

Edgardo S. Cheb-Terrab
Physics, Maplesoft 

Hi

I believe the solution to your problem may be found either in the readme files of GRTensor or asking Kayl directly.

But another question brings me here: are you aware that Maple provides (native) support for computation with tensors in curved spaces? It's true that GRTensor has been a magnificent package for years. I have the impression, however, that what you find in Maple nowadays goes beyond that. The Maple Physics package has builtin commands for performing most of the computations you do in General Relativity (GR), using tensor notation in curved spacetimes, and I'd say in a more natural way than GRTensor, appart from providing functionality not available in GRTensor. And for the less standard functionality you'd eventually need, you still have Maple DifferentialGeometry package (differential forms notation), a vaste and wide range package specialized in GR among other things. The Physics and DifferentialGeometry packages share the same library of solutions to Einstein's equations (metrics, this is equivalent to loading a metric in GRTensor); in turn this library found within Maple is already noticeably larger than the library of metrics (solutions to Einstein's equations) found in GRTensor. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Try this:
> sys := convert([eq[1], eq[2], eq[3]], rational); # remove floats around

> PDEtools:-InvariantSolutions(sys, display);

                            ..... various different invariant solutions here .....

Check the options in ?PDEtools,InvariantSolutions - using those options you may find solutions that are appropriate to match 'this' or 'that' initial conditions.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download TensorsInterpretatio.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download NotDifferentAnswer.mw

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Any tensor of the Physics package maps the the value 0 of any of its indices into the dimension of the spacetime. KroneckerDelta[0, 4] therefore becomes KroneckerDelta[4, 4] -> 1. This is explained in the help pages (see for instance the first sentence in the Examples section in ?KroneckerDelta).

Independent of that, the use of KroneckerDelta both as the standard KroneckerDelta and as a tensor has this problem ... and although this use is standard in textbooks, where the context is in the mind of the reader and gives meaning to the KroneckerDelta symbol, it is appearing not appropriate for a computer. I'll revise this, a fix will probably be available before the next release.

Meantime, a workaround is to not use 0 as a value for indexing Kets and Bras in quantum mechanics. i.e. define your basis of Kets starting with 1 and the problem of ambiguous meaning of KroneckerDelta will not show up. 

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Another alternative for Vector Calculus is to use the Physics:-Vectors package, that automatically uses the coordinates found in the vector field: if it is written in Cartesian, then the Divergence is in Cartesian; if is written in spherical coordinates, then so will be the computation of the Divergence, etc. For example:

(The picture seems to not work) ... Here is the input output shown in the picture:

> with(Physics:-Vectors):

> F_ := x^2 * _i + y^2 * _j + z^2 * _k;
> Divergence(F_);
                         2 x + 2 y + 2 z
> S_ := _r;
> Divergence(S_);
                                  2/r

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

Note that the d entering z before you call 'additionally' does not exclude the value 0. Therefore, in my opinion it would not be correct to take that d equal to the one you input after calling 'additionally' that then excludes the value 0. So I think this is not bad design.

So how could you do this computation? Any of these two ways work fine:

1) calli additionally before the first assignment 'z:=t=a/d:' This approach assures that the 'd' entering both assignments to z has the same mathematical properties in both expressions.

2) keep the call to additionally where you have it now, but use 'assuming additionally', that is meant to do exactly what you intend: it takes the first z (entering z * d), then gets the assumptions existing on d (found in z:=t=a/d) additionally places the new assumption, and then computes a result.

To give you an idea of how this works, 

> assume(d::nonnegative);

> about(d);                       # the real range includes 0
Originally d, renamed d~:
is assumed to be: RealRange(0,infinity)

> about(d) assuming additionally, d <> 0;  # not anymore
Originally d, renamed d~~:
is assumed to be: RealRange(Open(0),infinity)

Edgardo S. Cheb-Terrab
Physics, Maplesoft

There is a bug in an internal routine causing the result you see. It is fixed now in the version of Maple under development; the fix will probably appear in the next dot release or so.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

There is also convert/trig

convert(exp(I*x)+ exp(-I*x), trig);
                            2 cos(x)

convert(exp(I*x) - exp(-I*x), trig);
                           2 I sin(x)

convert(exp(I*x), trig);
                       cos(x) + I sin(x)

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Although you can differentiate the integrand of a functional, and add the terms that would correspond acccording to the dependency of the integrand (y', y'', etc.), each one with the corresponding sign, and for that purpose you can use Physics:-diff, in the Physics package you also have the Physics:-Fundiff comand, which directly performs functional differentiation; i.e it differentiates the functional itself - the integral directly; the examples in the help page illustrate the idea. If you are not familiar with tensors, go directly to the example equation number (25).

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
In fact I only saw your post today. No you cannot compute the value of 'a' entering MathieuC(a, q, z) using MathieuA(nu, q) with nu not integer.

Details.
Recalling, MathieuA(n, q) gives you the value of 'a' (as a function of q) entering MathieuC(a, q, z) such that MathieuC is Pi periodic (for n::even) or 2Pi periodic. So, say, for n = 1, MathieuC(a1, q, z) is 2Pi periodic, then for n = 2 you have MathieuC(a2, q, z) is also Pi periodic, where a2 = MathieuA(2, q), and so on. These values a1(q) = MathieuA(1, q), a2(q) = MathieuA(2, q), … an(q) = MathieuA(n, q) are called "characteristic values", there are infinitely many. You use 'n' just to count them and there is no meaning in 'non-integer' value of 'n'.

All the same relationship exists between MathieuS(a, q, z) and MathieuB(n, q), with the latter giving you the n (from 1 to infinity) values of a_n such that MathieuS(a_n, q, z) is Pi or 2Pi periodic.

In all cases a_n is a function of q, so you can plot MathieuA(n, q) and MathieuB(n, q) as a function of q for different (integer) values of n. You see these plots in ?examples,Mathieu.

Independent of that, all Mathieu ODE solutions can be rewritten in Floquet form as exp(I*nu(a,q))*P(z) with P(z) being Pi-periodic. For nu(a, q) rational, both MathieuC and MathieuS are have period 2*n*Pi. All this is explained in ?examples,Mathieu.

The section entitled "The Auxiliary Functions MathieuA, MathieuB, and MathieuExponent" however is not clear: for rational values of nu(a, q) you do not have MathieuExponent and MathieuA as the sort of inverse functions there mentioned. As said, the way the functions MathieuA and MathieuB are constructed, there is no meaning for their value at non-integer values of their first argument that just counts from 1 to infinity the amount of Mathieu functions that are either Pi or 2*Pi periodic. I'll see to rewrite the current paragraph to avoid this confusion between n and nu.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi

Revising old posts related to Physics; these examples you posted work fine in Maple 16.02.

Edgardo S. Cheb-Terrab
Physics, Maplesoft