ecterrab

8136 Reputation

20 Badges

14 years, 328 days

MaplePrimes Activity


These are replies submitted by ecterrab

@mthkvv 

The current v.687 contains further developments, not rollbacks. Define handles `μ` and `~μ` in definitions, `μ`, `~μ` are now valid indices, mu and `~μ` are not considered repeated indices when in a product, only the pairs [mu, ~mu] and [`μ`, `~μ`] respectively are. All that is new. And you cannot sum over repeated indices for objects before defining them as tensors, that is old.

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

@mthkvv 

Sorry but that won't happen. As said, that would complicate the code unnecessarily: in the output, we already have excellent typesetting, so all this is about how the input looks. But for the input, as said right-click and converting to 2D-Math input achieves an even better result: a greek letter and presented as a superscript, with no ~.

The only situation where we need to handle `~μ` is when you are passing a tensorial equation "to define" a tensor and you want to see ~mu as a Greek letter (by typing ~mu, then pressing escape and chosing mu you will receive `~μ` that looks like at ~ followed by the greek leter). In that case, the right-click & convert will not produce ~mu as a superscript because at the input level (before pressing enter in a call to Define) that object is not yet a tensor, and so the index is not typeset as a tensor index (greek and superscript, while keeping its semantics equal to ~mu).

That exception is now handled since v.686 in the only place I can think it happens, which is when passing a tensorial equation to be defined using Define, as in your original example. In the latest example you posted, anyway you cannot perform a sum over repeated indices of an object that is not a tensor (will be after you press enter in that call to Define), so your example is invalid regardless of any typesetting issue.

Just try it. Type ~mu, then right-click and convert the tensorial expression to 2D Math input and you will see it working.

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

@mthkvv 

..hmm you meant `μ` and `~μ`, not mu and ~mu, which are automatically, always summed, unless you explicitly ask otherwise.

A bad news and a good news. The bad one: mu and `~μ` are not seen as "repeated indices" but for the context of Define, which handles the defining expression only once and can workaround the computer syntactic detail.

But there are too many places in the package where the convention is that repeated indices are A and ~A, not A and `~&A;`. So at this point that has no simple solution (and going all the way to implement that may end up introducing a level of complexity in the package that is not a good idea).

The good news is that to have a nice display, you do not need what you are asking. Instead: right-click the input line and select the menu 2-D Math -> Convert To -> 2-D Math Input, and not only you will see ~mu written with a Greek letter but also as a superscript (instead of this Fortranish tilde).

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

@mthkvv 

In v.686 the two problems are addressed: you can now define a tensor, using mixed covariant and contravariant, in a curved spacetime and when the tensorial expression involves objects that are not actually tensors, as is the case of d_[nu](v[~mu]) in the definition that you posted as problematic. Additionally, from v.686 on, things like `μ`, that also appear from times to times in the GUI and are indistinguishable from the greek letter mu, as well as `~μ`, are both valid tensor indices in equal footing with mu and ~mu.

This pic, an excerpt of your last worksheet (_3.mw) shows how both things work now, 

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

@mthkvv 
You say "Yes, I did definitions with different indices intentionally.". It is good, we caught one more exception. The problem being that, when you convert to d_, the first term of the covariant derivative becomes d_[nu](v[~mu]) and that is not a tensor. The code assumes it is and, when normalizing the defintion, just substitutes ~mu by mu to get the covariant form, which of course is correct if an only if you are substituting in a tensor. The code got fooled by your input because the left-hand side of the definition is a tensor OK (of type Physics:-Library:-PhysicsType:-Tensor) but - as said - the first term after converting to d_, is not. The fix is simple, check that the right-hand side is also a tensor in the current coordinates (command Physics:-Library:-IsTensorInCurrentCoordinates).

That said, I wonder your intention ... what was it? Regarding ~mu, this is a longstanding issue with the GUI: it sometimes transforms `mu` into `μ` and `~mu` into `~μ`. I will adjust the code to understand `μ` and `μ~` as valid as  `mu` and `~mu` indices.

Note after the post: but mu and `~μ` are not considered repeated indices when in a product. Only the pairs [mu, ~mu] and [`μ`, `~μ`] are.

