Bug#153022: Partial support of rounding modes
Re Daniel Martin's message:
The (latest public draft of the) ISO C standard says:
[#7] Each of the macros
FE_DOWNWARD
FE_TONEAREST
FE_TOWARDZERO
FE_UPWARD
is defined if and only if the implementation supports
getting and setting the represented rounding direction by
means of the fegetround and fesetround functions.
So, it is not a bug to define only FE_TONEAREST (as done on the ARM).
> alpha, hppa: every rounding mode produces the same result as
> FE_ROUNDTONEAREST (possible bug?)
I don't think this should be regarded as a bug (at least with the
current standards), in particular because an implementation isn't
required to support all the rounding modes and it is not possible
to indicate which rounding modes are supported for each function.
Even with FE_TONEAREST, the returned result isn't always the result
that is nearest to the exact value (we call that "exact rounding")
for the elementary functions.
Note also that on x86, even though directed-rounding results may
be different from FE_TONEAREST results, the rounding direction is
sometimes wrong (for elementary functions).
----------------------------------------
Re Philip Blundell's message
With the ARM FPA, it would have been possible to support all the
rounding modes dynamically by adding tests and using operations in
the 4 rounding modes in the code (unless this can be optimized).
Of course, this would make code larger and slower. So, a compiler
switch could have been a solution so that the users could choose
between optimized code and results rounded in the right direction.
However, if this is likely to be dropped in the near future, it
isn't worth to change anything.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Reply to: