I tried ttmath, but no luck.

Regarding ttmath, I had to specify to skip using the assembly file.

#define TTMATH_NOASM 1 

#include <ttmath/ttmath.h>
typedef ttmath::Big<TTMATH_BITS(256), TTMATH_BITS(512)> MyBig;

It's working sort of… it draws the right shape but the precession angle for Newtonian gravity (where alpha = beta = 1) is far too large – it should be close to zero.

The code (not including the ttmath library) is at:

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

The ttmath library is at:

https://www.ttmath.org/​

P.S. It's absolutely glacial in terms of speed. )

OK, so I've found that decreasing the time step dt gets the negative precession under control. For instance, using a time step of dt = 1, there is -96 arc seconds of precession per Earth century. Where dt = 0.1, the angle is -11 arc seconds of precession. I'm currently running the numbers for dt = 0.01, but I'm certain that the angle will be like -O(1). I really like this ttmath library.

I mean, this has to be so, since that's what the double-precision version of the code does.

Ok, so I set alpha and beta using the equations and Big numbers, and the precession is about the same as for the double version. Now to do the conversion to float to see what happens. Unfortunately it takes about 4 hours to calculate a full orbit LOL

after I’ve gotten that answer, I’ll make the big nums twice as big as they are now, to see if there’s any big difference.

taby said:
Unfortunately it takes about 4 hours to calculate a full orbit LOL

To integrate a single planet? :O

Now i know why they need a whole moth to make a mandelbrot zoom video.
The assembly optimizations would surely be worth it.

Maybe try another library. The GNU library from the list felt promising to me.

Yeah, and the thing is… I'm using the smallest possible ‘big’ number, which has 64 bits for exponent and 64 bits for mantissa. Pardon me if my terminology is incorrect.

So, once I'm doing this one last test, I'll bump the big number size to 128 bits for the exponent and 128 bits for the mantissa.

I'm pretty excited. Thanks for all of your help, y'all.

P.S. To be fair, I am using a constant time step of 0.01 seconds.

P.P.S. ttmath works just fine, and so what if it's a bit slow…. as long as it reproduces the results (which will be ready in a few hours).

OK, everything works as expected when using

typedef ttmath::Big<1, 1> MyBig;

Now to try

typedef ttmath::Big<2, 2> MyBig;

In case you're wondering, converting to float still produces 46 or so arc seconds of precession per Earth century. So, that ‘coincidence’ transcends the number library… basically, I told you guys that I didn't need a number library, but you wouldn't listen! LOL I'm just kidding! Thanks again to everyone for their insight. It's super appreciated.

OK, so looking into the ttmath source code, I see that they manually create a double from the big num, then just casts that double as a float. So, basically it's no wonder why it comes up with the correct solution.

The latest ttmath version is at:

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

The pre-ttmath version is at:

https://github.com/sjhalayka/mercury_gr/tree/8094347b05b3f0230014aababb4916b72e1a3361

I moved the source around a bit.

The ttmath version (which I'm abandoning) is at: https://github.com/sjhalayka/mercury_gr_ttmath​

The main version is at: https://github.com/sjhalayka/mercury_gr​

I'm currently trying to get the normalized_double_to_float function in main.cpp to work properly.

float normalized_double_to_float(const double d)
{
	float tempf = 0.0f;

	//static const float max_val = nextafterf(1.0f, -1.0f);
	//static const double dbl_max_val = nextafter(1.0, -1.0);

	while (tempf < d && tempf < 1.0f)
		tempf += nextafterf(tempf, 1.0f);

	return tempf;
}

taby said:
OK, so looking into the ttmath source code, I see that they manually create a double from the big num, then just casts that double as a float.

Maybe you use it somehow wrong. Why should they do this? Eventually only to continue with regular CPU instructions, but you are supposed to do all high precision math before that point?

Well, i have just wasted the second day to hunt a ghost. My tool reports errors on the BVH build. If i run the BVH build again after that, no more errors. But it computes the exact same data es before, it says. And i can't figure out wtf is going on. >:(