Updates for Physics are available on the Maplesoft R&D Physics webpage around the clock, posted every week, and include bug fixes (e.g. those reported here in Mapleprimes) and also new developments, functionality.

Maple 18.02 includes all the changes that happened in the package till July/30, that are listed below in a linked PDF, as well as in a linked worksheet including examples for all the changes. 

Likewise all the changes that happened in the differential equation programs and the MathematicalFunctions package till July/30, made available for download along the year on the Maplesoft R&D DEs and Mathematical Functions webpage, are also included in Maple 18.02.

The update being distributed for Physics in its Maplesoft R&D webpage, however, includes a substantial number of further changes and new functionality not present in Maple 18.02. To mention but one, there is a new Tetrads subpackage for General Relativity. These further changes include all the fixes and new developments from August/1 till today, and run natively in the new Maple 18.02 just released.

NOTE: If you have been updating Physics till recently, installing Maple 18.02 will automatically reset the changes in Physics to July/30, which is not a problem: to activate all the changes from August/1 till today please update Physics again, as said downloading it from the Maplesoft R&D Physics webpage.

The links mentioned: a PDF describing the changes in Physics included in Maple 18.02 and Worksheet to reproduce the changes in Physics 18.02 described in the PDF.

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

@NOh 

I cannot explain why the website suddenly loses contents. It happened other times with other people too. The contents is there for a while, after uploading, and then, sometimes, suddenly, it is not there anymore. It was reported. I thought it was fixed. Unfortunately it is still happening.

I uploaded the worksheet again.

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

@guyp 

Yes, it would be interesting to have these issues fixed directly in sum instead of having to redefine sum. Note anyway that the redefinition mentioned, is already a core Maple procedure, and the whole Physics package is too. This issue is pretty relevant in Physics, where we keep entering these sums and not understanding why these unexpected results.

But there are more things to take into account: some people would prefer to see multi-index summation directly in the add command, while others would prefer to not change the premature evaluation because they take advantage of that (sum is a command with more than 30 years around), etc.

The issue is then debatable, and I personally would also prefer to just fix the standard and old Maple sum command for everybody, and just be sorry if someone was taking advantage of this premature evaluation. But for now what we have is this redefinition provided, it concretely fixes the core sum command (it does exactly what we would do if we were to fix this problem in sum), is provided as an official approach to the problem, and tries to address all these different things mentioned at once.

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

Hi NOh

I'm pretty busy in this moment - will give a look at this and return some feedback hopefully by the end of tomorrow. Meantime, it would help concretely when revising/optimizing your code if you could explain, before that review, in few words (say a paragraph per routine), what is what you are trying to achieve with each of these routines you have programmed.

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

Hi Age

Sounds like a good idea to me. Regarding the problem you mentioned in this first post, it is more a GUI issue, where % and (2) are not exactly the same thing (they should). Independent of that I tweaked the Physics code to avoid this GUI subtlety. So the two results are the same, equal to 1, and in that sense the problem is fixed (not the underlying GUI issue though). The adjustment can be downloaded as an update to the Physics package from the usual place, the Maplesoft R&D Physics webpage.

Independent of that: note there is a distinction between `.` and `*`, and when you compute algebraically the operation is `*`. The code takes care of this duality in some places but using `.` to perform algebraic (non-matricial and non Bra, Ket stuff) you will not always get the operation performed.

There were other posts in Mapleprimes regarding how to implement the algebra of Pauli matrices using commutators and anticommutators. The plan is to have these algebras known by the system, so that nobody needs to enter them, but that is still not implemented. This week and perhaps the next one I will still be working on tetrads.

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

@Age 

I see now clearly the issue you are pointing at, and indeed your logic is perfect. The problem was as mentioned in the third bulled of my previous response here, I still need to make complete the implementation of tetrad indices, in this example, a routine that was only working with spacetime indices, detected a contravariant index and it lowered using the spacetime metric, but the index is a tetrad one, so the tetrad metric should have been used instead. This problem would turn visible if: a) you enter the right-hand side of the definition as a matrix and b) the tetrad index is contravariant, and if any of a) or b) wouldn't happen, the problem would not be visible. It is fixed now and the fix available at the usual place, the Maplesoft R&D Physics webpage.

This latest version of Physics also has an important step in the implementation of tetrads. Say you define a tensor giving its spacetime components, as in A[mu,nu] = (some tensorial expression or a Matrix, or an Array if there are more than 2 indices, etc.). What are the components of, say, A[~a, mu]? or A[a, ~b]? or any combination of covariant/contravariant/ and spacetime/tetrad indices? It is now implemented.

It follows an image showing the fix and this novelty illustrated with your example.

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

@Age 

Thank for your feedback, it's been useful, very, and please, if this is not a burden for you, keep posting any problem you find, here in Mapleprimes or writing to physics@maplesoft.com (I prefer in Mapleprimes, because everybody interested in Physics learns something with the exchange. And the package grows more and more with yours and other's feedback.

Regarding the specific issue of tetrads, you know, it is a new development. What works already, works pretty well, I think, but not everything is implemented.

