Does -0.5 fit an unsigned when truncated to an integer?
vincent at vinc17.net
Tue Mar 19 03:24:28 CET 2013
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:
18.104.22.168 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)
More information about the gmp-devel