Does -0.5 fit an unsigned when truncated to an integer?

[Vincent Lefevre]

On 2013-03-18 22:35:51 +0100, Torbjorn Granlund wrote:
> bodrato at mail.dm.unipi.it writes:
> 
>   Il Lun, 18 Marzo 2013 12:05 pm, Torbjorn Granlund ha scritto:
>   > Zimmermann Paul <Paul.Zimmermann at inria.fr> writes:
>   >
>   >   indeed this is inconsistent. mpf_fits_uint_p(-0.5) should return true,
>   > as well
>   >   as mpf_fits_uint_p(-0.99999999999).
>   >
>   > I am not so sure that would be the right fix here.
>   
>   Do you suggest to change the documentation so that it describes the
>   current code?
> 
> I haven't though a lot about this, but it is not clear that -1 + eps
> should be considered to fit an unsigned type.

Why? Just like eps and 1 - eps are rounding to the same value 0,
-1 + eps and -eps must have the same behavior. And since the
rounded value is 0 for -1 + eps and -eps, I don't see why the
result should be considered not to fit: what's important is the
value once converted, not the FP argument.

Actually it seems to me that this is what the documentation says.
But it could be clarified.

FYI, this is also how ISO C behaves:

  6.3.1.4 Real floating and integer

  When a finite value of real floating type is converted to an integer
  type other than _Bool, the fractional part is discarded (i.e., the
  value is truncated toward zero). If the value of the integral part
  cannot be represented by the integer type, the behavior is undefined.61)

  61) The remaindering operation performed when a value of integer type
      is converted to unsigned type need not be performed when a value of
      real floating type is converted to unsigned type. Thus, the range
      of portable real floating values is (-1, Utype_MAX+1).

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)