Re: What is acceptable for -ffast-math? (Was: associative law in combine)

Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[dewar]

a/2.0/2.0 will never yield zero if a is non-zero
a/4.0 may indeed yield zero if a is the smallest number

Indeed if one saw a/2.0/2.0 that's pretty peculiar, and it would not be
unreasonable to guess that the properly of not yielding zero was being
exploited :-)

Re: What is acceptable for -ffast-math? (Was: associative law incombine)

[Linus Torvalds]

On Wed, 1 Aug 2001 dewar@gnat.com wrote:
>
> a/2.0/2.0 will never yield zero if a is non-zero
> a/4.0 may indeed yield zero if a is the smallest number

Didn't you already agree that FTZ was acceptable even for a default mode,
much less -ffast-math?

The above rules, btw, only apply for exact IEEE math, and on a number of
machines you _will_ see zero for the first one.

So I don't think your example is a valid argument for not using the
optimization - even without -ffast-math.

			Linus

Re: What is acceptable for -ffast-math?

[Kai Henningsen]

dewar@gnat.com  wrote on 01.08.01 in < 20010801171343.5E207F2B65@nile.gnat.com >:

> a/2.0/2.0 will never yield zero if a is non-zero
> a/4.0 may indeed yield zero if a is the smallest number

If a is the smallest positive number in some floating point type, then I  
would certainly expect both a/2.0 and a/4.0 do the same thing - either  
yield zero or signal underflow.

And I certainly do not see how a second /2.0 can possibly change that.

> Indeed if one saw a/2.0/2.0 that's pretty peculiar, and it would not be
> unreasonable to guess that the properly of not yielding zero was being
> exploited :-)

What buggy idea of floating point does this?!

MfG Kai

Re: What is acceptable for -ffast-math?

[Jeremy Sanders]

On Fri, 3 Aug 2001 dewar@gnat.com wrote:

> <<would be a very useful one for the time consuming codes we run.
> >>
>
> Do you have measurements, or is this just a guess?

I'm afraid that's only a guess. If I get some time, I might look at some
of the assembly output and see how often this sort of code occurs.

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>  http://www-xray.ast.cam.ac.uk/~jss/
Pembroke College, Cambridge. UK   Institute of Astronomy, Cambridge. UK

Re: What is acceptable for -ffast-math?

[dewar]

<<If a is the smallest positive number in some floating point type, then I
would certainly expect both a/2.0 and a/4.0 do the same thing - either
yield zero or signal underflow.
>>

Please review the IEEE standard

(and please remember rounding!)

>>What buggy idea of floating point does this?!

Please make absolutely sure you understand the issue before deciding this
is a bug :-)

Re: What is acceptable for -ffast-math?

[dewar]

<<would be a very useful one for the time consuming codes we run.
>>

Do you have measurements, or is this just a guess?

Re: What is acceptable for -ffast-math?

[Kai Henningsen]

gdosreis@sophia.inria.fr (Gabriel Dos_Reis)  wrote on 01.08.01 in < 15208.15303.748602.738457@perceval.inria.fr >:

> | <<We're talking here of transformations which we do know able to
> | drastically change the results.
> | >>
> |
> | Words like drastically are not particularly helpful in this discussion,
> | plain "change" would be just fine.
>
> Do you think changing 0.125 to 0.0 is not drastic?

That depends entirely on the context, obviously. If it's a pixel position,  
for example, it's completely meaningless.

And anyway you needed to go right to the edge of the data type to do that.  
Calculating on the edge (and needing precision) is precisely the situation  
where you switch optimization *off*.

Sure, with 64 bit floats, that edge is a lot closer than with larger  
types. So?

Some work can't be done with those. So? Some work can't be done with 32  
bit floats, either. Or with ints. Nothing new about that.

MfG Kai

Re: What is acceptable for -ffast-math?

[Jeremy Sanders]

Just writing my thoughts here... I write (and use) a fair amount of
numerical code, mostly in the field of astronomical data
analysis/modelling. The proposals to rewrite slower expressions into
faster ones, eg

a/b/c -> a/(b*c)

would be a very useful one for the time consuming codes we run. This is
especially true for the C++ code I write, which needs significant
optimisation after inlining.

The point is, this would be an option which would be explicitly enabled,
and so there's no problem about breaking IEEE standards. In addition, if
one is writing code to handle numbers on the order of the maximum value in
a float/double, then there's a good argument that these types are
inappropriate. Losing, say, a factor of ten in any direction in a floating
point number wouldn't be a problem! As for the extra errors introduced by
rewriting expressions, this wouldn't be a problem: if one needs total
control over floating point, there's no reason to use -ffast-math!

Jeremy

-- 
Jeremy Sanders <jss@ast.cam.ac.uk>  http://www-xray.ast.cam.ac.uk/~jss/
Pembroke College, Cambridge. UK   Institute of Astronomy, Cambridge. UK