ecterrab

13431 Reputation

24 Badges

19 years, 362 days

MaplePrimes Activity


These are answers submitted by ecterrab


 

Below, the lines in 1D input format are yours, the comments and lines in 2D input format are mine.

restart

with(plots):
with(VectorCalculus):
with(Physics[Vectors]):
with(inttrans):
Setup(mathematicalnotation = true):

SetCoordinates('spherical'[r, phi, theta]);
E_[1]:=Vector(<r,phi,theta>);
'VectorCalculus(E_[1])'=type(E_,Vector);
'PhysicsVectors(E_[1])'=type(E_,PhysicsVectors);

spherical[r, phi, theta]

 

_rtable[18446744078278530462]

 

VectorCalculus(E_[1]) = false

 

PhysicsVectors(E_[1]) = true

(1)

Ev_[1]:=convert(E_[1],PhysicsVectors);
'VectorCalculus(Ev_[1])'=type(Ev_,Vector);
'PhysicsVectors(Ev_[1])'=type(Ev_,PhysicsVectors);

_phi*phi+_r*r+_theta*theta

 

VectorCalculus(Ev_[1]) = false

 

PhysicsVectors(Ev_[1]) = true

(2)

E_[2]:=convert(Ev_[1],VectorCalculus);

_rtable[18446744078278521430]

(3)

Check who is `#mover(mi("E"),mo("&rarr;"))`[1] and `#mover(mi("E"),mo("&rarr;"))`[2]

lprint(E_[1])

Vector[column](3, {1 = r, 2 = phi, 3 = theta}, datatype = anything, storage = rectangular, order = Fortran_order, attributes = [coords = spherical[r, phi, theta]], shape = [])

 

lprint(E_[2])

Vector[row](3, {1 = r, 2 = theta, 3 = phi}, datatype = anything, storage = rectangular, order = Fortran_order, attributes = [vectorfield, coords = spherical[r, phi, theta]], shape = [])

 

 

You see the differences:

– 

 A column vector versus a row vector. From the point of view of "a vector', this difference is artificial only related to using a matricial representation in VectorCalculus, and does not exist when using the algebraic representation of the Physics:-Vectors package. So this artificial distinction is discarded in the first conversion.

 

– 

 When converting back from Physics to VectorCalculus you always get a vectorfield, corresponding to the meaning of a vector in the Physics:-Vectors package.

 

Till here there is nothing wrong with either of the first and second conversions but for perhaps mentioning this distinction clearly in the documentation (I am replying without giving a look at it).

 

Then, if, during the conversion from Physics (algebraic representation of a vector field) to VectorCalculus (matricial representation) you do not want a vector field AND want a column instead of a row vector, you can do this additional step

E_[3] := Vector[column](E_[2])

_rtable[18446744078278519014]

(4)

You see that now `#mover(mi("E"),mo("&rarr;"))`[3] is the same as `#mover(mi("E"),mo("&rarr;"))`[1]

lprint(E_[3])

Vector[column](3, {1 = r, 2 = theta, 3 = phi}, datatype = anything, storage = rectangular, order = Fortran_order, attributes = [coords = spherical[r, phi, theta]], shape = [])

 

lprint(E_[1])

Vector[column](3, {1 = r, 2 = phi, 3 = theta}, datatype = anything, storage = rectangular, order = Fortran_order, attributes = [coords = spherical[r, phi, theta]], shape = [])

 

``


NOTE ADDED AFTERWARDS: I missed in the above that the order of phi and theta is not following the convention in VectorCalculus [ r, phi ,theta ] different from Physics [ r, theta, phi ]. This is fixed now, as explained in the next reply below.

Download ConversionsAreOK.mw

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

Hi JLPaillet
No, there is no conflict between the mla library files found in the system folder and the Physics2017.mla library. You can place it in the system folder with no problem. If you still prefer not to do so, then check the help page ?libname to see how to add a directory to the libname path and place Physics2017.mla in that directory. Both approaches are equivalent.

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


From your worksheet, you arrived till equation (11), I'm taking it from there:

....

 

Moreover, if in your worksheet you do not assign n := 2 and re-executed the worksheet including the Setup of [x, y] = 0, you get the result you asked also for general n.

 

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

This was indeed a Typesetting issue related to the new default of extended typesetting in Maple 2017. It is fixed now. The fix is available to everybody as usual in the Maplesoft R&D Physics webpage, within the updated Physics library, that includes as well updates to the Differential Equations and Mathematical Functions programs.

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

Hi  _Maxim.  Markiyan Hirnyk

Simplify calls convert, the problem is one place, not two, and happens when both Re(z) > 0 and abs(z) > 1. So this problem, that manifests through simplify or convert, is now fixed. The fix is available for download together with the updates for Physics, Differential Equations and Mathematical Functions distributed in the Maplesoft R&D Physics webpage.

Then, the "numeric exception" for abs(z) < 1 is not expected. I understand that within the unit circle the result is 0. This and some other cases where MeijerG is not numerically evaluated will require a further look by the people who take care of the numerical evaluation of MeijerG. Or otherwise I may be able to help but only during November.

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

Your PDE can be solved, symbolically, in different ways, resulting in different particular solution, that in a second step they may or not be suitable to match the boundary conditions you specify.

Among the different particular solutions you can obtain, there are:

pdsolve(PDE, HINT = `+`);

