## 13633 Reputation

18 years, 325 days

## Invariant Solutions...

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

## Define(A) and tensors in your algebra...

 > restart; with(Physics): Setup(mathematicalnotation = true):

It is possible to indicate each of the many quantum operators as you did, but it is simpler to just indicate A, and that is equivalent to indicate anything that indexes A, as in

 > Setup(op = A);
 (1)

Check it out

 > type(A, Physics:-Library:-PhysicsType:-QuantumOperator);
 (2)
 > type(A[1, 2], Physics:-Library:-PhysicsType:-QuantumOperator);
 (3)

Set now the algebra, as you did

 > Setup(%Commutator(A[i, j], A[k, l]) = A[i, l]*KroneckerDelta[j, k] - A[k, j]*KroneckerDelta[l, i]);
 (4)

At this point there is a bit of ambiguity in the interpretation of this expression ... (more on this at the end).

The interpretation the code is doing is that in this algebra there are free indices   in the left-hand-side, and the same in each of the terms added in the right-hand-side. However, until you define A as a tensor, the term  has for tensorial free indices only , while the term has for tensorial free indices only , and so the sum of these two terms with "different free indices" is interrupted with an error saying the terms being added have different free indices (incorrect thing).

In short, your computation, to proceed, requires defining A as a tensor

 > Define(A);
 (5)
 > Commutator(A[3, 2], A[2, 1]);
 (6)

There is a second possible interpretation though, which is to think of the algebra rule  as "non-tensorial", because there are no contracted products, so this is not a case where Einstein's summation rule for (non-existing here) repeated indices would apply, and because the letters used to index the quantum operator A are not set as indices of any kind, as one can see:

 > Setup(timein, spacein, spinorin, gaugein);
 (7)

From this output of Setup, KroneckerDelta should be considered a tensor only when indexed with greek letters - not the case in your example. And hence this operation you wanted to do should proceed without requiring the definition of A as a tensor.

Among the two interpretations, in this example I think this second interpretation is more natural - I will adjust the code accordingly; perhaps the change is available for download before the next release.˜

Edgardo S. Cheb-Terrab
Physics, Maplesoft

If I understand your post correctly, I see no bug, and what you call 'the last one' is indeed zero. The input/output below is obtained using Maple 17.01.

 > restart; with(Physics): Setup(mathematicalnotation = true, op = C, quiet);
 (1)
 > Cp := Dagger(C);
 (2)

To make the input more readable, frome here on use Cp in the input, not Dagger(C)

 > Setup(%Commutator(Cp, C) = -1);
 (3)

 > S := sqrt(N - (Cp + sqrt(N)*conjugate(eta))*(C + sqrt(N)*eta)):

This is the expression you use within f and g:

 > eq1 := collect(expand(op(1, S)), N);
 (4)

You want to substitute

 > op(1, eq1) = xi;
 (5)

You can do that the way you did it, or before calling series etc.

The way you did it first.
I am quoting all calls to delay their evaluation and so see who is f and g before performing the computations

 > f := 'map'(simplify, 'map'(x -> x*sqrt(xi), 'convert'('series'('sqrt'('subsop'(1 = xi, eq1)/xi), xi = infinity, 3), polynom)));
 (6)
 > g := '`assuming`'(['map'(simplify, 'convert'('series'('sqrt'('subsop'(1 = xi, eq1)), xi = infinity, 2), polynom))], [xi > 0]);
 (7)

Looks all OK to me. Indeed they are the same:

 > simplify(f - g);
 (8)

Note you do not need Physics:-Simplify for this.

Here is substituting  before proceeding; it makes the input a bit more readable

 > eq2 := subsop(1 = xi, eq1);
 (9)
 > f2 := map(simplify, map(x -> x*sqrt(xi), convert(series(sqrt(eq2/xi), xi = infinity, 3), polynom))):
 > g2 := map(simplify, convert(series(sqrt(eq2), xi = infinity, 2), polynom)) assuming xi > 0:

This is also zero

 > simplify(f2 - g2);
 (10)
 >

Edgardo S. Cheb-Terrab
Physics, Maplesoft

## bug and workaround...

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

## Physics:-Vectors...

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

## design is ok; alternatives; how it works...

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)

Originally d, renamed d~~:
is assumed to be: RealRange(Open(0),infinity)

Edgardo S. Cheb-Terrab
Physics, Maplesoft

## You crossed with a bug...

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

## also convert(..., trig)...

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

## Functional differentiation, directly....

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

## meaning n in MathieuA(n, q)...

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

## it works fine in Maple 16.02...

Hi

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

Edgardo S. Cheb-Terrab
Physics, Maplesoft

## it works fine in Maple 16.02...

Hi

Revising old posts; this problem got fixed, 'diff(Dagger(P(t)), t)' of your post works fine in Maple 16.02.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

## it works fine in Maple 16.02...

Hi,

Just revising this old post - the fix got into the system and examples as the one you posted work fine in Maple 16.02.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

## Fixed...

I missed a line in your post, "LinearAlgebra[Transpose](map(Dagger, P))". Dagger was using LinearAlgebra:-HermitianTranspose, but you are right, the matrix components may be operators, and in these cases, as the one you posted, LinearAlgebra:-HermitianTranspose will not work as expected.

It's fixed now in the Maple version under development.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

## It's a bug...

Hi

It's attempting dDagger/dP * dP/dt  to then complain that d/dP is not defined for P::noncommutative  - that behavior is bogus.

Now, diff and Dagger do not commute unless the differentiation variable is known to be real. In that case there is still the issue of the normal form: should it return diff@Dagger or Dagger@diff? Note this applies to diff, and the Physics commands d_[mu], D_[mu] and Fundiff. Till Maple 16, when possible (but for this bug you are pointing at) we mapped Dagger into diff constructions, returning as in diff@Dagger, considering that outside a computer Dagger(P) is not a "composite function" - it is just a function as P is.

According to that, the output for diff(Dagger(P(t)), t) would be 'unevaluated' (that is, as you are entering it, without performing any operation). That is what I have in the version of Maple under development after the bug got fixed. Opinions?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

 First 52 53 54 55 56 Page 54 of 56
﻿