Ciao,
Il Sab, 8 Febbraio 2014 9:50 am, Niels ha scritto:
bodr...@mail.dm.unipi.it writes:
So, maybe we can discuss about adding a new function to the _limbs
interface:
mp_ptr
mpz_init_limbs_write (mpz_t x, mp_size_t n)
What is this intended for? Looks a bit like like mpz_init2.
bodr...@mail.dm.unipi.it writes:
So, maybe we can discuss about adding a new function to the _limbs interface:
mp_ptr
mpz_init_limbs_write (mpz_t x, mp_size_t n)
{
ALLOC (x) = n;
PTR (x) = (mp_ptr) (*__gmp_allocate_func) (n*GMP_LIMB_BYTES);
SIZ (x) = 0;
return PTR (x);
}
What
ni...@lysator.liu.se (Niels Möller) writes:
Why isn't __gmp_extract_double's style OK for mpn_set_d? Is its
conventions not neat enough, or are there efficiency reasons?
I found the conventions of __gmp_extract_double hard to understand. And
I think returning a base 2 exponent is
Torbjorn Granlund t...@gmplib.org writes:
But then the shifting done in __gmp_extract_double will be needed in
every caller. Or am I mistaken?
I think you are right, for all current callers but one. The exception is
mpq_set_d, which needs to remove trailing zero bits for normalization,
using a
Ciao,
Il Gio, 6 Febbraio 2014 2:08 pm, Niels ha scritto:
Personally, I feel a bit easier about adding feature close to release,
than about rewriting code for existing features.
So, maybe we can discuss about adding a new function to the _limbs interface:
mp_ptr
mpz_init_limbs_write (mpz_t x,
Ciao,
Il Gio, 6 Febbraio 2014 9:56 am, Niels ha scritto:
What do you think?
void
mpz_set_d (mpz_ptr r, double d)
{
int negative;
! mp_limb_t tp[MPN_SET_D_SIZE];
! mpz_t t = MPZ_ROINIT_N (tp, MPN_SET_D_SIZE);
Uhm, in tests/mpz/t-limbs.c we test MPZ_ROINIT_N only
#if
bodr...@mail.dm.unipi.it writes:
Il Gio, 6 Febbraio 2014 9:56 am, Niels ha scritto:
What do you think?
void
mpz_set_d (mpz_ptr r, double d)
{
int negative;
! mp_limb_t tp[MPN_SET_D_SIZE];
! mpz_t t = MPZ_ROINIT_N (tp, MPN_SET_D_SIZE);
Uhm, in tests/mpz/t-limbs.c we test
ni...@lysator.liu.se (Niels Möller) writes:
For mpn_set_d, I think it would make some sense to have it return a
base-2 exponent, and write the mantissa to a few limbs. Number of limbs
would be a constant, part of the ABI, similar to LIMBS_PER_DOUBLE but
renamed for external use.
On Thu, 6 Feb 2014, Niels Möller wrote:
ni...@lysator.liu.se (Niels Möller) writes:
For mpn_set_d, I think it would make some sense to have it return a
base-2 exponent, and write the mantissa to a few limbs. Number of limbs
would be a constant, part of the ABI, similar to LIMBS_PER_DOUBLE but
Marc Glisse marc.gli...@inria.fr writes:
Why not return int, since int is what we use for _mp_size?
int would be sufficient for all known float formats I guess. I choose
long because that was the signed type closest to mp_bit_cnt_t.
Is 53 really safe for non-IEEE double? Maybe something based
On 2014-02-06 11:54:04 +0100, Niels Möller wrote:
Marc Glisse marc.gli...@inria.fr writes:
+ ASSERT (d != 0.5*d); /* Exclude infinities */
That excludes more than infinities, it might also exclude
FLT_TRUE_MIN, no?
I would have expected that FLT_TRUE_MIN * 0.5 == 0.0. And then it's
Vincent Lefevre vinc...@vinc17.net writes:
In rounding mode toward +inf (FE_UPWARD), FLT_TRUE_MIN * 0.5 gives
FLT_TRUE_MIN.
I see.
You may need:
ASSERT (d - d == 0);
That should exclude both infinities and NaN:s, right?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is
On 2014-02-06 12:46:05 +0100, Niels Möller wrote:
Vincent Lefevre vinc...@vinc17.net writes:
You may need:
ASSERT (d - d == 0);
That should exclude both infinities and NaN:s, right?
Yes. If you want to differentiate between NaN and infinities:
d != d is true only for NaN.
--
Vincent
Vincent Lefevre vinc...@vinc17.net writes:
Yes. If you want to differentiate between NaN and infinities:
d != d is true only for NaN.
I'm looking at the definition of DOUBLE_NAN_INF_ACTION in gmp-impl.h.
Maybe it could be simplified to a single, unconditional, definition
#define
On Thu, 6 Feb 2014, Niels Möller wrote:
Vincent Lefevre vinc...@vinc17.net writes:
Yes. If you want to differentiate between NaN and infinities:
d != d is true only for NaN.
I'm looking at the definition of DOUBLE_NAN_INF_ACTION in gmp-impl.h.
Maybe it could be simplified to a single,
Marc Glisse marc.gli...@inria.fr writes:
On Thu, 6 Feb 2014, Niels Möller wrote:
I'm looking at the definition of DOUBLE_NAN_INF_ACTION in gmp-impl.h.
Maybe it could be simplified to a single, unconditional, definition
Note that there exist standard functions like isfinite.
But so far, we
On Thu, 6 Feb 2014, Niels Möller wrote:
Marc Glisse marc.gli...@inria.fr writes:
Note that there exist standard functions like isfinite.
But so far, we don't use any libm functions in gmp.
True.
* no slower then the _GMP_IEEE_FLOATS definition (which extracts the
exponent via a
ni...@lysator.liu.se (Niels Möller) writes:
Below is a patch to do this (and return value is long, not mp_bitcnt_t,
since it needs to be signed).
What do you think?
I'm to busy to make an educated analysis.
Why isn't __gmp_extract_double's style OK for mpn_set_d? Is its
conventions
Niels,
sorry for the late reply, we were quite busy with the MPFR/MPC workshop
(which was very successful).
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
Ciao,
Il Gio, 23 Gennaio 2014 8:39 am, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Well, it is wrapped with
#if ! HAVE_VSNPRINTF /* only need this file if we don't have vsnprintf
so, on many systems it is not compiled at all... (and that's a reason
By forcing
bodr...@mail.dm.unipi.it writes:
Maybe our printf/repl-vsnprintf.c is not tested enough?
Oddly enough it is not even listed at e.g.,
https://gmplib.org/devel/lcov/hannahnbsd32v61/gmp/printf/index.html.
Of the existing 21 function in printf/ only 17 are there. Great
coverage analysis! :-(
Ciao,
Il Mer, 22 Gennaio 2014 12:44 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Maybe our printf/repl-vsnprintf.c is not tested enough?
Oddly enough it is not even listed at e.g.,
https://gmplib.org/devel/lcov/hannahnbsd32v61/gmp/printf/index.html.
Well, it is
bodr...@mail.dm.unipi.it writes:
Well, it is wrapped with
#if ! HAVE_VSNPRINTF /* only need this file if we don't have vsnprintf */
[...]
#endif /* ! HAVE_VSNPRINTF */
so, on many systems it is not compiled at all... (and that's a reason why
it is less tested than other chunks
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
Zimmermann Paul paul.zimmerm...@inria.fr 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
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
Torbjorn Granlund t...@gmplib.org 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
Marc Glisse marc.gli...@inria.fr 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
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
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
ni...@lysator.liu.se (Niels Möller) writes:
Torbjorn Granlund t...@gmplib.org 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
Marc Glisse marc.gli...@inria.fr 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
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
Marc Glisse marc.gli...@inria.fr 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
Ciao,
Il Mar, 21 Gennaio 2014 4:24 pm, Torbjorn Granlund ha scritto:
Zimmermann Paul paul.zimmerm...@inria.fr 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
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
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
___
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
38 matches
Mail list logo
