Hi
In order to help you please post the input lines you used to define the operators C and c. Just from what you show, if c[1]^2 is not returning zero, then you seem to have failed in defining it as an anticommutative operator or the like.
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
The main help page for Physics is ?Physics and the three links found there that I'd mention as more relevant are ?Physics,examples, ?Physics,conventions and ?Physics,Setup. In ?Physics,examples you see some problems involving annihilation and creation operators (see last section on Quantum Mechanics). Giving a look at how these commands are actually used is frequently more useful than reading a complete description of the functionality in a help page. Regarding the help pages, I'd recommend reading the calling sequence, first paragraph (introductory) and jump to the examples, and only read the rest if there is something unclear in the examples.
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
The main help page for Physics is ?Physics and the three links found there that I'd mention as more relevant are ?Physics,examples, ?Physics,conventions and ?Physics,Setup. In ?Physics,examples you see some problems involving annihilation and creation operators (see last section on Quantum Mechanics). Giving a look at how these commands are actually used is frequently more useful than reading a complete description of the functionality in a help page. Regarding the help pages, I'd recommend reading the calling sequence, first paragraph (introductory) and jump to the examples, and only read the rest if there is something unclear in the examples.
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
If c and C are annihilation/creation operators there are various advantages in using the Annihilation and Creation commands of Physics in that the properties of these objects are set automatically. See the corresponding pages. So if this is the case you can then construct these operators using those two commands and set the algebrarule with KroneckerDelta as you show, using Setup, and everything works as expected.
If that is not the case, so if c and C are NOT annihilation/creation operators, then the first Setup calling sequence is OK, and where you say "Troubles begin if I want to define rules for mixing the c's and the C's like [setting their anticommutator different from zero]", what is happening is that the Physics routines are assuming (they should not ..) that the c[i] and C[j] belong to the same space, therefore they anticommute between themselves, as if they were all part of the same set of anticommuting variables, for example as if this set of variables/operators were entered using the anticommutativeprefix. This assumption that members of different anticommuting groups anticommute between themselves is not correct and is fixed in the upcomming Maple.
Note anyway that the (undesired) anticommutation happens regardles of calling simplify, and also that the simplificator of the Physics package is Simplify, not simplify (this may change in order to have Simplify called automatically from inside simplify...).
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
If c and C are annihilation/creation operators there are various advantages in using the Annihilation and Creation commands of Physics in that the properties of these objects are set automatically. See the corresponding pages. So if this is the case you can then construct these operators using those two commands and set the algebrarule with KroneckerDelta as you show, using Setup, and everything works as expected.
If that is not the case, so if c and C are NOT annihilation/creation operators, then the first Setup calling sequence is OK, and where you say "Troubles begin if I want to define rules for mixing the c's and the C's like [setting their anticommutator different from zero]", what is happening is that the Physics routines are assuming (they should not ..) that the c[i] and C[j] belong to the same space, therefore they anticommute between themselves, as if they were all part of the same set of anticommuting variables, for example as if this set of variables/operators were entered using the anticommutativeprefix. This assumption that members of different anticommuting groups anticommute between themselves is not correct and is fixed in the upcomming Maple.
Note anyway that the (undesired) anticommutation happens regardles of calling simplify, and also that the simplificator of the Physics package is Simplify, not simplify (this may change in order to have Simplify called automatically from inside simplify...).
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
[italized: your text, non-italized: my text].
Maple 11 has included indicial notation capability to its new Physics package. This is a good start in performing tensorial calculations using Einsteinian summation convention. However, I wish that Maple further adds the following capabilities to make this package of practical use to folks involved in tensor analysis.
Generally speaking, I believe that the ability to compute with tensors taking into account Einsten's summation rule while monitoring free and repeated indices for correctness (by the way Maple is the first system implementing this) suffices to perform most tensorial computations at undergraduate, as well as many of those performed at graduate level. The handling of D-dimensional transformations (your X(Y) and Y(X) previous post) is something that can be done in current Maple though not the way you've been suggesting; I also think that "Physics" has a way to go in making this type of computation kind of trivial as opposed to one requiring Maple expertise.
Independent of that, in addition to Physics, Maple 11 also presents astonishingly increased tensor functionality in the DifferentialGeometry package; integrating some of these novelties with a friendlier interface in the Physics package is part of the current developing plans.
Regarding your wish list:
1) Both covariant and contravariant indices are denoted in subscript. Including the convention of posting counter and covariant indices in super and subscripts, respectively, will help to improve the readability of the printed results.
Note that, when the indices are contracted, we know one is covariant and the other contravariant (otherwise it would be an error); then when the indices are free, the correctness of the tensorial expression is independent of whether the index is covariant or contravariant (see ?Physics,conventions). It is only when you project the tensor space objects into components (e.g. make A[mu] = [A[0], A[j]]) that this distinction between covariant and contravariant indices is relevant. In fact, also when you compute by hand - when you do not need to project the tensor expressions - it is unnecessary (while is "brain-focus expensive") to carry on the information about the "co/contra"variant character of the indices. The Maple implementation takes advantage of this fact not requiring you to specify the character (co or contravariant) when you enter expressions (great!) nor when it displays them (requires you to be aware of the fact). This is an important simplification in the algebraic representation of objects that want to keep.
On the other hand, the development plan for "Physics" includes (new, not currently existing) tools for declaring the character of free indices in an expression _together_ with the ability to project free and projected indices them into components, as well as the ability to entirely omit repeated indices from the display (as you see in some textbooks), and present the free ones as superscripts or subscripts according to the character explicitly declared (this declaration being optional), plus (still under debate) the adoption of a default character for free indices when their character is not declared (e.g. contravariant, as it is the case when handling Dirac matrices -- see ?Physics:-Dgamma).
2) The package needs multiple types of independent indices within a given spacetime. For example, in continuum mechanics, small letters are used to denote Eulerian framework and Capital letters are used to denote Lagrangian framework.
I don't understand what you mean by "Lagrangian" and "Eulerian". In any case this is the stats of things: tensors are defined in spaces and in Physics you have a default spacetime that can also work as N-dimensional space-only, and two other types of indices for representing internal manifolds. It is true that three kinds of indices - or even four after distinguishing space-only from spacetime indices (this is part of the project) - may be seen as "too few" kinds of indices in some contexts but these contexts are rather rare, I think. Note we are talking of _tensor_ indices, so representing objects defined in some space, not just arbitrary indices (you cab have as many non-tensor indices as you want).
The "Setup" command only allows defining spacetime indices as lowercaselatin.
Note there are three options: lowercaselatin, upercaselatin and greek. The upcoming forth is a distinction between the first 10 lowercaselatin and the next ones.
However, for practical use, it needs to allow two or more types of spacetime indices.
I may be missing something here: you can have, basically, as many spacetime coordinates (X, Y, Z, etc.) as you want. What do you actually mean with " ... need more than one 'spacetime kind of index""?
> It also should allow building functional relationships between the variables in two coordinates systems.
Yes. That is what I meant in the first paragraph on top. You can do that today in different ways but requires Maple expertise, and if you use the DifferentialGeometry package for that purpose it requires some DG background (by the way DG was presented with a DG course in the form of Maple worksheets).
3) Lot more examples are needed to denote the use of X and Y spacetimes.
I do not understand what you meant. Some examples of the use of many systems of coordinates at the same time are found in ?Fundiff, ?FeynmanDiagrams, and in some other pages of the package. What we do have in the plans is to add more examples of the use of the package in different areas than the ones you already see at ?Physics,examples (today you only see Analytical Geometry, Classical Mechanics, Electrodynamics and Quantum Mechanics, and no more than 4 examples per topic).
4) The metric tensor can be defined only in Euclidean and Pseudo-Euclidean spacetimes. More general definitions should be allowable.
Yes, though not about "more flat-space" definitions. What is in the plans is to extend the algebraic manipulations to handle curved spaces.
Summarizing: first of all many thanks for your feedback; on the matching side of your wishes "Physics" is already evolving to include type-declarations for the free indices, tools for projection spacetime into spaceonly-indices and time component, expanding the spaceonly ones, and tools for handling manifold transformations between systems of coordinates not requiring you to get involved with DifferentialGeometry. The display (super/lowerscripts) depends on independent graphical interface developments that are also in the plans.
Edgardo S. Cheb-Terrab
Ph.D Theoretical Physics,
Research Fellow, Maplesoft
Hi,
Indeed there is an excessive type checking in Physics:-Dagger that prevents the use of Dagger on Matrix structures. That will appear fixed in the next 11.0x release. Meantime, for a Matrix you can use LinearAlgebra:-HermitianTranspose. This would be a patched 'dagger' command:
> dagger := u -> if u::Matrix then LinearAlgebra:-HermitianTranspose(u) else Physics:-Dagger(u) end if;
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
The list of things is large to describe in a post. Trying to be brief I'd say that this package implements computational representations for 3D non-projected vectors, anticommutative and noncommutative variables, spacetime tensors and related indexed differentiation operator, the dAlembertian, Einstein's summation convention for repeated indices, Pauli and Dirac matrices, Dirac notation for bra-ket quantum state vectors and projectors, commutators and anticommutators, quantum field operators, etc. The extended typesetting of these mathematical-physics objects in the GUI look terrific.
Four relevant things not evident in the summary above is that the package can compute taking into account "algebra rules" that you define for commutators and anticommutators of objects, including summation convention for repeated indices, in the same way you can define "bracket rules" for computing the result of projections (inner product) between bra and ket state vectors, the Trace command can compute traces between Dirac or Pauli matrices and that the GreenFunctions routine essentially compute Feynman graphs of up to three loops and six external legs.
Generally speaking, the computational tools implemented probably cover the computational needs of undergraduate and basic graduate Physics courses. Among the things I can mention that didn't enter this version for Maple 11 is a subpackage specialized for General Relativity, that can be implemented on top of the new DifferentialGeometry package of Maple 11.
Edgardo S. Cheb-Terrab
Ph.D. Theoretical Physics, Maplesoft
Editor, Computer Physics Communications
Hi,
> 1. Will the differential geometry package subsume the functionality of the tensor and/or differential forms package s?
Yes, in that DifferentialGeometry (DG) turns obsolete these other package you mention, though not entirely in Maple 11.
> 2. Will there be any major changes and/or upgrades to the group package? Any new (abstract) algebra functionality?
I am not sure what you mean by abstract algebra and some of that I believe is already in DG. Could you be more precise?
> 3. Is the new differential equations package a successor to the DETools package?
There is no new differential equations package, though PDEtools duplicated its size with a new module for symmetries for PDEs, and DEtools has a module for symmetries since 1997, so I guess you are asking whether the new PDE symmetries routines are replacing the old ones in DEtools?
If so, the answer is: no. The old symmetry routines - only for ODEs, not PDEs - have sophistications that will take some years to implement in the PDE sector. Even that day I believe there would be no reason to remove them because they are specialized and fast in a way it would be difficult to achieve with more general routines.
Edgardo S. Cheb-Terrab
Ph.D. Theoretical Physics, Maplesoft
Hi,
Although it would be interesting to have a Maple plug-in, especially for helpfiles, note that the existing GDS plug-ins by Larry Gaeda (from Ontario), allow you to index Maple worksheets and also windows help-files; I wouldn't be surprised if he finds a simple way to extend his plug-in to also index Maple help databases (hdb files) or perhaps his plug-ins already work OK with these files.
The links to Larry's plug-ins are:
http://desktop.google.ca/plugins/i/indexitall.html
http://desktop.google.ca/plugins/i/indexthechm.html
In connection with installing these plug-ins, you may want to re-index or do alike operations, for which the following plug-in is relevant:
http://desktop.google.ca/plugins/i/tweakgds.html
Finally this other plug-in is helpful in narrowing searches in typical ways which are not possible with the standard GDS
http://desktop.google.ca/plugins/i/airbeargdsuite.html
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Hi,
It is true that in general these problems are tough. There are Maple commands to treat them though. I mean: "Given a system of equations, differential or not, linear or not, involving inequations or not, depending on some parameters, say {a,b,c,...}, such that a solution exists only for some particular values of these parameters, compute all these solutions as well as the different values of the parameters {a,b,c,...} such that these solutions exist".
By the way, among the existing computer algebra systems, Maple is the only one able to handle such a general problem.
The Maple packages handling these probelms are diffalg and RIF. They can do this type of computation since Maple R5 (diffalg) and Maple 6 (RIF), and both work rather efficiently, in my opinion RIF performs better on average problems.
The computation using diffalg/RIF in Maple is also simplified and extended, by means of the PDEtools[casesplit] and PDEtools[dpolyform] commands, in order to handle basically all the mathematical functions. That is, to perform types of (maybe differential) Grobner basis elimination on systems not just rational in the unknowns and the independent variables. Despite being in PDEtools, casesplit handles the same way systems of equations not involving derivatives.
To see some examples of how this works see ?PDEtools[casesplit] and PDEtools[dpolyform].
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
It is true that in general these problems are tough. There are Maple commands to treat them though. I mean: "Given a system of equations, differential or not, linear or not, involving inequations or not, depending on some parameters, say {a,b,c,...}, such that a solution exists only for some particular values of these parameters, compute all these solutions as well as the different values of the parameters {a,b,c,...} such that these solutions exist".
By the way, among the existing computer algebra systems, Maple is the only one able to handle such a general problem.
The Maple packages handling these probelms are diffalg and RIF. They can do this type of computation since Maple R5 (diffalg) and Maple 6 (RIF), and both work rather efficiently, in my opinion RIF performs better on average problems.
The computation using diffalg/RIF in Maple is also simplified and extended, by means of the PDEtools[casesplit] and PDEtools[dpolyform] commands, in order to handle basically all the mathematical functions. That is, to perform types of (maybe differential) Grobner basis elimination on systems not just rational in the unknowns and the independent variables. Despite being in PDEtools, casesplit handles the same way systems of equations not involving derivatives.
To see some examples of how this works see ?PDEtools[casesplit] and PDEtools[dpolyform].
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
Editor for Computer Algebra, Computer Physics Communications
Hi,
You question is about aspects of a numerical solution, assuming that
> ... for this problem no closed-form...
So maybe this is of help: in Maple 9.5 and 10 (perhaps also in previous versions), dsolve can compute a closed-form solution for this problem:
> dsolve([diff(s(t),t) = A - A * rho^((1 - r^(theta * t)) * x) - v, diff(f(t),t)=((c - s(t)) / l) * m + x, diff(h(t),t) = x, f(0) = 0, s(0) = 0, h(0) = 0]);
x (theta t)
A rho Ei(1, x r ln(rho))
{h(t) = x t, s(t) = ----------------------------------
theta ln(r)
t
x /
A rho Ei(1, x ln(rho)) | m c
- ----------------------- + (A - v) t, f(t) = | ---
theta ln(r) | l
/
0
x (theta _z1)
m A _z1 m A rho Ei(1, x r ln(rho)) m v _z1
- ------- - -------------------------------------- + -------
l l theta ln(r) l
x
m A rho Ei(1, x ln(rho))
+ ------------------------- + x d_z1}
l theta ln(r)
Edgardo S. Cheb-Terrab
Research Fellow, Maplesoft
