## 2228 Reputation

17 years, 164 days

## Thanks...

@acer: When posting, I had a hunch that the introduction of `type/T` could be avoided, but did not know how to. Thanks for the satisfies-solution.

You certainly have a point: As each addend of expand(expr) contains either alpha or beta, the evalindets-construct will not combine anything.

## Sluggish...

@Preben Alsholm: I have not received the error you mention, but I do experience some sluggish behaviour when trying to load MaplePrimes in Firefox. It seems to be related to some TLS-handshake business, but I am not at all sure.

## Nicely spotted...

@Preben Alsholm: Indeed, a square of 1/r is missing in the last term, compare equation (28) here (where u = 1/r). With such a square, Maple is no longer able to find an exact, closed formula for r(phi) as I previously thought it was [although I was then surprised because I was under the impressing that that was not possible].

## Embarrasing...

@Rouben Rostamian: You are absolute right concerning the mass: it is, of course, the mass of the Sun. I don't know what I was thinking yesterday. The equivalence principle dictates that the trajectory of any test particle (Mercury may here be considered one) in some gravitational field does not depend on the mass of that test particle. Thanks for spotting that embarrasing error of mine.

## I agree...

@JoeyJoe: The physical constants G and c are certainly correct, I agree. The mass is 3.3*10^23 kg, having just consulted a difference souce as well. The perihelion distance 4.6*10^10 m is also correct. So now only h needs to be verified; I do not readily know where to look up that number.

## Correct numbers?...

@JoeyJoe: Are you sure that M, h, and r0 are all correct? I ask because executing

```ode := diff(1/r(phi),phi\$2) + 1/r(phi) - G*M/h^2 - 3*G*M/(c^2*r(phi)):
sol := dsolve({ode,r(0) = r0,D(r)(0) = 0},r(phi));
sol := eval(sol,{
M  = 1.99*10^30,
G  = 6.67*10^(-11),
h  = 2.7*10^15,
c  = 3.0*10^8,
r0 = 4.6*10^10
});```

does not result in an ellipse due to presence of cosh rather than cos:

Update: The mass of Mercury is only 3.3*10^23 kg, see here. Your parameter for r0 is correct, compare same page. What about h?

## Manuals...

@JoeyJoe: You are welcome.

Instead of online courses, I would like to direct you to the manuals 'User Manual' and 'Programming Guide' downloadable from Maplesoft Documentation Center, https://www.maplesoft.com/documentation_center/. Note that the manuals can take some time to download, due to their size.

## Using exact solution...

Warning: With the error spotted by Preben Alsholm, the code below is no longer correct, and (now consistent with my recollections) Maple is no longer able to find an exact, closed formula for r(phi).

@JoeyJoe: Even though Preben Alsholm has answered your query, which concerned a numerical solution, here, just for the fun of it, a method using the exact solution of the differential equation [I am actually surprised that it can be found]:

```ode := diff(1/r(phi),phi\$2) + 1/r(phi) - G*M/h^2 - 3*G*M/(c^2*r(phi)):
sol := eval(dsolve({ode,r(0) = 2/3,D(r)(0) = 0},r(phi)),{
M = 1,
G = 1,
h = 1,
c = 8
}):
assign(sol):
plots:-polarplot([r(phi),phi,phi = 0..10*Pi]);
# The perihelion shift after n revolutions, for n = 0..4
seq(fsolve(r(phi) - 2/3,phi = 2*n*Pi..2*(n+1)*Pi) - 2*n*Pi,n = 0..4);```

The perihelion shift per revolution is thus 0.1526..., in accordance with what Preben finds.

## No Maple 16...

@smiths: On that matter I cannot, unfortunately, help you as I have no installation of Maple 16 running. I hope others will weigh in.

## Can't reproduce...

When I execute solve({1<x or x<3 or x<5}) in Maple 2017, I get

which is correct, as it is equivalent to {x = x} because the output means {x = x} or (as a union) {x < 5}.

## I see you point...

@ecterrab: I see you point, having already somewhat anticipated it with the "But then again, there might be a problem" of my former comment. But I had the following idea (perhaps equally untenable): What about defining a protected object, designated with this Open Face I, with a type that depends, loosely speaking, on the enviroment in which it is situated? An object for which, say, I * x = I . x = x if considered acting as a matrix, and I(x) = x if considered acting as a map?

Thanks for pointing me to the Open Face palette. Normally, I have none of the palettes shown on screen; in fact, I think I have never entered anything using them. But there is a problem: it seems I cannot enter any of the symbols from that specific palette.

## Best solution...

@Robert Israel: That solution is the best one yet, I think; thumbs up.

PS: It is a long time ago that I have seen you post here at Mapleprimes. I hope you will continue posting.

## Use the quiet option...

@mapleatha: To avoid the message, use the quiet option:

`PDEtools:-declare(y(t),prime=t,quiet);`

## Thanks...

@ecterrab: Concerning your post, see my comment there.

PS: Just to make sure that we are not taking past each other: When I refer to the (minimal) spin connection, I do not think of "spinor notation" (with for instance tensors written using twice the number of indices, loosely speaking), but of the connection making it at all possible to couple spinors to the gravitational field, at the classical level as well.

## Identity map rather than identity matrix...

First of all, thanks for taking serious my suggestion as put forward in the thread you mention. Two comments, though:

1a.) Instead of an identity matrix, I ended up thinking more of an identity map, compare the PPS in the reply Very interesting, implemented simply as I:x -> x (here, I stands for Identity, as I do not presently know how to type the 'double bar identity' symbol). This map is algebraic too, and as far as I can tell, its contents is not displayed either. With such a map, I(psi) would immediately display as psi, while the Dirac anticommutator algebra would still display as 2 times the metric times this I. But then again, there might be a problem: The anticommutator acting on a spinor would, I guess, have to entered as

`AntiCommutator(Dgamma[mu],Dgamma[nu])(psi)`

perhaps unnatural, rather than

`AntiCommutator(Dgamma[mu],Dgamma[nu])*psi`

1b.) Having such an identity map instead of the identity matrix, the latter implemented using the deprecated (right?) matrix constructor, would, I think, also be a conceptually cleaner solution.

2.) I think it would be more natural/intuitive if this identity element was not to be appended manually, as it is done in Eq. (6), but was present from the outset in Eq. (1).

PS: How is the 'double bar identity' symbol actually entered in Maple?

 1 2 3 4 5 6 7 Last Page 3 of 68
﻿