On Thu, Apr 27, 2017 at 3:03 AM, James Cameron <quozl at us.netrek.org> wrote: > On Thu, Apr 20, 2017 at 04:08:21PM +0200, Michael Bax wrote: >> > Those constants aren't accurate to the limit of a float. E.g., >> > (float)M_PI/2.0 == 1.57079637f but (float)M_PI/2.0 != 1.5707964f. >> >> printf( "%i\n", (float) ( M_PI/2.0 ) == 1.5707964f ); >> >> 1 > > Yes, so too is (1.57079637f == 1.5707964f), on gcc 4.8.4 x86_64. Indeed it is. It takes 9 decimal digits to represent all floats (24 bit mantissa) with complete accuracy. And 1.5707964f is only eight. But of course 9 digits are the max, any given number might be accurate with fewer. 1f == 1.0000000f after all and that's just one digit. I tested M_PI/2.0 to see how many digits it needed and came up with the max of 9. I must have tested incorrectly somehow because clearly it's 8. Though I still say use 9 digits, because then you know it will be right no matter what number. >> > In a less fractured code base, there should have been some utility to >> > do this so it wouldn't keep getting re-implemented. >> >> Funny that you should mention that… :-) >> https://github.com/mrbax/netrek-server/commit/5bcf5964eef8c545c3dda43a16b28ffc60fcd7b0 > > Almost like. As author of to_dir, naming loss is felt, apparently > some attachment still ... and the constant 40.743665f is a bit opaque. > > Otherwise grand. ;-) I agree. Nicely consistent. Suggest making: #define RAD_TO_BRAD (float)(128f/M_PI)