@Rouben Rostamian

Reliable = not wrong results. And unreliable for me means the opposite. Regarding "always" returning a solution (when a solution exists), that is entirely another game. We know that neither computers nor humans can solve all the problem for which a solution exists, because, simply put, people don't know how to do it - or in the case of a computer because a known method is not implemented. That does not make software unreliable.

Beyond semantics, I've said in this forum, several times: to be useful, criticism regarding something that could work better is respectful and has contents. So, no sarcasm, no irony, no disqualifications, and, no matter how "easy" the problem could be, the "criticism" shows how to solve the problem or a reference where something of the like is found. When these conditions are met, we frequently code the method, sometimes right away. The software grows, and everybody benefits from the comment.

The Physics Updates - these include, on equal footing, updates to the Differential Equations (symbolic code) and Mathematical Functions - are not included in a current release. They are advanced in time, the updates and fixes present in the version under development, that will be the new release in the future, but tested and merged into the current release. In the example of this post, I see "eval(diff(u(x, t), x), x = 1)", a minor thing, that makes Maple 2018.0 fail in solving the problem, showing the error message posted. With the Physics Updates, that problem disappears, it is fixed in the version under development, and these Updates make this fix available to everybody right away instead of having to wait for the next release.

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

@Rouben Rostamian

I find pdsolve very reliable. Not returning u = 0 is not a sign that it is otherwise. Think about. All linear homogeneous equations have the (so-called: trivial) solution u = 0. What would be the purpose of returning that? What would be your impression if, at any linear homogeneous problem posed, pdsolve and dsolve say "well, here is a solution: u = 0". Well, I'd think "we all know that, come on, I'm obviously interested in a solution that is not trivial".

More specifically on the reliability of software, If you find bugs, that all software have, either they are fixed sufficiently fast, so that their occurrences happen rarely, or they are not fixed fast enough, in which case I'd agree with you, such a software would not very reliable. But that is not the case of pdsolve.

It is also the case that this PDE problem posted is solved entirely by pdsolve. For that, you need to have installed the latest Physics Updates (version 34) - see the Maplesoft R&D Physics webpage. and follow the Installation instructions on the linked webpage. The Physics Updates is now distributed through the MapleCloud. As is known, this Updates package contains the advanced version of updates for Physics, Differential Equations and Mathematical Functions.

Attached is a worksheet with this PDE problem and its solution as returned by pdsolve, tested with pdetest.

Download PDE_solved.mw

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

@nm 

The link you mention is 8 years old. Nowadays filenames with blank spaces are 100% standard.

Note as well that the main technical reason pointed out everywhere in this link you posted, is that filenames with blank spaces require special care when used from a command line. That is a terminal in UNIX/Linux or a DOS command line window. Perhaps that is the reason. I am skilled with UNIX, and also with DOS, and Macintosh is UNIX, but I almost never use a command line, and in Macintosh, when I use it, I use tab to retrieve file names, that handles blank spaces perfectly well. And then GUI programs are for me simpler, I learn how to use them rapidly, and work with them orders of magnitude faster. I tend to believe that the vast majority of users also access this Maple update not from a command line, but through the MapleCloud, or the Maple input using PackageTools:-Install. Eventually, through an OS file manager, that in all the three OS are GUI style and handle spaces in filenames natively and flawlessly.

Nowadays this feels to me more like a matter of preference. Although not the same issue, it somehow reminds me of the preference for working with 1D or 2D Math input. Many people prefer 1D Math input. After working 15 years with 1D Math input, since 2008 I prefer 2D Math input.

Still, as said, if someone points to a concrete problem, a real one in installing the Physics Updates due to the space between the two words, I'm open to reviewing this.

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

@nm 

... I have a more recent Maple (the version under development), so I don't see this problem you are showing. I imagine that, in 2018.0, what you show is related to the MapleCloud issue: the "Physics Updates" package is installed one subdirectory down, in toolbox/2018, and the PackageTools commands assume this extra layer (2018, indicating the release where this update works) does not exist - they scan for packages just below toolbox. For example, try PackageTools:-ListInstalledPackages()  and see whether it reports Physics Updates - it does not.

Until this issue with the MapleCloud and related PackageTools gets fixed, I suggest you to just give a look at the date returned by Physics:-Version(), March 28, versus the date of the latest update shown in the MapleCloud, 2018-04-13.

Regarding the name: I understand linux handles blank spaces in filenames out-of-the-box. It is more readable in general. So unless there is a more concrete problem that you could mention, I prefer it this way.

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

@digerdiga 

3. After doing F[mu,nu]  :=  D_[mu](A[nu](X)), you do not have F[1,2] returning the component 1,2, to mention but one, or any of the things I show in the worksheet I posted. Of course if you enter F[mu,nu] you get what you assigned to it but what is the value of that if F[alpha,beta] is not equal to D_[alpha](A[beta](X)). Try type(F[alpha, beta], Physics:-Library:-PhysicsType:-Tensor). It returns false. Try with mu,nu, it returns true, all this is natural, but definitely not what you intended, which is to define a tensor F[mu,nu] whose components are given by D_[mu](A[nu](X)) and the definition is not valid only for the values mu and nu of its indices. If you still think it works then please before posting more on this take a minute reading the help page for Define. And no, it does not expand when you write g_[mu, nu].F[`~mu`, `~nu`] because you assigned to F[mu, nu], not to F[~mu, ~nu].