pdsolve(PDE, HINT = `*``); # this has phi(x, t) = 0 so not OK for your boundary conditions

PDEtools:-InvariantSolutions(PDE, degreeofinfinitesimals = 1);  # linear infinitesimals are easy to compute and to use

If none of these symbolic solutions can be specialized to match your boundary conditions, you can still try other options of InvariantSolutions (see its help page), or also some change of variables that you may find that simplify your problem (this is trial and error, the command is PDEtools:-dchange) to a point that it can be solved using some of the alternatives mentioned.

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

Hi

A fix for this issue, regarding the display of rtables that contain aliased objects, is now available within the Physics updates library, distributed in the Maplesoft R&D Physics webpage. This update library also contains adjustments and developments for Differential Equations (symbolic solutions only) and Mathematical functions that couldn't enter in Maple 2017.3 due to time constrains.

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

Hi Pascal4QM

Currently, it is not possible to do what you want. What vv shows is an F procedure that takes indices and arguments as arguments, but that F cannot be a tensor of the Physics package, for which it needs to be a "table procedure", as you show (i.e. not a plain procedure).

The implementation of tensors as 'table procedures' is in turn necessary in order to "execute some action" when you index the object. For example, the procedure indicated by vv will not execute any action when you enter F[j], only when you enter F(j).

In the end, what you actually want do accomplish is similar to what we do with D(F)(x), that flows through a rather obscure program called evalapply. Once you read its help page you see its potential, but for historical reasons the Maple kernel only directs the flow through evalapply for F(j)(x), not F[j](x).

Meantime, it is also the case that to implement Physics as you see it many things required tweaks and tricks, and one of the most mandrake-like ones was the "Physics evaluator" (described in ?Physics,Setup), that maps your tensor input into one that has covariant and contravariant indices, even when you input all the indices covariant. This same Physics Evaluator was then used to implement automatic simplification: you input a computation, without calling the simplifier, and nevertheless, everything comes "simplified in size". (BTW If simplify/size were faster, kernel, I would vote for this option to be default)

This Physics Evaluator could also be used to make evalapply work for F[j](x) the same way it works for F(j)(x), without requiring changes in the Maple kernel. In this way, you can have a Physics tensor (ie defined as a table-procedure, not a plain procedure) and at the same time be able to use indices and function arguments are arguments of a tensor function.

I'm now heavily loaded with a number of presentations to do but your implicit suggestion is worth implementing. I will work on this.

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

I imagine that the answer to your question is convert/diff, in that declare handles diff structures, not D ones. For instance, for the two expressions of your worksheet, using convert/diff you get:

 

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

This one is fixed, in all the conversions from arctan to any of the complex components (Re, Im, signum abs, argument). The FunctionAdvisor now also reports the condition (x and y being real) for this conversion to be valid, e.g. when you input FunctionAdvisor(specialize, arctan, abs).

This adjustment is available to everybody within the updated library for Physics, Differential Equations and Mathematical Functions, distributed in the Maplesoft R&D Physics, and etc. webpage. If possible (timewise) this fix will also appear in the next dot release, Maple 2017.3

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

Hi,

The last statement of your worksheet, where you read 
f15:=isolate(f14,Nabla.diff(E_(t,x,y,z),t))
I don't get an error message but the following

Independent of that, you load only Vectors, not all of Physics, therefore your calls to Coordinates are not active. Also, you use x,y,z (Cartesian) but then use rho around (which is the cylindrical coordinate. If you intend to use it as a density, not the coordinate, either use a different letter or use the local rho approach (see ?local). If however your rho is indeed the cylindrical coordinates, then it is simpler to use cylindrical coordinates all around, instead of cartesian. Attached is your worksheet using cylindrical coordinates.

Different_basis_(reviewed).mw

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

This is a good opportunity to note the difference between the two computational representation of vectors available in the Maple system: the array (e.g. as 1 x n matrices, explicity containing the vector components) and the algebraic one, ie natural Maple algebraic expressions including unit vectors, possibly abstract not projected (ie where you do not know the components).

Representing vectors as matrices could be advantageous when computing with extremely large systems - say involving thousands, for which Arrays have special performance treatment. On the other hand, the algebraic representation is more natural, a concrete mimicry of what we do with paper and pencil, that also permits working with abstract representations.

The advantages of abstract vector manipulations are significant when formulating algebraic problems, see for instance ?Physics,Examples, the first section on Vector Analysis. For operations with components, the advantage of an algebraic formulation is that you can manipulate the vectorial expressions with mostly all of the commands of the library that manipulate algebraic expressions - this is also not possible with the array (not algebraic) representation.

Regarding your question, Kitonum showed the array representation approach (albeit neither p nor q are really array vectors there, only lists). This is the same operation using an algebraic representation:

 

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

 

Therefore, the two products of Gamma functions are equal to one, and also the same, and what remains, and infinite sum of z^k/k!, is just the exponential function. Regarding how to evaluate infinite series to hypergeometric functions, is about going from the right-hand-side to the left-hand side using not just matching pattern but also mathematical identities of different sorts, that end up rewriting an infinite sum as the right-hand-side and so as a hypergeometric function.

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

 

MeijerGTransformationNotValidOverTheCut.mw

 

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

Hi

From a first look, in the image you show E(u) = E(phi, k); then see Abramowitz and Stegun, page 589 (17.2.2): phi = JacobiSN(x,k).

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

First 29 30 31 32 33 34 35 Last Page 31 of 55