About your other post regarding the font: it is also a known issue. Acer gave you a good suggestion to address the problem locally in your machine, until Maplesoft fixes the problem.

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

@mthkvv 

NOTE ADDED May 25: the issue mentioned below as 'to be fixed later today', is also resolved by installing the Maplesoft Physics Updates v.686 or newer.
 

The computations are performed correclyt if in the definitions you use all free indices covariant , as you see below, which is your worksheet but entering the defnitions of the tensors dv1, dv2, dv3 and dv4 using indices all covariant. I will fix the problem that arises when you Define with one index covariant the other contravariant, and post the fix in the nex version of the Physics Updates later today.

 

To the side, note that to get the matrix form there is a shortcut: [] produces the all covariant components and "[~]" the all contravariant ones. Finally, maybe you noticed maybe not: you can always post your worksheet with the contents itself visible, and you can insert text in the document: in any line (or open one above or below the cursor) by pressing Ctrl + T (or Command + T in Macintosh) or by clicking 'Text' in the context bar.

 

with(Physics)``

Setup(mathematicalnotation = true)

Coordinates(X = [t, r, theta, phi])

{X}

(1)

g_[sc]

Physics:-g_[mu, nu] = Matrix(%id = 18446744078394656638)

(2)

Define(v[mu] = (Vector[row](4, {(1) = (r-2*m)/r, (2) = 0, (3) = 0, (4) = 0})))

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(3)

v[]

v[mu] = Array(%id = 18446744078294210310)

(4)

