]]>

Having found [$]y[$] you now need to solve for the true anomaly [$]\theta[$], How?

[$]\tan^2(\theta/2) = a \tan^2(y/2)[$] where [$] a = (1+\varepsilon)/(1 - \varepsilon)[$].

What's [$]\theta[$]?

you keep changing this, there have been at least 3 different expressions since I started to answer it

[$]\tan^2(\theta/2) = a \tan^2(y/2)[$] so [$]\theta=\pm2\arctan\left[\sqrt{a \tan^2(y/2)}\right][$], with the addition of some multiple of [$]2\pi[$] if necessary for physical reasons

Statistics: Posted by ppauper — May 21st, 2017, 12:34 pm

]]>

[$]\tan^2(\theta/2) = a \tan^2(y/2)[$] where [$] a = (1+\varepsilon)/(1 - \varepsilon)[$].

What's [$]\theta[$]?

Statistics: Posted by Cuchulainn — May 21st, 2017, 12:19 pm

]]>

Traden4Alpha wrote:Kepler is not good enough for GPS -- they need Einstein to get the accuracy.

Interesting. Do you have a link?

Actually, up at Myvatn was a retired American prof talking about his day with Atlas (D?) in the 50s/60s and the very issue of time synchronisation. They let the satellite broadcast the 'time'. There is no day or night up there.

The showstopper if relativity is ignored in GPS:

The Article wrote:

If these effects were not properly taken into account, a navigational fix based on the GPS constellation would be false after only 2 minutes, and errors in global positions would continue to accumulate at a rate of about 10 kilometers each day! The whole system would be utterly worthless for navigation in a very short time.

Statistics: Posted by Traden4Alpha — May 21st, 2017, 1:01 am

]]>

http://www.nytimes.com/1990/01/23/scien ... gewanted=1

Done in 1609, Kepler's fakery is one of the earliest known examples of the use of false data by a giant of modern science.

Statistics: Posted by Cuchulainn — May 20th, 2017, 8:13 pm

]]>

outrun wrote:It's just that in real life we have many body problems, the physics is the same, but the solutions have to be numerical instead of analytical, right?

yes; Kepler is 2-body, but probably a good approximation as gravity decays awful fast.

My take: Kepler's equation is a luvly ellipse but it must be approximated numerically?

You might like this, NASA's low accuracy approximations for the positions of the planets with the method described in this dos:"Keplarian elements" (your equation is in it at 8.36) here are the numerical factors (table with coeficients)

Statistics: Posted by outrun — May 20th, 2017, 7:58 pm

]]>

It's just that in real life we have many body problems, the physics is the same, but the solutions have to be numerical instead of analytical, right?

yes; Kepler is 2-body, but probably a good approximation as gravity decays awful fast.

My take: Kepler's equation is a luvly ellipse but it must be approximated numerically?

Statistics: Posted by Cuchulainn — May 20th, 2017, 7:44 pm

]]>

Kepler is not good enough for GPS -- they need Einstein to get the accuracy.

Interesting. Do you have a link?

Actually, up at Myvatn was a retired American prof talking about his day with Atlas (D?) in the 50s/60s and the very issue of time synchronisation. They let the satellite broadcast the 'time'. There is no day or night up there.

Statistics: Posted by Cuchulainn — May 20th, 2017, 7:38 pm

]]>

]]>

]]>

]]>

Kepler is not really useful for practical orbits, more a math trick. E.g. when I worked on light intensity forward curves for energy company I simple downloaded a table with 4000 oscillation terms from Nasa which would correct for all the platens wobbles many decades out.

Well, there goes 400 years of physics down the drain in one sentence.

I was always led to believe GPS satellites are based on Kepler's laws. Or are we talking about different things?(?)

One of my uni buddies was designer at Motorola, he said Classical Mechanics worked fine.

Statistics: Posted by Cuchulainn — May 20th, 2017, 7:25 pm

]]>

Cuchulainn wrote:Traden4Alpha wrote:Yes it's a very interesting approach.

And now that I see this was a physics problem all along -- having bounds on the parameter space and geometric/physical interpretation of the solution space that would not occur in the full math problem -- I can see why negative eccentricity and multiple solutions was not what you sought.

What is curious to me is that as a numerical computation, Bessel and iteration both share the property of requiring convergence time. Of course they differ in that Bessel's terms can be computed in parallel whilst iteration is strictly sequential.

I think the parallel solution will be slower..Code:`double KeplerExact(double eps, double x)`

{

int N = 1e4; // Truncated series

double result = 0.0;

double tmp;

for (int n = 1; n < N; ++n)

{

tmp = 2.0*boost::math::cyl_bessel_j(n, n*eps)/n;

result += tmp*std::sin(n*x);

}

result += x;

return result;

}

That seems likely.

And even if one Bessel call were as fast as one iteration, there'd be the simple issue with all parallel vs. sequential versions of an algorithm in which parallel consumes more total computational resources but it can have lower latency to a solution.

If one must solve Kepler's in a microsecond, a GPU version of Bessel might be best. But if one needs to continuously solve a million Kepler's per second, then iteration might offer better throughput.

So where's the specifications document?

One example that immediately springs to mind is to compute the position of the Earth relative to the Sun in heliocentric polar coordinates [$](r,\theta)[$] at any time [$]t[$] since perihelion.

Statistics: Posted by Cuchulainn — May 20th, 2017, 7:13 pm

]]>

]]>

Traden4Alpha wrote:Yes it's a very interesting approach.

And now that I see this was a physics problem all along -- having bounds on the parameter space and geometric/physical interpretation of the solution space that would not occur in the full math problem -- I can see why negative eccentricity and multiple solutions was not what you sought.

What is curious to me is that as a numerical computation, Bessel and iteration both share the property of requiring convergence time. Of course they differ in that Bessel's terms can be computed in parallel whilst iteration is strictly sequential.

I think the parallel solution will be slower..

Code:

`double KeplerExact(double eps, double x)`

{

int N = 1e4; // Truncated series

double result = 0.0;

double tmp;

for (int n = 1; n < N; ++n)

{

tmp = 2.0*boost::math::cyl_bessel_j(n, n*eps)/n;

result += tmp*std::sin(n*x);

}

result += x;

return result;

}

And even if one Bessel call were as fast as one iteration, there'd be the simple issue with all parallel vs. sequential versions of an algorithm in which parallel consumes more total computational resources but it can have lower latency to a solution.

If one must solve Kepler's in a microsecond, a GPU version of Bessel might be best. But if one needs to continuously solve a million Kepler's per second, then iteration might offer better throughput.

So where's the specifications document?

Statistics: Posted by Traden4Alpha — May 20th, 2017, 4:43 pm

]]>