John Fredsted

2228 Reputation

15 Badges

17 years, 164 days

MaplePrimes Activity


These are replies submitted by John Fredsted

@acer: My 'trick' targeting for Omega only, relied of course on a visual inspection of the expression in question. If some factors of Omega are added here and there, then I have no doubt that the method will generally fail.

PS: Just to make sure: No offence taken :-).

@taro: I am no expert on these matters, and do thus not feel competent to say something in general. But for the present concrete example, the following construction might give you an indication on how to avoid, or at least minimize the risk of, getting session-dependent results:

expand(select(has,numer(a),Omega)/denom(a))*remove(has,numer(a),Omega);

It does not depend on any ordering of the factors in the numerator, because it uses the select command to single out the factor that is to be divided by the denominator.

@acer: Rest assured, no offence taken. And from what taro writes above in his reply to you, your concerns seem justified.

@acer: You have a point, of course. I also worried that perhaps session-dependency (leading to different ordering of the multiplicands, say) might be a problem, but I settled on my proposed pragmatic solution because I felt that was in the spirit of OP.

@taro: Happy to hear that.

@ecterrab: I have downloaded the latest update and verified, as asserted, that `.`and `*` act identically for the quantity in question.

Thanks for the pointers on the two Library procedures. I was not at all aware of the existence of such a Library. I have just looked it up in the help pages, and wow!: "96 programming commands and 58 specialized Physics types".

The design plan laid out in your last paragraph sounds very interesting. I will look forward to see how the items a.) to c.) come to be implemented, for it might make the previously mentioned migration to the Physics environment an obvious thing to do.

A comment concerning the "psi -> Vector[row/colum](4, symbol = psi)"-transformation: If not already on the table, it would be nice if the user has the option to choose the naming of the components, as it should not, I think, be fixed by the name of abstract object itself.

PS: The coupling of spinor fields to gravity requires the spin connection. Perhaps this is not the correct place for mentioning it, but this connection does not seem to be comprised by the Physics[Tetrads]-package. Is it something that is on the drawning board, at least for the minimal spin connection that is uniquely determined by the vierbein? I am aware that there is a SpinConnection command in DifferentialGeometry[Tensors], but the formalism (using soldier forms) seems quite foreign to me as a physicist.

PPS: Concerning the anticommutator of the Dirac matrices, it suddenly hit me whether we could strike a compromise by having it equal 2 times the metric times some identity map, the latter perhaps pretty-printed as some boldface 1. That would be completely satisfactory to me, while still being in abstract notation.

@ecterrab: Thanks for your feedback and your improvements to the Physics package (I have downloaded the latest update); I actually thought the thread was dead.

Concerning 1.): Nice that the algebra rules are now loaded automatically. As previously stated, though, I still find it unnatural that the anticommutators of Dirac gamma matrices result in scalarly quantities. But I guess we will not be able reach consensus on that matter.

Concerning 2.) Thanks. Using * instead of . works as asserted. I guess * applies here because the quantities are scalarly in the matrix sense?

Concerning 3.) I look forward to see how the implementation turns out. In particular, I would like to see/learn how to get from the abstractly entered Dirac mass term in 2.), where psi is not specified as some column-vector, to some concrete mass term with explicit components of some column-vector.

Concerning "hitting road-blocks" and "non-intuitive formalism": Perhaps this wording of mine is a bit to harsh. But an example of the latter, is the above-mentioned issue of scalar- contra matrix-valuedness; perhaps it will get clearer to me with the pending resolution of 3.)? And the former, I think, mainly refers to often getting lost in the help pages; as you know, I have on several occasions called for some text book material on the Physics package, in order to obtain an overview - a 'vantage point' from which to navigate the details.

@wilk007: Happy to hear that.

@Preben Alsholm: I had a hunch that my approach was somewhat primitive; your solution is much better, of course.

@mapleatha: Happy to hear that.

