On the ps2 one tip is make sure you output assembly in your release build and do a 'find in files' for occurences of the instruction for converting double to float. (I think it was cvt.d) This lets you track down places where you are accidently using float. This can happen when you instantiate a float value as
0 instead of  0.0f
----- Original Message -----
From: Michael Pohoreski
To: gdalgorithms-list@lists.sourceforge.net
Sent: Friday, November 08, 2002 6:46 PM
Subject: RE: [Algorithms] RE:acos function

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.
        #define cos     $" Don't use doubles!  Use: XXX"
        #define cosf    $" Don't use cosf()   Include <XXXX.h> & use: XXXX() "

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


-----Original Message-----
From: Andrew Jones [mailto:andrew@empire-interactive.com]
Sent: Friday, November 08, 2002 1:25 PM
To: gdalgorithms-list@lists.sourceforge.net
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 -----
From: "David Notario" <dnotario@microsoft.com>
To: <gdalgorithms-list@lists.sourceforge.net>
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).


> -----Original Message-----
> From: Tom Forsyth [mailto:tomf@muckyfoot.com]
> Sent: Friday, November 08, 2002 9:20 AM
> To: gdalgorithms-list@lists.sourceforge.net
> Subject: RE: [Algorithms] RE:acos function
> On a lot of compilers,
> #define acosf(blah) ((float)acos((double)(blah)))
> :-(
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> > -----Original Message-----
> > From: Nick Pelling [mailto:NPelling@climax.co.uk]
> > Sent: 08 November 2002 15:19
> > To: 'gdalgorithms-list@lists.sourceforge.net'
> > Subject: RE: [Algorithms] RE:acos function
> >
> >
> > Don't forget acosf(). Though, to be honest, my first instinct would
> > be to avoid using either acos() or acosf() if at all possible. :-)
> >
> > Cheers, .....Nick Pelling.....
> >
> > -----Original Message-----
> > From: Stein Pedersen [mailto:stein@innerloop.com]
> > Sent: 08 November 2002 14:51
> > To: gdalgorithms-list@lists.sourceforge.net
> > Subject: FW: [Algorithms] RE:acos function
> >
> >
> >
> > We had a similar problem which would only occur in the realease
> > build of our game because of a compiler optimisation that caused a
> > float not
> > 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