On 2011-12-20 16:04:05 +0100, David Brown wrote:
> But I think compiler flags are a suitable choice as they make it
> easier for the user to apply them to the program as a whole.
This can be done with pragmas too.
> An example of this would
> be "-fshort-double" or "-fsingle-precision-constant". These specifically
> tell the compiler to generate non-conforming code, but are very useful for
> targets that have floating-point hardware for single-precision but not for
> double-precision.
If the developer wants to allow the user to choose the precision
(or the type), he can do something like:
#ifndef FP_TYPE
/* default */
# define FP_TYPE double
#endif
typedef FP_TYPE fp_t;
or something more restrictive. At least, it is clear that the choice
of the precision is allowed in the program.
> >>I would still say that most floating point code does not need such
> >>control, and that situations where it matters are rather
> >>specialised.
> >
> >I think that if this were true, there would have never been an
> >IEEE 754 standard.
> >
>
> The IEEE 754 standard is like many other such standards - it is very useful,
> perhaps critically so, to some users. For others, it's just a pain.
>
> I work with embedded systems. [...]
OK, so I would say that embedded systems are very specific and do not
concern most floating-point code. However it's a pity that people from
the embedded world didn't take part of the discussion of IEEE 754R.
IIRC the only discussions about embedded systems concerned FTZ, and
IEEE 754-2008 has something similar (substitute / abruptUnderflow).
> My believe is that for the great majority of users and uses, floating point
> is used as rough numbers.
But the IEEE 754 standard is also a benefit for them (reproducibility
of the results, portability, detection of potential problems thanks
to exceptions...).
> People use them knowing they are inaccurate, and almost never
> knowing or caring about exactly how accurate or inaccurate they are.
> They use them for normal, finite numbers. Such users mostly do not
> know or care what IEEE 754 is.
Still, -ffast-math can be inappropriate for them due to enabled
options like -fassociative-math. Exception handling can allow them
to detect bugs or other problems.
> That's probably one of the most common mistakes with floating point
> - the belief that two floating point numbers can be equal just
> because mathematically they should be.
No, the problem is more than that, it's also about the consistency.
Assuming that
int foo (void)
{
double x = 1.0/3.0;
return x == 1.0/3.0;
}
returns true should not be regarded as a mistake (even though it might
be allowed to return false for some reasons, the default should be
true).
> This "bug" is not, IMHO, a bug - it's a misunderstanding of floating
> point.
Despite some users who may misunderstand FP, it's really a bug that
affects correct code. And the fact that some users do not understand
FP is not a reason to make their life difficult.
> Making "-Wfloat-equal" a default flag would eliminate many of these
> mistakes.
No. This bug is due to the extended precision. Floating-point code
affected by rounding errors vs discontinuous functions (such as ==)
will have problems, whether extended precision is used or not.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
