[boost] Re: Numeric Conversion Formal Review

From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2003-12-12 17:38:03

Le ven 12/12/2003 à 21:24, Fernando Cacciola a écrit :
> Guillaume Melquiond wrote:

[...]

> > So I'm not sure what the best thing to do is. At least, the
> > documentation should mention the default rounding to nearest is a
> > strange one. But it may be worthwhile to use a more thorough
> > implementation.
> >
> > And rather than only relying only on floor and ceil, maybe a third
> > function could be used (it's just a quick thought, there probably are
> > some drawbacks).
> >
> OK, I think I should try to figure out a corrected implementation that ties
> to even as most people would expect.
> If you'd like to suggest something I'd appreciate it.

Rounding to nearest with ties to even is hard when the only available
functions are floor and ceil. I'm not even sure that it is possible for
an udt: you need the user to provide a "good" subtraction.

  a = floor(x); // only works inside the range
  b = ceil(x);  // not at the boundaries
  c = (x - a) - (b - x); // the "good" subtraction
  if (c < 0) return a;
  else if (c > 0) return b;
  else return 2 * floor(b / 2); // needs to behave sanely

It's quite ugly. It's why I was suggesting to rely on a third function
just for this rounding. Unfortunately the current C++ standard isn't at
all as good as C99 when it comes to rounding functions (C99 provides
floor, ceil, rint, round, lround, and a few others). So in order to use
them, you have to hope there is a C library laying around.

For binary floating-point numbers, there is a funny method to find the
rounding of a positive number f (I'm not suggesting to use it, it's only
an anecdote). Let's call M the biggest integer such that 2M-1 is
representable (M = 2^23 for simple precision).

  if (f >= M) return f;    // f is already an integer
  else return (f + M) - M; // f+M will round f

And obviously it won't work at all for an udt. And for a floating-point
type, the binary representation must be known in order to compute M.

In conclusion: sorry, I don't have anything useful to suggest.

> >>> In the definition part of the documentation, the notions of "range"
> >>> of a
> >>> type and "overflow" don't match the later explanation of float to
> >>> int rounding.
> >> I can't find what 'later explanation' are you referring to... or I
> >> don't see the error :-)
> >> Can you be more specific?
> >
> > In the definition part, you explain a value is out of range if it is
> > smaller than the smallest target value or bigger than the biggest
> > target value. But, in the rounding to integer part, a value is out of
> > range if
> > it is outside of the destination range plus a fuzz (-1/0, -0.5/+0.5,
> > 0/+1). Maybe I'm misunderstanding the definitions.
> >
> hmmm, help me out... I still don't follow.....
> 
> Considering that the "value" being used in the definition of overflow is an
> "abstract" value, not a "typed" value in any particular format, why is it
> not true that given: H=the biggest target (typed) value, then any N>abt(H)
> is out-of-range w.r.t to the target type?
> This is what the definition says.
> 
> IOW, how is it that the value is out if it's outside "Range(T) + something"?
> Why plus something?

Now I'm quite sure I misunderstood the whole idea of these "abstract"
values. Unfortunately, even after reading the documentation one more
time, I still don't understand.

So here is what made me wince. As you said it yourself: H=the biggest
target (typed) value, then any N>abt(H) is out-of-range w.r.t to the
target type.

Now if we take a look at the documentation about float to int rounding,
we can read: round_to_zero |--> [...] && (s <  S(HighestT)+S(1)).

So now I'm lost: it seems the definition of overflow has changed.
However it may only be because I don't understand what this notion of
abstract value is.

[...]

> > In fact, the only problem may be this sentence: "if v==prev or
> > v==next,
> > the representation is correctly rounded". You should remove
> > "correctly"
> > and put the "correctly rounded" of the next sentence in bold.
> 
> Oh yes, this would match the correct definition for "correctly" rounded.
> Furthermore, I think I can replace "correctly" by "faithfully" in the
> original sentence, right?

Right.

[...]

> Fernando Cacciola
> SciSoft

Regards,

Guillaume