On Mon, Aug 20, 2007 at 10:18:33AM -0400, Andy Dougherty wrote:
> On Sun, 19 Aug 2007, chromatic wrote:
> 
> > On Sunday 19 August 2007 17:32:01 Andy Dougherty wrote:
> > 
> > > On Sat, 18 Aug 2007, [EMAIL PROTECTED] wrote:
> > 
> > > > Log:
> > > > Added FLOAT_IS_ZERO() macro to parrot/misc.h for comparing floats to
> > > > zero. This may need some attention on platforms where INTVAL isn't four
> > > > bytes, but I did the best I could.
> > >
> > > Stepping back a moment, I don't think this is a good idea.  The original
> > > code,
> > >   f == 0.0
> > > is perfectly clear and quite well-defined.  I think the compiler warning
> > > should simply be turned off.  It isn't doing anything useful here.
> > 
> > For the zero case or for all floating point comparisons?  If it's not 
> > useful 
> > for the zero case, can we disable it for just that one?
> 
> I don't know how to disable it for just some cases. Broadly speaking, I 
> see three use cases in the source:
> 
>       f == 0.0
>       $1 == $2  (in cmp.ops, for example)
>       miscellaneous
> 
> Your trick (extended, if needed, by clever Configure.pl probes) will 
> cleverly suppress the warning for the f == 0 case, while still retaining 
> the exact comparison.  (Hmm.  Not sure about negative zero offhand.  I'd 
> have to test.)

I'm not convinced that it's great. It assumes

1: that the floating point representation is all bits zero [Alphas can run in
   non IEEE, IIRC]
2: that there is an integer type exactly the same size as the floating point
   type. (Larger and smaller will both have problems)

For most machines both assumptions are valid. But it's possible to build Perl
5 in configurations where it's not valid. For example, long doubles on Sparc
Solaris (and IIRC OS X on x86, surprisingly) are 16 bytes. long doubles on
most IEEE platforms would be even more fun (12 bytes, where actually only 10
are significant, and 2 are noise)

I can't think of a clean, portable, efficient way to test that a floating
point variable is zero other than == 0.0;

Nicholas Clark

Reply via email to