Regarding your not numbered question on how comments work, digerdiga, please don't take me wrong but this is a forum for questions that are beyond the documentation, or at least these are the questions I'm happy to spend my time answering.

4. Yes it is mandatory to use the argument (X). But again this is something you can check by yourself: enter without the argument X. What you see? Have you checked that. The rhs is equal to zero, because the derivand does not depend on the coordinates.

On your other not-numbered question, with this you exhausted the ones that I answer but you could check by yourself (you really need to get into checking things before asking): if you define F[mu,nu] correctly, of course F[~mu, ~nu] works.

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

@Arny 

Hold on: in the Mathematica input/output you also integrate over p1, not just p3. In the maple input/output you integrate only on p3. Therefore these two things cannot be compared. And your image does not show any Mathematica output for the integral, only the input. In addition, in your last worksheet attached you use some nonexisting commands DotoProduct and CrossProduct.

So go back to the worksheet you attached first, correct your wrong integration range replacing the duplicated range on p__3y by one in p__3z, add integration ranges for each of the three p1__<x,y,z>, and you now have the problem set. Then expand the integral, using expand, to remove occurrences of unit vectors. Tackle now with 'value' and after a little while you receive "undefined", which in my opinion is correct, or maybe I am missing something here that I don't see what would that be.

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

@digerdiga 

1) When working with a curved space, the signature is relevant with regards to transformations of coordinates from the curved spacetime to a locally Minkowski orthonormal system of references (this transformation is key in general relativity, the resulting system of references is also called the tetrad system). So depending on whether the signature is (+ -) or (- +) the transformation (or tetrad, see the help page ?Physics,Tetrads,e_) will be different, as well as the corresponding Minkowski metric. So, no, the signature is not irrelevant. Having said that, if you do not work with tetrads, setting the signature here makes no difference.

2) The notation and conventions used in this package are as said in the help pages: we follow the Landau book. In this book (and actually in most general relativity textbooks - albeit not all of them), what distinguishes the Christoffel symbols of the first and second kind is the covariant/contravariant character of its first index, not the third one.

3) No, an assignment as in F[mu,nu] := D_[mu](A[nu](X)), does not work as you intended, at all. That is at the core of why the computations in you worksheet don't work. And no, using assignment for the purpose you want was never intended to work. More important, and general advice when using computer algebra: read the documentation. Never use a command without giving at least a look at its help page, and in the one for Define this is explained: you do not define the components of a tensor using assignment. Instead, you use an equation definition.

4) As you realize in your comment, D_[~mu](A[mu](X)) with the contravariant index in the covariant derivative operator, is, of course, the same as D_[mu](A[~mu](X)) with the contravariant index in A. Now, in Physics, there is the friendly approach where in cases like these you can enter both indices covariant (or contravariant) and the system will make one of them be the other way around so that you have one covariant the other contravariant. But you can always indicate this, for example entering D_[~mu](A[mu](X)) or D_[mu](A[~mu](X)), in which case the system will never change your choice. In your example you are using a definition F[mu,nu] = D_[mu](A[nu](X)), so when you compute the trace there is no way the system could guess that you want the first or the second index contravariant. Still, if you want to have the trace expressed using the contravariant components of A, one way of achieving that is to tell that to the system. Make your definition of F explicit regarding A being contravariant. For instance as in F[mu, nu] = g_[nu, alpha]*D_[mu](A[~alpha](X)); Define(%);  and now when you input F[trace] you will see it expressed as you indicated, using the contravariant components of A.

PS: I wonder what is the meaning you intend with your several uses of ??, ??? and the like. Mind you, they do not look polite.

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

Hi Digerdiga

It is always helpful to upload a worksheet with your input/output. For that purpose you can use the green arrow; note as well that you can write the text directly on it, and when you upload it you can request to show the contents, besides you sharing the worksheet so that others can reproduce the problem and give suggestions. 

Without a worksheet, to try to help you implies on more work, it is prone to mistakes through copy and paste, etc. Could you please upload your worksheet?

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

@rahinui 

Thanks for your kind comments :) Just to say that the fix for Maple 2018 is already uploaded to the MapleCloud, distributed within the Physics Updates, that contains updates to all of Physics, Differential Equations and Mathematical Functions.

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

@peter137 

I implemented yesterday the d straight and in bold, and included this change in the Physics Update - the last one for Maple 2017, and also in "The First Physics Update for Maple 2018".

I thought, like you, that not bold is closer to ideal, but distinguishing what you see from d(x) only by straight versus italic could be missed easily. The grey is in use for inert, everything that starts with %, and at this moment we distinguish between %d_(x) an d_(x) precisely using grey for the former. Using a completely different colour could also help - I considered that - but we already have several colours (commutative, anticommutative, noncommutative and inert). I prefer to not add one more colour only for this.