@ecterrab: Thanks for your answer.

For working with the Standard Model and related, not least with the Dirac-, Weyl-, and Majorana Lagrangians, I use procedures and functions of my own pedigree. From the Physics package, I use only its ability to work with anticommuting numbers, i.e., Grassmann numbers; this feature is highly appreciated, though. Several times I have contemplated migrating these functionalities of mine to the realm of the Physics package, but every time these attempts have failed because I hit seemingly roadblocks, or simply get frustrated over what appears to me to be non-intuitive formalism.

Let me illustrate it with a simple thing: the mass term of the Dirac Lagrangian: Entering it as

Setup(anticommutativeprefix = psi):
Dagger(psi) . Dgamma[~0] . psi;

makes no sense, as psi is moved to the left of Dgamma[~0]; understandably so, I guess, as psi is not specified as a column vector, although specifying it as such while keeping Dgamma[~0], produces a result no more useful. Then we can try something like the following:

Setup(
   anticommutativeprefix = psi,
   Dgammarepresentation = chiral
):
spinor := Vector(4,symbol = 'psi');
Dagger(spinor) . rhs(Dgamma[~0][matrix]) . spinor;

This, at least, produces a sensible mass term, but only at the expense of the 'unnatural' construction rhs(Dgamma[~0][matrix]).

Perhaps I am missing something? Perhaps issues like this are not present in the Standard Model package of Physics under way?

@Pascal4QM: Thanks for that suggestion as well, but sorry to say, that is the very one I deemed "unnatural" in my reply above to Christopher. Anyway, it should not be necessary to have to specify a specific representation, as the anticommutator in question vanishes in any representation, as also mentioned in my reply to Christopher.

@Pascal4QM: I agree, my original formulation could be misread to mean zero as the zero scalar, rather than zero as the zero matrix. I apologize.

Even though g_[mu,nu] is certainly a tensor, of rank two, there is no problem in having that metric and the four matrix-valued elements of any representation of the Dirac algebra, respectively, play together. It is just the first equation on the page https://en.wikipedia.org/wiki/Dirac_algebra. Of course, in curved spacetime, where the metric differs from the Minkowski metric, the gamma matrices must be defined via a socalled vierbein, but that is only technicalities.

As to your question, the problem posed is not really part of some larger calculation of mine, but rather an issue in and by itself.

@Pascal4QM: Thanks for your suggestion. But here applies somewhat the same objection as for the suggestion by Christopher: the statement should really be a matrix statement, not a scalarly statement. And something like

with(LinearAlgebra):
with(Physics):
Setup(algebrarules = {%AntiCommutator(Dgamma[mu], Dgamma[nu]) = 2*g_[mu,nu]*IdentityMatrix(4)});

does not work. But, to reiterate my comment to Christopher: Perhaps I am simply missing something. Perhaps I am messing different aspects together, an abstract algebra and representations of that algebra, say.

@Christopher2222: Thanks for your suggestion. But the vanishing of the trace of the anticommutator is a much weaker condition than the vanishing of the anticommutator itself, the former being a scalarly statement, the latter being a matrix statement. What I would like is for

Simplify(AntiCommutator(Dgamma[1],Dgamma[2]));

to equal a (4x4) matrix with zero entries only, simply because that anticommutator vanishes in any representation of the Dirac algebra (in 4-dimensional spacetime). One could possibly do something like

Setup(Dgammarepresentation = chiral);
rhs(Simplify(AntiCommutator(Dgamma[1][matrix],Dgamma[2][matrix])));

but that appears to me unnatural due both to the presence of rhs, and for having to choose some specific representation.

Perhaps I am simply missing something. Perhaps I am messing different aspects together, an abstract algebra and representations of that algebra, say, but on this aspect of Dirac matrices, the behaviour of the Physics package appears to me non-intuitive.

2 3 4 5 6 7 8 Last Page 4 of 68