bug-gmp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GMP ceil/floor/trunc & round-offs


From: Hans Aberg
Subject: GMP ceil/floor/trunc & round-offs
Date: Mon, 30 Apr 2001 19:18:51 +0200

Here are some inputs on ceil/floor/trunc and round-off functions:

I think that ceil/floor/trunc functions should be viewed as integer
truncation functions
  rational -> integer
  fixed -> integer
  floating -> integer
(I add the "fixed" type here just for mathematical completeness.)

The traditional ceil/floor/trunc should then be replaced by round-off functions
  (fixed, precision) -> fixed
  (floating, precision) -> floating
where the precision argument specoifies the precision of the function
return. Note that there are special round-off techniques favoured by some,
like that the number exactly in the middle in the round-off process is
rounded up/down depending on what the next higher binary digit is. (I am
myself somewhat sceptical about those round-off techniques, and I merely
note that they do exist.)

One should avoid the type-conversions
  rational -> integer
  floating -> integer
  floating -> rational
and similar for the fixed type, and instead make separate functions.

In fact, if I add them to my C++ header, based on mpz_set_q & mpz_set_f, my
C++ compiler becomes confused with the other type conversions. For example,
it cannot add an integer and a rational anymore. It does not make so much
difference under C, but strictly speaking those mpz_set_q & mpz_set_f ought
to be replaced by the ceil/floor/trunc mentioned above.

I added to my rational class the functions corresponding to
  mpz_cdiv_q   mpz_fdiv_q   mpz_tdiv_q
  mpz_cdiv_r   mpz_fdiv_r   mpz_tdiv_r
  mpz_cdiv_qr  mpz_fdiv_qr  mpz_tdiv_r
They the became functions
     int_ceil, int_floor, int_trunc: rational -> integer
  frac_ceil, frac_floor, frac_trunc: rational -> rational
     div_ceil, div_floor, div_trunc: rational -> (integer, rational)
The thing is that the fractional part is only defined as a rational number,
so it would strictly speaking be mathematically ambiguous to define say
  frac_trunc: rational -> integer
as the return integer would depend on the representation of the rational
number.

And then one gets similar functions for the other types, fixed and floating.

  Hans Aberg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]