Define(dv1[mu, nu] = `▿`[nu](v[mu]))

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], dv1[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(5)

dv1[]

dv1[mu, nu] = Matrix(%id = 18446744078413868318)

(6)

Define(dv2[mu, nu] = convert(`▿`[nu](v[mu]), d_))

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(7)

dv2[]

dv2[mu, nu] = Matrix(%id = 18446744078383960062)

(8)

Define(v[mu] = (Vector[row](4, {(1) = 1, (2) = 0, (3) = 0, (4) = 0})))

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(9)

v[]

v[mu] = Array(%id = 18446744078383946438)

(10)

Define(dv3[mu, nu] = `▿`[nu](v[mu]))

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], dv3[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(11)

dv3[]

dv3[mu, nu] = Matrix(%id = 18446744078310429630)

(12)

Define(dv4[mu, nu] = convert(`▿`[nu](v[mu]), d_))

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], dv3[mu, nu], dv4[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(13)

dv4[]

dv4[mu, nu] = Matrix(%id = 18446744078431803862)

(14)

``

NULL


 

Download cov_diff_bug_3_(reviewed).mw

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

@vv 

There is only one Maple syntax indeed. Essentially, whatever you write using that syntax when the display is 1D, you can write when the display is 2D with the same meaning. But then there is also (as the 15th order term in a series expansion ...) a very small number of things that change, mostly related to not leaving a space between operators, as for example the one you mention. However, you see: with so many years using Maple, programming in Maple, and having used 1D display of input as well as 2D display of input, I never - ever -  crossed with this example you are mentioning now, simply put: wasn't even aware of it. If something, your example basically makes my point, in my opinion.

With all due respect, honest respect I have for you, vv, to think otherwise, that because of this example, then what you write when using 1D display doesn't work when using 2D display seems to me a blatant misrepresentation of the actual situation. People need to understand how this works 99.999 % of the time. It may even be useful to collect the minuscule exceptions, but not useful to think they are the issue here.

Most of the confusion about this, in fact, I think, derives from the mistake of calling these modes "1D input" and "2D input" when in reality they mean "1D display" and "2D display" of the same sequence of characters being input. Plus the fact that when using "2D display" of the input, you can, additionally, optionally, also use a space to represent multiplication, as we do with paper and pencil.

One last comment for Janhardo: what I meant by Maple syntax is not about programming. Maple syntax is just how we express mathematics on the worksheet. So 1+1 is Maple syntax, f(x), diff(f(x), x), all that is Maple syntax. 

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

 

@Steve Roper 

Just to suggest you upload the worksheet contents using the green arrow so that the contents becomes visible in Mapelprimes, without having to manually download and open the worksheet.

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

Not sure what the problem is. You do have the latest version, 669, that is what the first line shows, then you install again version 669 (that is what Physics:-Version(669) does, it install the version, that in your case it is already installed). So the first thing is that you do not need to install the Updates again.

Independent of that, I performed the same two input/output (I use macintosh) but didn't receive a kernel connection lost. I suppose clicking the restart icon should fix a problem of that kind (it is the icon to the right of the bug icon). If that doesn't work I would try closing and reopening Maple.

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

Hi

Would it be possible to post the problem itself within a worksheet? Something where it is clear what you intended to do, what is the input that you would have imagined to accomplish that, what is what you would expect to receive. Frequently, problems like this, with a clear prescription, are excellent sources for development (or otherwise, if the solution already exists, to tell you how to get that result).

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

 

@Steve Roper 

Unfortunately, form times to times development happens too fast and I forget about the help pages. I need to do one for ChangeCoordinates. Sorry for that. Meantime, its syntax is kinda natural: the same as ChangeBasis.

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

@Pascal4QM 

Indeed, defining A, B and C as noncommutative objects in general works fine for this. The possibility of defining commutator and anticommutator algebra rules for them also allows for flexible manipulation of their products. Note, additionally, that it is possible to be more specific in this case, by using matrix instead of Matrix, as discussed in Sec.5 of the Maple help page "Physics, Mini-Course". That automatically defines these as noncommutative objects, the same way quantumoperators are.

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

@Steve Roper 

with(Physics:-Vectors)

In your first post you asked about square of the norm of

a*`#mover(mi("r"),mo("∧"))`+b*`#mover(mi("θ",fontstyle = "normal"),mo("∧"))`+c*`#mover(mi("φ",fontstyle = "normal"),mo("∧"))`

_phi*c+_r*a+_theta*b

(1)

And this following result is correct because the three unit vectors form a basis and are orthogonal.

(_phi*c+_r*a+_theta*b).(_phi*c+_r*a+_theta*b)

a^2+b^2+c^2

(2)

In your second post you asked about something different

_i*x+_j*y+_k*z

_i*x+_j*y+_k*z

(3)

Of course the square of the norm of this one is

(_i*x+_j*y+_k*z).(_i*x+_j*y+_k*z)

x^2+y^2+z^2

(4)

BUT: if you express this result in spherical coordinates you have

ChangeBasis(_i*x+_j*y+_k*z, spherical, alsocomponents)

r*_r

(5)

r*_r.(r*_r)

r^2

(6)

That is understandable, because

ChangeCoordinates(r^2, cartesian)

x^2+y^2+z^2

(7)

So you see (4) and (6) are of course the same result. Summarizing: all these results are correct, and in (2) to expect something different is wrong.

 

You can see the same going the other way around: from shperical to Cartesian. Take the vector of your original post and change the basis to Cartesian

_phi*c+_r*a+_theta*b

_phi*c+_r*a+_theta*b

(8)

ChangeBasis(_phi*c+_r*a+_theta*b, cartesian)

(a*cos(phi)*sin(theta)+b*cos(phi)*cos(theta)-c*sin(phi))*_i+(a*sin(theta)*sin(phi)+b*cos(theta)*sin(phi)+c*cos(phi))*_j+(-sin(theta)*b+cos(theta)*a)*_k

(9)

So now you have your orginal vector in the Cartesian orthogonal basis. Take now the scalar product

((a*cos(phi)*sin(theta)+b*cos(phi)*cos(theta)-c*sin(phi))*_i+(a*sin(theta)*sin(phi)+b*cos(theta)*sin(phi)+c*cos(phi))*_j+(-sin(theta)*b+cos(theta)*a)*_k).((a*cos(phi)*sin(theta)+b*cos(phi)*cos(theta)-c*sin(phi))*_i+(a*sin(theta)*sin(phi)+b*cos(theta)*sin(phi)+c*cos(phi))*_j+(-sin(theta)*b+cos(theta)*a)*_k)

(a*cos(phi)*sin(theta)+b*cos(phi)*cos(theta)-c*sin(phi))^2+(a*sin(theta)*sin(phi)+b*cos(theta)*sin(phi)+c*cos(phi))^2+(-sin(theta)*b+cos(theta)*a)^2

(10)

simplify((a*cos(phi)*sin(theta)+b*cos(phi)*cos(theta)-c*sin(phi))^2+(a*sin(theta)*sin(phi)+b*cos(theta)*sin(phi)+c*cos(phi))^2+(-sin(theta)*b+cos(theta)*a)^2)

a^2+b^2+c^2

(11)

You see you again arrive at (2) For experimentation, you can try changing also the vector components, not just that basis, so that instead of seeing theta and phi in (9) you see x, y, z.

ChangeBasis(_phi*c+_r*a+_theta*b, cartesian, alsocomponents)

((x^2+y^2)^(1/2)*a*x-(x^2+y^2+z^2)^(1/2)*c*y+b*x*z)*_i/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))+((x^2+y^2)^(1/2)*a*y+(x^2+y^2+z^2)^(1/2)*c*x+b*y*z)*_j/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))+((x^2+y^2)^(1/2)*a*z-b*(x^2+y^2))*_k/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))

