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)