RE: [Algorithms] RE:acos function

[Michael P. <MPo...@cy...>]

Metrowerks's Codewarrior has a pragma that treats all floating point
numbers as floats regardless of declaration. Very handy on the PS2,
since doubles are emulated in software.

We found the simple solution to prevent accidental double usage was to
- ban math.h,
- declare all floats with the 'f' extension
- re-#define all the standard math functions to spit out an error if
they are used.
i.e.
	#define cos 	$" Don't use doubles!  Use: XXX"
	#define cosf 	$" Don't use cosf()   Include <XXXX.h> & use:
XXXX() "
	etc.

It's a shame there is no standard pragma's to warn when down-casting.

Cheers


-----Original Message-----
From: Andrew Jones [mailto:an...@em...]=20
Sent: Friday, November 08, 2002 1:25 PM
To: gda...@li...
Subject: Re: [Algorithms] RE:acos function


I suppose the minefield of floating point implementation issues in VC
could be tidied up a little. Just as an aside in case anyone hasn't
spotted the danger, (in the context of this thread), using 'improve FP
consistency' to shoehorn an 'ever-so-slightly >1.0' double value to an
'exactly 1.0' float value to get acos to return the expected result
could be very dangerous. It could hide those low precision bits until
some later date when the error gets just that bit bigger and finally
does kill your acos. Allthough having more control over your FP
precisions is a good thing, be aware that an awful lot of your FP
precision problems will simply surface less frequently at a different
precision. Changing the precision to sidestep problems like this is only
really an option if you can be sure that the dependant system is
somewhat tolerant of occasional NANs or whatever coming through. e.g.
historically some graphics hardware / API combinations can be
justifyably fussy about NANs coming through various bits of the
pipeline.

Andrew Jones
Empire Interactive


----- Original Message -----=20
From: "David Notario" <dno...@mi...>
To: <gda...@li...>
Sent: Friday, November 08, 2002 6:05 PM
Subject: RE: [Algorithms] RE:acos function


That would be great if VC respected the float casts with a default
compilation. Unfortunately, it doesn't.

With the Improve FP consistency option (/Op) it should do it, so you may
want to turn that on (or use the magic #pragma for just that piece of
code).

David

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: Friday, November 08, 2002 9:20 AM
> To: gda...@li...
> Subject: RE: [Algorithms] RE:acos function
>=20
> On a lot of compilers,
>=20
> #define acosf(blah) ((float)acos((double)(blah)))
>=20
> :-(
>=20
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
>=20
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
>=20
> > -----Original Message-----
> > From: Nick Pelling [mailto:NPe...@cl...]
> > Sent: 08 November 2002 15:19
> > To: 'gda...@li...'
> > Subject: RE: [Algorithms] RE:acos function
> >
> >
> > Don't forget acosf(). Though, to be honest, my first instinct would=20
> > be to avoid using either acos() or acosf() if at all possible. :-)
> >
> > Cheers, .....Nick Pelling.....
> >
> > -----Original Message-----
> > From: Stein Pedersen [mailto:st...@in...]
> > Sent: 08 November 2002 14:51
> > To: gda...@li...
> > Subject: FW: [Algorithms] RE:acos function
> >
> >
> >
> > We had a similar problem which would only occur in the realease=20
> > build of our game because of a compiler optimisation that caused a=20
> > float not
to
> > be truncated. The float value was excactly 1.0 but it's double value

> > was slightly greater and was just left on the FPU stack.
> >
> > Stein