Re: [lmi] Unit test for C99 round()

[Greg Chicares]

On 2008-06-04 13:18Z, Vadim Zeitlin wrote:
> On Wed, 04 Jun 2008 02:20:12 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> So, yes, it would be interesting to see what 'round_to_test.cpp' spews
> GC> out on GNU/Linux.
> 
>  The output is small enough compressed to be attached to this email, so
> I tried to do it but it bounced back with "The message's content type was
> explicitly disallowed" so now I resend this message without the attachment
> which I'm going to send to you directly.
> 
>  Once again, sorry but I simply didn't have time to look at the
> failures details at all yet so it's perfectly possible that they're due to
> something trivial.

This failure strongly suggests ruling out decimal scaling, and
floating types other than plain 'double':

Rounding   (double)-5.00000000000000000e-01
  to 0 decimals
  with style r_downward
  hex value of input    is: 000000000000e0bf / bfe0000000000000
  hex value of expected is: 000000000000f0bf / bff0000000000000
  hex value of observed is: 0000000000000080 / 8000000000000000

 fixed:
  input     -0.50000000000000000
  expected  -1.00000000000000000
  observed  -0.00000000000000000
  abs error 1.00000000000000000
  rel error 1.00000000000000000
  tolerance 0.00000000000000022
 scientific:
  input     -5.00000000000000000e-01
  expected  -1.00000000000000000e+00
  observed  -0.00000000000000000e+00
  abs error 1.00000000000000000e+00
  rel error 1.00000000000000000e+00
  tolerance 2.22044604925031308e-16

And this, at the beginning, indicates that there's no problem
when the FPU is globally set to "nearest" rounding mode:

  Default style synchronized to hardware mode:
    hardware rounding mode: to nearest
    hardware rounding mode: downward
[errors begin]

while this, at the end, shows that there's no problem unless
the default style is synchronized to the hardware mode:

  Default style NOT synchronized to hardware mode:
    hardware rounding mode: to nearest
    hardware rounding mode: downward
    hardware rounding mode: upward
    hardware rounding mode: toward zero

So I'd guess the problem must have something to do with whether
detail::perform_rint() gets called in this block, because that's
the only place it seems to be used:

// Choose the auxiliary rounding function indicated by the argument.
template<typename RealType>
typename round_to<RealType>::rounding_function_t
round_to<RealType>::select_rounding_function(rounding_style const a_style) const
{
#ifndef LMI_LACKING_RINT_OR_EQUIVALENT
    if
        (  a_style == default_rounding_style()
        && a_style != r_indeterminate
        )
        {
        return detail::perform_rint;
        }
#endif // not defined LMI_LACKING_RINT_OR_EQUIVALENT

If you change that thus:
-        return detail::perform_rint;
+        // EXPERIMENTALLY SKIPPED return detail::perform_rint;
to suppress that early exit (which should be a mere speed
optimization), then does everything work?

AIUI (but you shouldn't rely completely on my recollection),
rint() or equivalent is called when the floating-point style
is already set to the style desired: then it should just do
the right thing, without incurring the overhead of changing
the floating-point control word. It's hard to say more from
here about what's happening on your machine, but we could
instrument it more elaborately--for instance, to print out
the actual and hoped-for control words.