(12)

(((x^2+y^2)^(1/2)*a*x-(x^2+y^2+z^2)^(1/2)*c*y+b*x*z)*_i/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))+((x^2+y^2)^(1/2)*a*y+(x^2+y^2+z^2)^(1/2)*c*x+b*y*z)*_j/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))+((x^2+y^2)^(1/2)*a*z-b*(x^2+y^2))*_k/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))).(((x^2+y^2)^(1/2)*a*x-(x^2+y^2+z^2)^(1/2)*c*y+b*x*z)*_i/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))+((x^2+y^2)^(1/2)*a*y+(x^2+y^2+z^2)^(1/2)*c*x+b*y*z)*_j/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2))+((x^2+y^2)^(1/2)*a*z-b*(x^2+y^2))*_k/((x^2+y^2+z^2)^(1/2)*(x^2+y^2)^(1/2)))

((x^2+y^2)^(1/2)*a*x-(x^2+y^2+z^2)^(1/2)*c*y+b*x*z)^2/((x^2+y^2+z^2)*(x^2+y^2))+((x^2+y^2)^(1/2)*a*y+(x^2+y^2+z^2)^(1/2)*c*x+b*y*z)^2/((x^2+y^2+z^2)*(x^2+y^2))+((x^2+y^2)^(1/2)*a*z-b*x^2-b*y^2)^2/((x^2+y^2+z^2)*(x^2+y^2))

(13)

simplify(((x^2+y^2)^(1/2)*a*x-(x^2+y^2+z^2)^(1/2)*c*y+b*x*z)^2/((x^2+y^2+z^2)*(x^2+y^2))+((x^2+y^2)^(1/2)*a*y+(x^2+y^2+z^2)^(1/2)*c*x+b*y*z)^2/((x^2+y^2+z^2)*(x^2+y^2))+((x^2+y^2)^(1/2)*a*z-b*x^2-b*y^2)^2/((x^2+y^2+z^2)*(x^2+y^2)))

a^2+b^2+c^2

(14)

``

 

Download scalar_product_in_spherical_coordinates.mw


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

 

@Axel Vogt 

No, the definition is not the same, neither there is only one in use in the literature. Maple and Mathematica definitions are related via JacobiSN(a, z) = JacobiSN[a, z^2]and the two solutions shown are actually the same after you translate from Maple to Mathematica. By the way entering convert("JacobiSN[a, z^2]", FromMma) shows how the definitions in both systems are related.

The issue mentioned by Rouben Rostamian is standard in Computer Algebra differential equations solvers when the DE has  square roots of the unknown of the problem. That results in branches directly in the DE. Semantics to the side, I tend to think of these problems as: remove the square root and you have a well-defined problem, otherwise, the symbolic solution will be correct only in some region of the complex plane. Basically, most of the time the symbolic solution you receive is the one that corresponds to the DE after removing those square roots. In this example, take for instance ODE^2, then call dsolve, and there you see the JacobiSN solution.

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

@deniscr 

Curious how minds interpret written language differently ... It confused me your comment about inner products. From your last reply, you only wanted to have one of the Killing vectors (tensors of 1 index) defined as a tensor. Do it the usual way using Define, for example with the first one:

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

1 2 3 4 5 6 7 Last Page 1 of 43