Re: mpz_limbs interface
Dear Marco,
> > Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
> > repl-vsnprintf.c:379: GNU MP assertion failed: len < total_width
> > /bin/bash: line 5: 7656 Aborted (core dumped)
> > MPFR_QUIET=1 ${dir}$tst
> > FAIL: tprintf
>
> > I trust that you will debug this and report it to us if it is GMP's fault.
>
> I believe it is GMP's fault.
with the gmp-5.1.90-20140122 snapshot the problem is fixed, thanks.
> Maybe our printf/repl-vsnprintf.c is not tested enough?
yes it seems.
Paul
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
ni...@lysator.liu.se (Niels Möller) writes: This assumes that C++ allows initializers with arbitrary non-constant expressions (does it?), and that we implement mpn_set_d. The top-level file extract-dbl.c kind-of does that already. Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Marc Glisse writes:
> On Tue, 21 Jan 2014, Niels Möller wrote:
>
>> When does this situation arise?
>
> __GMPXX_TMPZ_D, for instance.
>From a quick look in gmpxx.h, it appears we could *almost* use
MPZ_ROINIT_N. For the target call, the temp variable always used as an mpz_t
*input* only (from a quick look at gmpxx.h). But the initialization
calls mpz_set_d. Ideal would be something like
mp_limb_t limbs[__GMPZ_DBL_LIMBS];
mpz_t temp = MPZ_ROINIT_N(limbs, mpn_set_d(limbs, d));
This assumes that C++ allows initializers with arbitrary non-constant
expressions (does it?), and that we implement mpn_set_d. Then, mpz_set_d
could be reimplemented as
void
mpz_set_d (mpz_t r, double d)
{
rn = ... needed space for d ...
mp_ptr rp = MPZ_REALLOC (r, rn);
SIZ(r) = mpn_set_d (rp, d));
}
In the current code, there's a related function __gmp_extract_double. I
haven't really tried to understant how mpz_set_d works.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Tue, 21 Jan 2014, Niels Möller wrote: No, the new limb interface can only do it the other way round. If you want to use a buffer as mpz_t output, and access it with low-level fucntions too, you have give the reponsibility for allocating it to _mpz_realloc, and write the code to tolerate that any use of the buffer as an mpz_t output might do an unexpected reallocation. Up to now, we have always kind of promised that if there was enough margin in the output variables, there wouldn't be any unexpected reallocation. When does this situation arise? __GMPXX_TMPZ_D, for instance. But this is mostly a speed issue, we shouldn't reallocate when it is obviously unneeded. I guess I got confused between what is a guideline for us (don't reallocate) and what is promised in the doc (don't bother specifying when reallocation may happen: always), so we can drop this. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Ciao,
Il Mar, 21 Gennaio 2014 4:24 pm, Torbjorn Granlund ha scritto:
> Zimmermann Paul writes:
> Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
> repl-vsnprintf.c:379: GNU MP assertion failed: len < total_width
> /bin/bash: line 5: 7656 Aborted (core dumped)
> MPFR_QUIET=1 ${dir}$tst
> FAIL: tprintf
> I trust that you will debug this and report it to us if it is GMP's fault.
I believe it is GMP's fault.
I have a similar problem, some changes ago the generated config.h contained:
/* Define to 1 if exists and works */
#define HAVE_STDARG 1
[...]
#define HAVE_VSNPRINTF 1
After some recent changes it reads:
/* #undef HAVE_VSNPRINTF */
I removed some remaining "#if HAVE_STDARG" from acinclude.m4, this
probably heals also the failure spotted by Paul:
https://gmplib.org/repo/gmp/rev/e9c5ede5b42d
Maybe our printf/repl-vsnprintf.c is not tested enough?
Regards,
m
--
http://bodrato.it/
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Marc Glisse writes: > I was talking of the case where I already have a preexisting buffer I > want to use as _mp_d, I don't want to allocate a new one with > mpz_realloc2. That seems to be a few steps further than the new limb > interface goes, and I can understand not wanting to support that. No, the new limb interface can only do it the other way round. If you want to use a buffer as mpz_t output, and access it with low-level fucntions too, you have give the reponsibility for allocating it to _mpz_realloc, and write the code to tolerate that any use of the buffer as an mpz_t output might do an unexpected reallocation. When does this situation arise? In the given example, the root cause was a missing mpn-level function in gmp. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: New mpn random generators
Torbjorn Granlund writes: > ni...@lysator.liu.se (Niels Möller) writes: > > After 5.2? > > Probably, but you're welcome to fix it today also. :-) > > Or would you suggest that we postpone the release? No, I donät think the release whould wait for new randomness functions. As you say, the design is not entirely obvious, and maybe that has to take some time. Actually, there are two parts: (i) Rewrite current code to not use mpz internally, and (ii) define a new public mpn interface. First part has no interface design issues. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Tue, 21 Jan 2014, Niels Möller wrote: There's a ChangeLog entry from the day before yesterday: * doc/gmp.texi: Undocument mpz_array_init. Thanks, I hadn't seen it yet. One can still use mpz_realloc2, which can be viewed as an allocation hint to the gmp implementation (so in mini-gmp, it's harmless but also mostly useless, due to the frequent use of mpz_swap). I was talking of the case where I already have a preexisting buffer I want to use as _mp_d, I don't want to allocate a new one with mpz_realloc2. That seems to be a few steps further than the new limb interface goes, and I can understand not wanting to support that. Playing with mp_set_memory_functions, there is a complicated way to use a preexisting buffer without breaking if I am using mini-gmp, but having 2 versions of the code still seems simpler and more efficient (and that's all unsupported anyway). I guess it would be hard to make an official interface that lets users reimplement __GMPXX_TMPZ_D. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Marc Glisse writes: We already have function mpz_array_init which encourages thinking of I removed its docs the other day. Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
New mpn random generators (Was: Re: mpz_limbs interface)
ni...@lysator.liu.se (Niels Möller) writes: Torbjorn Granlund writes: > ni...@lysator.liu.se (Niels Möller) writes: > > I see. In this particular case, I think the right gmp interface change > is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random > and mpn_random2, but with a randstate argument). If I understand this > correctly, the main obstacle is that random number internals use mpz > functions, which is an undesirable dependency for mpn functions. > > We should indeed do this. After 5.2? Probably, but you're welcome to fix it today also. :-) Or would you suggest that we postpone the release? I am not sure exactly how a revamped mpn random interface would look like. Perhaps mpn_urandomb and mpn_rrandomb, with bit counts (giving machine indep results). Current mpn random function take limb counts. I assume it will be good enough to have just bit counts in the new generators, even at the limb oriented mpn level. A count like n*GMP_NUMB_BITS is not that bad. A subtle difference between the current functions and such new functions would be that the new functions would not make the result "normalised". At least not mpn_urandomb. (For mpn_rrandomb we might define the most significant set bit to be defined by the bit count argument.) We could consider mpn_urandomm, but I am not sure that's a good idea. > For testing the result, I'd write a wrapper C program that run old and > new code in separate processes, and compare that the results are > identical for the same (now and then regenerated) seeds. If the generation is intended to be machine-independent, it would also make sense to also add tests generating some random numbers from a few fixed seeds, and compare to expected (constant) numbers. Sure, but I think that has been established for the current implementation already. Thus my suggested test woudl indirectly establish that for an mpn rewrite. (I am talking about mpz_*random* here, not new mpn_*random* functions.) Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
> PS: when doing "make check" with mpfr development version and the gmp
> snapshot
> from last night, I get one failure:
>
> Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
> repl-vsnprintf.c:379: GNU MP assertion failed: len < total_width
> /bin/bash: line 5: 7656 Aborted (core dumped) MPFR_QUIET=1
> ${dir}$tst
> FAIL: tprintf
>
> I trust that you will debug this and report it to us if it is GMP's fault.
most likely it is a bug in MPFR or the way MPFR uses GMP, but in case it
still pops up when GMP 5.2 comes out, be sure we will debug and report!
Paul
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Niels, > There's a ChangeLog entry from the day before yesterday: > > * doc/gmp.texi: Undocument mpz_array_init. > > I take it Torbjörn really wants to deprecate this function. > > Are you using it in mpfr? no. Paul ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Marc Glisse writes: > We already have function mpz_array_init which encourages thinking of > the buffer as belonging to a variable, There's a ChangeLog entry from the day before yesterday: * doc/gmp.texi: Undocument mpz_array_init. I take it Torbjörn really wants to deprecate this function. Are you using it in mpfr? > Gratuitous extra alloc+dealloc pairs can have a horrible performance > effect. One can still use mpz_realloc2, which can be viewed as an allocation hint to the gmp implementation (so in mini-gmp, it's harmless but also mostly useless, due to the frequent use of mpz_swap). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
On Tue, 21 Jan 2014, Niels Möller wrote: MPFR_ASSERTN (nbits >= 1); /* To be sure to avoid the potential allocation of mpz_urandomb */ ALLOC(z) = SIZ(z) = MPFR_PREC2LIMBS (nbits); PTR(z) = mp; [...] mpz_urandomb (z, rstate, nbits); I think this is brittle, and I don't think this style should be officially supported in the public gmp interface. mpz_urandomb is not included in mini-gmp, but if you, e.g., try the same with other functions, it will most likely break with mini-gmp which assigns many of the output parameters using mpz_swap. We already have function mpz_array_init which encourages thinking of the buffer as belonging to a variable, with all other functions keeping this association as long as the buffer is large enough. Gratuitous extra alloc+dealloc pairs can have a horrible performance effect. That's not an issue for mini-gmp because performance is not a concern, but it is for mpfr and many users, and even if they rewrite the code to accomodate mini-gmp, they will probably want to keep the current one for regular gmp (with suitable #if). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Torbjorn Granlund writes: > ni...@lysator.liu.se (Niels Möller) writes: > > I see. In this particular case, I think the right gmp interface change > is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random > and mpn_random2, but with a randstate argument). If I understand this > correctly, the main obstacle is that random number internals use mpz > functions, which is an undesirable dependency for mpn functions. > > We should indeed do this. After 5.2? > For testing the result, I'd write a wrapper C program that run old and > new code in separate processes, and compare that the results are > identical for the same (now and then regenerated) seeds. If the generation is intended to be machine-independent, it would also make sense to also add tests generating some random numbers from a few fixed seeds, and compare to expected (constant) numbers. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Zimmermann Paul writes:
PS: when doing "make check" with mpfr development version and the gmp snapshot
from last night, I get one failure:
Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
repl-vsnprintf.c:379: GNU MP assertion failed: len < total_width
/bin/bash: line 5: 7656 Aborted (core dumped) MPFR_QUIET=1
${dir}$tst
FAIL: tprintf
I trust that you will debug this and report it to us if it is GMP's fault.
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
ni...@lysator.liu.se (Niels Möller) writes: I see. In this particular case, I think the right gmp interface change is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random and mpn_random2, but with a randstate argument). If I understand this correctly, the main obstacle is that random number internals use mpz functions, which is an undesirable dependency for mpn functions. We should indeed do this. The random number framework uses the following mpz functions: mpz_add_ui mpz_addmul_ui mpz_clear mpz_clrbit mpz_export mpz_fdiv_r_2exp mpz_init mpz_init2 mpz_init_set mpz_init_set_str mpz_mod mpz_mul mpz_setbit mpz_sub_ui mpz_tdiv_q_2exp mpz_tdiv_r_2exp mpz_tstbit This should be fairly easy to rewrite to use mpn. For testing the result, I'd write a wrapper C program that run old and new code in separate processes, and compare that the results are identical for the same (now and then regenerated) seeds. There is a pseudo-dependency on mpz in the gmp_randstate_t type, since the _mp_seed if of type mpz_t. To clean that up without causing binary incompatibility, we could just define a type with the exact same components as mpz_t. Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
Re: mpz_limbs interface
Zimmermann Paul writes: > we have looked at the mpz_limbs interface, Thanks for the review. > it seems it won't be sufficient for > our needs in MPFR. Consider for example the following function, which > generates nbits random bits into mp[]: I see. In this particular case, I think the right gmp interface change is to add mpn_urandomb and mpn_rrandomb (similar to current mpn_random and mpn_random2, but with a randstate argument). If I understand this correctly, the main obstacle is that random number internals use mpz functions, which is an undesirable dependency for mpn functions. Any other problematic cases? > MPFR_ASSERTN (nbits >= 1); > /* To be sure to avoid the potential allocation of mpz_urandomb */ > ALLOC(z) = SIZ(z) = MPFR_PREC2LIMBS (nbits); > PTR(z) = mp; [...] > mpz_urandomb (z, rstate, nbits); I think this is brittle, and I don't think this style should be officially supported in the public gmp interface. mpz_urandomb is not included in mini-gmp, but if you, e.g., try the same with other functions, it will most likely break with mini-gmp which assigns many of the output parameters using mpz_swap. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
mpz_limbs interface
Hi,
we have looked at the mpz_limbs interface, it seems it won't be sufficient for
our needs in MPFR. Consider for example the following function, which
generates nbits random bits into mp[]:
/* generate nbits random bits into mp[], assuming mp was allocated to contain
a sufficient number of limbs */
void
mpfr_rand_raw (mpfr_limb_ptr mp, gmp_randstate_t rstate,
mpfr_prec_t nbits)
{
mpz_t z;
MPFR_ASSERTN (nbits >= 1);
/* To be sure to avoid the potential allocation of mpz_urandomb */
ALLOC(z) = SIZ(z) = MPFR_PREC2LIMBS (nbits);
PTR(z) = mp;
#if __MPFR_GMP(5,0,0)
/* Check for integer overflow (unless mp_bitcnt_t is signed,
but according to the GMP manual, this shouldn't happen).
Note: mp_bitcnt_t has been introduced in GMP 5.0.0. */
MPFR_ASSERTN ((mp_bitcnt_t) -1 < 0 || nbits <= (mp_bitcnt_t) -1);
#endif
mpz_urandomb (z, rstate, nbits);
}
The only mpz_limbs function that takes as input an array of limbs is
mpz_roinit_n(), but in this function X is read-only, and in mpfr_rand_raw()
above z is not read-only.
Thus we need a function that creates a valid mpz_t from given alloc and size
fields.
Paul
PS: when doing "make check" with mpfr development version and the gmp snapshot
from last night, I get one failure:
Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
repl-vsnprintf.c:379: GNU MP assertion failed: len < total_width
/bin/bash: line 5: 7656 Aborted (core dumped) MPFR_QUIET=1
${dir}$tst
FAIL: tprintf
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
mpz_limbs interface
Hi,
we have looked at the mpz_limbs interface, it seems it won't be sufficient for
our needs in MPFR. Consider for example the following function, which
generates nbits random bits into mp[]:
/* generate nbits random bits into mp[], assuming mp was allocated to contain
a sufficient number of limbs */
void
mpfr_rand_raw (mpfr_limb_ptr mp, gmp_randstate_t rstate,
mpfr_prec_t nbits)
{
mpz_t z;
MPFR_ASSERTN (nbits >= 1);
/* To be sure to avoid the potential allocation of mpz_urandomb */
ALLOC(z) = SIZ(z) = MPFR_PREC2LIMBS (nbits);
PTR(z) = mp;
#if __MPFR_GMP(5,0,0)
/* Check for integer overflow (unless mp_bitcnt_t is signed,
but according to the GMP manual, this shouldn't happen).
Note: mp_bitcnt_t has been introduced in GMP 5.0.0. */
MPFR_ASSERTN ((mp_bitcnt_t) -1 < 0 || nbits <= (mp_bitcnt_t) -1);
#endif
mpz_urandomb (z, rstate, nbits);
}
The only mpz_limbs function that takes as input an array of limbs is
mpz_roinit_n(), but in this function X is read-only, and in mpfr_rand_raw()
above z is not read-only.
Thus we need a function that creates a valid mpz_t from given alloc and size
fields.
Paul
PS: when doing "make check" with mpfr development version and the gmp snapshot
from last night, I get one failure:
Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
repl-vsnprintf.c:379: GNU MP assertion failed: len < total_width
/bin/bash: line 5: 7656 Aborted (core dumped) MPFR_QUIET=1
${dir}$tst
FAIL: tprintf
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