The collision with bold for vectors (the default is an arrow, but someone could choose bold as you correctly pointed out) is something to think, maybe using a different font could help removing bold. Anyway the improvement is in place, refining it, if necessary, is for a second round.

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

@peter137 

Download d-ronde_or_d-straight_(II).mw

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

Hi Arny

It would be convenient if you attach the worksheet to your post to avoid copy & paste prone to mistakes - so, could you please post it? Thanks.

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

@Louis Lamarche 

You are confusing products of kets of one Hilbert space with tensor products of kets of different Hilbert spaces. You only have tensor products between objects belonging to different Hilbert spaces.

The reviewed version of your worksheet is attached at the end, and here are the notes I intercalated within your input/output lines:

To work with the right convention for the Dagger of a tensor product shown above you need to update your Physics library from the Maplesoft R&D Physics webpage.

Next:

Next:

Summarizing, Louis, in order to work with tensor products:

1. You need to indicate the (disjointed) Hilbert spaces of your problem and which operators act on each of these spaces
2. Be careful with the convention when taking Dagger.
3. Manually reordering Kets and Bras of a single Hilbert space, for which an inner product is already defined and therefore the operands in these products do not commute, is wrong, even if you happen to formulate the problem in a way that results in what you wanted to obtain. Helpful regarding such reorderings is the routine Physics:-Library:-Commute that receives A and B and tells you whether they commute.

Disjointedspaces_(reviewed).mw

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

@Louis Lamarche 

The Maplesoft R&D Physics webpage distributes a Physics update for Maple 2017.3 that contains this new library mentioned in my comments to your post. From the worksheet you posted, I understand you are using Maple 2017, so this update should work for you, ie you can use it and test it.

Note three things anyway.

1. A relevant part of my previous comment is that what you show makes sense if and only if each of the kets a_j and b_k , totaling 8 kets, all of them belong to different Hilbert spaces. In your post you say that the a_j are the orthogonal kets of a single Hilbert space, that is not correct, and this is something not related to the dimension of the tensor product of spaces being n x m, not n + m.
2. In my previous comment, and in the Physics updated for Maple 2017 distributed at the Maplesoft R&D Physics webpage, I am using Dagger(Ket(A) x Ket(B)) = Bra(B) x Bra(A), where x here represents "tensor product". Although this is correct, because the Hilbert spaces A and B are disjointed, and Kets and Bras from the subspaces A and B commute. the notation used for tensor products that nevertheless preserves ordering, is: Dagger(Ket(A) x Ket(B)) = Bra(A) x Bra(B). This is known as the violation of the swapping rule of the Dagger operation and is the standard notation used for tensor products. The reason for this notation, particularly relevant in quantum information where the ket labels are not displayed, is that in states like |0, 1> and <0, 1|, you must preserve the ordering of the  Hilbert subspaces, or otherwise, the notation is ambiguous. So, using the standard notation, if |0, 1> = |A, 0> x |B, 1>, then Dagger(|0, 1>)  = <0, 1| = <A, 0|, <B, 1|, not <B, 1|, <A, 0|. As said this Maplesoft project is not finished and implementing this standard notation to represent the Dagger of a tensor product "violating the swapping rule" is still not in place. 
3. By the way, the 'hide the ket label', is in place in the Physics update distributed for Maple 2017. Try Setup(hidketlabel = true), then enter Ket(A, 0) and you will see |0,> instead of |A, 0>. Remember anyway that you need to input the label A. The label is only hidden from the display.

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

@John Fredsted 

It is standard in computer algebra the concept of "special values", ie values for which you have the function evaluates automatically to something that is not just echoing your input unchanged. So for instance sin(-x) maps automatically into sin(x) and every single function, from BesselJ to AppellF1, will return in terms of some special values when the experience (subjective) with them tells it is better to return the special value. Of course some people would prefer to never evaluate any function to anything, but then, just my opinion, you would only get a nice text editor, not a math computing system.

So no, it would be non-sense to me to return Christoffel symbols for a Minkowski space, they are all equal to 0 (the special case were we do not want to go inert), and in the same line it would be just wrong to return zero for the Schwarzschild metric because they are not equal to zero.

Now on your manner of presenting this question, and I've seen this in several of your posts. You seem to ask things indirectly, parabolically. I prefer a more direct question. If your issue is that you want to work with an abstract tetrad, just ask that, and the answer to that is: no, we do not want to go that way because the resulting complexity of even simple algebraic computations can become enormous, making things rapidly untractable - instead of what we have today where you can compute in almost any imaginable scenario. My point here, however, is that instead of asking that, so that I could answer to that, with you I frequently go two to three rounds of answering this, then that, then this, then that, to finally discover that what you wanted to ask is actually something else, basically you seem to want to state that you would have designed this code differently. And to that I would just answer "all OK with that", instead of spending time answering questions that are not actually what you are interested on.

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