And what is and what is not yet there? Skipping the little details, the design is that now you can compute with the tensor A, as in A[mu] or A[a] in equal footing, and representing different objects: A[mu] are the components in the global coordinates (g_[mu,nu] metric) system while A[a] are the components in the local (tetrad eta_[a,b] metric) system.

This requires:

• Ability to define a tensor with spacetime or tetrad indices: implemented.
• Ability to compute the components when you raise any of these different indices: implemented - your example today actually works fine for me - please see below.
• Ability to compute the tetrad (spacetime) components when the definition was in terms of spacetime (tetrad) components: not implemented yet. Eg you define a tensor giving its spacetime components, say as in A[mu,nu] = g_[mu,nu] and you ask A[mu, b, matrix].
• Ability to perform operations (all Physics commands dedicated to general relativity) distinguishing the case (the index is spacetime or tetradic): not implemented yet, though a new Library routine for making this possible is already in place, called Library:-RewriteTypeOfIndices (see below). To mention but one example of things not implemented yet: d_[mu] and d_[nu] commute, of course, but d_[a] and d_[b] do not.

And in what is already implemented I still expect we will find things to adjust furthermore, here or there, the code is pretty new. But as said what is in place is already working very-very well, and I am happy to handle your next bug reports rapidly if there are any. Your suggestions (not necessarily bug reports) are also welcome.

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

@Age 

It is great that you are providing this early feedback on tetrads/GR - many thanks - not many people in this forum work in the area.

The problem you mentioned is now fixed. The fix is available for download in the usual place, the Maplesoft R&D Physics webpage. The extension of the tensor machinery of the package to handle tetradic and spacetime indices at the same time, will probably require some more touches here or there, it is a large portion of code.

Attached is also revision of your worksheet with some comments; mainly: you indicate which repeated indices are contravariant (you can, but there is no need for that), and you explicitate the metric for performing the contractions (also you can but do not need), or you sum over repated indices before calling TensorArray - this too is not necessary. It is true however that, when we want to verify things, doing it the way you present may be helpful to identify where is that things are not as expected.

TensorArray_Tetrads(reviewed).mw

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

@Age 

It was not a problem in your machine. The package was under a reorganization, it is adjusted now, you'd need to updated Physics again, as usual from the Maplesoft R&D Physics webpage.

With the reorganization, Tetrads is now visible when you enter with(Physics); and all of the 8 related tensors, the four that have tetradic indices as well as the four spacetime null vectors of the NP formalism are all now part of the subpackage. I reorganized accordingly the NullVectors.mw temporary presentation.

The idea for this week is to have the Ricci rotation coefficients and the Weyl NP scalars implemented. Let's see. All these GR developments are really nice and it is exciting how these otherwise complicated matters become so accesible. 

Thanks also for your feedback, Age, both for the comments about the package and the pointing to this Physics:-Print issue.

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

Hi

I do not see the system of polynomial equations you mention, nor I see the metric or related line element of the problem. If you could please clarify your post?

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

@NOh 
I don't know what you are doing but it works for me and without quoting:

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

@Alejandro Jakubi 

int(f(x),x);

type(%, 'int(function, name)');

                                             true

type(f(1), 'f(integer)')

                                    true

So, no design problem here. On the contrary, this is one of the fantastic things in the maple system: you can test if an object is a certain function with arguments of certain types. That is also what Andriy was testing. Now if you allow int(function,name) to be executed, you receive function*name, making the type test fail, of course. for that reason you quote it, as in 'int(function,name)' when passing it as a second argument to type. By the way this also works with indexed objects:

type(A[j], 'A[symbol]')

                                        true

and here again: if A is a table such that A[symbol] returns a value, for example '2', then you need to quote it when passing it as second argument to type, or otherwise the type test will not work - you would be testing if A[j] is of type '2'.

For details see the help page ?type,structured. Here I only wanted to clarify that  there is no design problem and this is not related to names that collide with procedures or alike. This has to do only with a way to perform type testing in the Maple system, very useful, and described in the help page mentioned.

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

@w-Teilchen 

It would be great to see your post (I'd suggest to presente it separated, as a new post, instead of as an answer to this post). I'm looking forward.

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

@Alejandro Jakubi 

The computation shown illustrates precisely how to perform the derivative, whether you call the matrix in the middle by A, by B or by Inverse(A) -- in all cases it is just a matrix. By the way, note also the Physics:-Inverse command, useful when working without indices and not actually with matrices.

Regarding working with linear algebra using tensor notation: I find this natural, specially if you want to compute regardless of the dimension, or taking into account symmetries under permutation of indices, etc.

Regarding working with linear algebra also without tensor notation and not with matrices, depending on what you want to do, using noncommutative variables implemented within the Physics package serves the purpose well. The implementation of Dirac's notation within Physics, for "quantum mechanics vector calculus", is an example.

My 2 cents ...

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

@Age 

Just to confirm that I tried now your examples using a more recent Physics library, that you can download from the R&D Maplesoft Physics page, and the results come all correct (the ones you expected).

Edgardo S. Cheb-Terrab 
Physics, Maplesoft