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)