Re: [AD] a fix struct for dallegro

[torhus@xxxxxxxxxx]

Peter Wang wrote:
> On 2007-04-16, Chris Robinson <chris.kcat@xxxxxxxxxx> wrote:
> > On Monday 16 April 2007 04:23:35 pm Peter Wang wrote:
> > > The problem here is not float vs fixed but between different angle
> > > representations.
> >
> > Which is inherent in float vs fixed. There's no standard math functions for 
> > floats that use binary angles, and there's no Allegro math functions for 
> > fixed types that use radians.
>
> I forgot about that.  These trigonometric functions should be named
> fix* to distinguish them.
>
>    fix cos(fix x)           { return x.cos(); }
>    fix sin(fix x)           { return x.sin(); }
>    fix tan(fix x)           { return x.tan(); }
>    fix acos(fix x)          { return x.acos(); }
>    fix asin(fix x)          { return x.asin(); }
>    fix atan(fix x)          { return x.atan(); }
>    fix atan2(fix x, fix y)  { return x.atan2(y); }

Ok, I can rename them to fixcos, fixsin, etc, and just remove the member 
functions.  Then they would overload the fixed versions, like this:

fix fixcos(fix);
fixed fixcos(fixed);

Is that a good idea, or could it cause confusion?  Seems ok to me, 
global overloads are very common in C++ too.  Chris, is this okay with 
you, or do you still think I should drop the whole thing?

And then I'll just leave out all operator overloads taking floating 
point, leaving three versions of each operator:

fix opAdd(fix);
fix opAdd(int);
// just a convenience, so you don't need a cast to avoid the compiler 
warning
fix opAdd(long);

And another thing.  The docs state that the range of fixed is [-32768, 
32767].  But ftofix doesn't accept lower values then -32767.  In case 
I'm going to add checks for range in the fix struct, I need to know 
what's correct.