Ciao, Il Ven, 15 Febbraio 2013 3:51 pm, Niels Möller ha scritto: > /* Return limb pointer, for read-only operations. Use mpz_size to get > the number of limbs. */ > const mp_limb_t * > mpz_read_limbs (const mpz_srcptr x);
mpz_srcptr already is const, isn't it? > /* Get a limb pointer for writing, previous contents is intact. > Grows allocation if needed to make room for n limbs. */ > mp_limb_t * > mpz_modify_limbs (mpz_ptr x, mp_size_t n); You mean that allocation doesn't shrink, right? So n=0 can be used if one knows in advance that the mpn operations can not give a larger number. We may say that n=0 is equivalent to n=mpz_size (x). > /* Using an mpn number as an mpz. Can be used for read-only access > only. x must not be cleared or reallocated. Here and below, xs > stands for a signed parameter, where abs(xs) is the size, and xs < > 0 indicates a negative number. Returns x, cast to const, so it can > be used directly as an argument for other mpz functions. */ > mpz_srcptr > mpz_init_mpn (mpz_ptr x, const mp_limb_t *xp, mp_size_t xs); Maybe _roinit is a better name, if it is read-only. We may also allow write access, why not? I know it is dangerous, but it is not more dangerous than an mpz initialized with the already documented mpz_array_init function... > /* Copy x, which must be at most xn limbs, to the {xp, xn} area, > zero-padding if needed. Not sure what to do if x is too large to > fit, or if x < 0. */ > void > mpz_get_mpn (mp_limb_t *xp, mp_size_t xn, const mpz_t x); If the general idea is: zero-pad if read-only; then zero-padding here is not needed. > /* Assigns x from the area {xp, abs(xs)}. */ > void > mpz_set_mpn (mpz_t x, const mp_limb_t *xp, mp_size_t xs); We have mpz_set_q, mpz_set_f, mpq_set_z... should we call this one mpz_set_n? Regards, m -- http://bodrato.it/software/strassen.html _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel