So, i guess you use 100 bits for all numbers except gravity*, where you use 24.
And maybe i'm willing to accept this. I mean, gravity just causes problems in science it seems, and accepting paradox relativity or quantum entanglement wasn't easy either. Who knows what's next.

But then i'm still worried about this term in the equation:

double beta = sqrt(1.0 - Rs / distance);

Because if distance gets small, there is a square root of a negative number before distance gets zero, causing a div by zero. And both of that seems wrong.

Is this why they say there are two singularities in Schwarzschilds equation?
One at the center of the black hole, and another at the event horizon?

Would this mean that any matter has black hole properties? The center of any particle is a tiny black hole? :D

*) You talked about quantized gravity, but i see it's velocity which is affected, not acceleration.

Your guess is as good as mine. :)

The whole code is at:

https://github.com/sjhalayka/mercury_gr_boost_mp​

I'm not assuming that 24 bits is the magic number, so I'll be running the simulation for 20 through 30 bits, to see what's the highest value.

taby said:

The full code is at:

https://github.com/sjhalayka/mercury_gr

If you want people to play with your code atleast make sure that when they grab the code there is a way to build and run it.

taby said:
As for the character of the function that calculates angle from bits, it is not monotonically decreasing like you are saying. 20 bits gives an angle of 5.7, 24 bits gives an angle of 43.5, and 30 bits gives an angle of 14.8. That's not monotonic. Sorry man, but you're not right all of the time.

That's flawed reasoning. You're referring to the final value of a complex calculation, whereas I'm referring to the ability of floating point numbers to approximate the real numbers. The distance between neighboring floating point values decreases monotonically, just as 2^(-x) decreases monotonically. For a non-trivial calculation, especially one involving numerical integration or iterative calculations, the result could be anything. The values you are getting are the result of accumulated truncation error, which could produce a value too high or too low. Whether it is too high or low is impossible to predict without doing the calculations.

Here's an example to illustrate that different precision can affect the result of a series of calculations up or down from the exact value:

// Real numbers (exact)
1.24 + 2.5 + 3.74 = 7.48

// Rounded to nearest 0.1
1.2 + 2.5 + 3.7 = 7.4

// Rounded to nearest 0.2
1.2 + 2.6 + 3.8 = 7.6

Depending on if we round to the nearest 0.1 or 0.2, we can get a value that is above or below the exact result. Therefore, in general, no conclusions about precision can be made based on the final value of the calculation compared to the exact value. So, I repeat, this entire thread is nonsense based on faulty reasoning and a lack of understanding of floating point numbers.

Look, I don’t know why you’re not clueing in. I know that the floats are a subset of the doubles. That was the whole point of my original question.

I expect the user to know how to compile a few cpp files. It's like cl *.cpp or whatever.

In fact, I recommend not playing with the code.

taby said:

I expect the user to know how to compile a few cpp files. It's like cl *.cpp or whatever.

Thats not something you should assume specially not when you are relying on external libs

I have it all set up now to take only two initial conditions, the aphelion distance and the orbit speed at aphelion.

It does not work. God is the biggest trickster of them all.

Well, it’s strange. There is a pattern. However, I have many numbers to crunch. I’ll be back in a week.

JoeJ…. Your premonition about calculating many bit / angle pairs at once on the CPU cores: Is there an easy way to do double-sized floating point numbers in OpenGL 4.3 compute shaders?