With GCC there's a fourth option.
 
4> Hack the compiler source to disallow double operations unless explicitly switched on :)
 
-----Original Message-----
From: Jamie Fowlston [mailto:jamief@qubesoft.com]
Sent: 11 November 2002 14:30
To: gdalgorithms-list@lists.sourceforge.net
Subject: RE: [Algorithms] RE:acos function - double to float tip

there are various options:
 
- hack all doubles into singles (the option we were using, as other options weren't available early on, and this breaks all libs compiled with proper doubles)
- default to single accuracy floats (reduces the number of unexpected double operations)
- warn when doubles are used (didn't work last time i tried to use it, about a year ago :)
 
but i suspect this is getting a bit platform specific :)
 
jamie
-----Original Message-----
From: gdalgorithms-list-admin@lists.sourceforge.net [mailto:gdalgorithms-list-admin@lists.sourceforge.net]On Behalf Of Wayne Coles
Sent: 11 November 2002 14:09
To: 'gdalgorithms-list@lists.sourceforge.net'
Subject: RE: [Algorithms] RE:acos function - double to float tip

Erk, if that's the same option we used I'd advise against the 'default to floats' setting, nightmare breakage on some functions (using printf was scary with that option enabled). Although some people found it useful, I suppose it's a 'try it and see' option :)

 

-----Original Message-----
From: Jacob Turner (Core Design Ltd) [mailto:JacobT@Core-Design.com]
Sent
:
11 November 2002 13:29
To: 'gdalgorithms-list@lists.sourceforge.net'
Subject: RE: [Algorithms] RE:acos function - double to float tip

 

Also you can use the SN compiler options to warn about such things OR auto convert to floats rather than doubles

-----Original Message-----
From: Justin Heyes-Jones [mailto:justin.heyesjones@genepool-uk.com]
Sent: 11 November 2002 11:07
To: gdalgorithms-list@lists.sourceforge.net
Subject: Re: [Algorithms] RE:acos function - double to float tip

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 -----

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.
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: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).

David

> -----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
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