headers
Marc Glisse | 1 Aug 2011 15:39
Picon
Picon
Favicon

public typedefs for gmp malloc/free types

Hello,

the following is a common use of gmp:

       void (*gmp_free) (void *, size_t);
       mp_get_memory_functions (NULL, NULL, &gmp_free);
       (*gmp_free) (str, strlen (str) + 1);

which is valid in C, compiles with g++, but is invalid in C++ proper. For 
this reason, we have in gmpxx.h:

extern "C" {
   typedef void (*__gmp_freefunc_t) (void *, size_t);
}

so we can declare:

       __gmp_freefunc_t gmp_free;

Now, I have to introduce this same fix in CGAL and in GCC. I believe it 
would be good if gmp provided an official, documented typedef for the 
types of the malloc/realloc/free functions it uses.

Possibly gmp_malloc_t/gmp_realloc_t/gmp_free_t, but I really don't care 
about the name.

What do you think?

--

-- 
Marc Glisse
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bob Kuo | 2 Aug 2011 19:20
Picon
Gravatar

Incorporating GMP documentation into a project

Hello,

I'm working with the Parrot Foundation[1] for the Google Summer of Code[2]
and my project[3] is to provide bindings to the Integer functions in GMP.
 I'm incorporating the documentation that comes with GMP in my source code.
 What kind of attribution or text do I need to both acknowledge that that
documentation comes from GMP and not violate GMP's license?

Thanks,

Bob

[1] - http://www.parrot.org
[2] - http://www.google-melange.com/gsoc/homepage/google/gsoc2011
[3] -
http://www.google-melange.com/gsoc/project/google/gsoc2011/bubaflub/13001
Permalink | Reply | 0 comments |
headers
Torbjorn Granlund | 2 Aug 2011 19:31

Re: public typedefs for gmp malloc/free types

Marc Glisse <marc.glisse <at> inria.fr> writes:

  the following is a common use of gmp:

        void (*gmp_free) (void *, size_t);
        mp_get_memory_functions (NULL, NULL, &gmp_free);
        (*gmp_free) (str, strlen (str) + 1);

  which is valid in C, compiles with g++, but is invalid in C++
  proper. For this reason, we have in gmpxx.h:

What is invalid about it, in "proper C++"?

  extern "C" {
    typedef void (*__gmp_freefunc_t) (void *, size_t);
  }

  so we can declare:

        __gmp_freefunc_t gmp_free;

  Now, I have to introduce this same fix in CGAL and in GCC. I believe
  it would be good if gmp provided an official, documented typedef for
  the types of the malloc/realloc/free functions it uses.

  Possibly gmp_malloc_t/gmp_realloc_t/gmp_free_t, but I really don't
  care about the name.

Their types is defined, without a typedef in the manual:
http://gmplib.org/manual/Custom-Allocation.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Glisse | 2 Aug 2011 20:58
Picon
Picon
Favicon

Re: public typedefs for gmp malloc/free types

On Tue, 2 Aug 2011, Torbjorn Granlund wrote:

> Marc Glisse <marc.glisse <at> inria.fr> writes:
>
>  the following is a common use of gmp:
>
>        void (*gmp_free) (void *, size_t);
>        mp_get_memory_functions (NULL, NULL, &gmp_free);
>        (*gmp_free) (str, strlen (str) + 1);
>
>  which is valid in C, compiles with g++, but is invalid in C++
>  proper. For this reason, we have in gmpxx.h:
>
> What is invalid about it, in "proper C++"?

gmp_free is declared as void(*)(void*,size_t) with C++ linkage whereas 
mp_get_memory_functions takes as argument a void(*)(void*,size_t) with 
extern "C" linkage, which are 2 different types. C++ is allowed to use a 
completely different calling convention than C and there are rules 
ensuring that you can use both types of functions in your programs (you 
can even overload on linkage, and the standard C function qsort has 2 
overloads so you can pass it either a C or C++ function).

Note that since extern "C" can't appear in the middle of a function, a 
typedef is the only way to declare a local variable that is a pointer to a 
C function.

The bug in gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Cleaver | 9 Aug 2011 03:08
Favicon

New mpz prp functions...

Hello all,

Along with the previous Lucas functions I've mentioned, I'd also like to propose 
that we add several new prp functions to the official GMP library.  Here are the 
prototypes for the new prp functions:

int mpz_prp(mpz_t n, mpz_t a) aka: Fermat pseudoprime
int mpz_euler_prp(mpz_t n, mpz_t a) aka: Solovay-Strassen pseudoprime
int mpz_sprp(mpz_t n, mpz_t a) aka: Miller-Rabin pseudoprime
int mpz_fibonacci_prp(mpz_t n, long int p, long int q)
int mpz_lucas_prp(mpz_t n, long int p, long int q)
int mpz_stronglucas_prp(mpz_t n, long int p, long int q)
int mpz_extrastronglucas_prp(mpz_t n, long int p)
int mpz_selfridge_prp(mpz_t n) aka: Lucas-Selfridge pseudoprime
int mpz_strongselfridge_prp(mpz_t n) aka: strong Lucas-Selfridge pseudoprime
int mpz_bpsw_prp(mpz_t n)
int mpz_strongbpsw_prp(mpz_t n)

Where each function can return one of:
#define PRP_ERROR -1
#define PRP_COMPOSITE 0
#define PRP_PRP 1
#define PRP_PRIME 2

You can download the code at the sourceforge site:
http://sourceforge.net/projects/mpzprp/files/

The source is licensed under the LGPL and includes a sample main() function that 
will print the result of each test for a list of 25 numbers, starting with one 
given on the command line.
(Continue reading)

Permalink | Reply | 2 comments |
headers
bodrato | 10 Aug 2011 08:21
Picon
Picon
Gravatar

Re: New mpz prp functions...

Ciao,

Il Mar, 9 Agosto 2011 3:08 am, David Cleaver ha scritto:
> Here are the prototypes for the new prp functions:

> int mpz_sprp(mpz_t n, mpz_t a) aka: Miller-Rabin pseudoprime

The Miller-Rabin test already is implemented in GMP in the file
mpz/millerrabin.c , and there is a function named mpz_probab_prime_p.
Did you consider how your function can be integrated with the existing
functions in the library?

> int mpz_strongbpsw_prp(mpz_t n)

I'd personally add at most one of them, possibly the strongest, if we can
integrate it with the current probab_prime_p.

> Again I'd like to ask, is there any formal procedure to ask for new
> functions to be included into GMP?

As far as I know, there is none. GMP is not a CAS, this means that it
should not contain lots of different functions, but only the basic ones,
so that anyone can build lots of new functions/programs using those
bricks.

We should ask to programmers using GMP if they need some new functions.
I'm sure that projects like ECM-GMP [ http://ecm.gforge.inria.fr/ ] or
PARI/GP [ http://pari.math.u-bordeaux.fr/ ] are implementing their own
(pseudo) primality testing algorithms. Do they need to have part of them
reimplemented in GMP? You may ask.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Zimmermann Paul | 10 Aug 2011 15:01
Picon
Favicon

Re: New mpz prp functions...

> We should ask to programmers using GMP if they need some new functions.
> I'm sure that projects like ECM-GMP [ http://ecm.gforge.inria.fr/ ] or
> PARI/GP [ http://pari.math.u-bordeaux.fr/ ] are implementing their own
> (pseudo) primality testing algorithms. Do they need to have part of them
> reimplemented in GMP? You may ask.

for GMP-ECM (not ECM-GMP) we rely on GMP's pseudo-primality function
(mpz_probab_prime_p), which is sufficient for our needs.

Paul Zimmermann
Permalink | Reply | 0 comments |
headers
Sven Bettscheider | 10 Aug 2011 11:34
Picon
Picon

recursive to iterative mpn/mul_fft?

Is it possible to change the following functions So that they work 
iteratively rather than recursively?

Version is gmp-5.0.2.

File: /gmp/mpn/generic/mul_fft.c

Line 531:
static void
mpn_fft_fftinv (mp_ptr *Ap, int K, mp_size_t omega, mp_size_t n, mp_ptr tp)

Line 348:
static void
mpn_fft_fft (mp_ptr *Ap, mp_size_t K, int **ll, mp_size_t omega, 
mp_size_t n, mp_size_t inc, mp_ptr tp)
Permalink | Reply | 3 comments |
headers
Torbjorn Granlund | 10 Aug 2011 19:15

Re: recursive to iterative mpn/mul_fft?

Sven Bettscheider <Sven.Bettscheider <at> gmx.de> writes:

  Is it possible to change the following functions So that they work
  iteratively rather than recursively?

I am not sure I follow you.  These functions compute the FFT transforms
iteratively.

The addition, subtraction, and multiplies by roots-of-unity are done
using function calls, which are not in themselves calling the
transformation functions.

The dyadic product done when the transforms are ready is done with
either general multiplication (for small operands), or with recursion to
FFT (for large operands).  So the dyadic products make the entire FFT
multiply code recursive.

--

-- 
Torbjörn
Permalink | Reply | 2 comments |
headers
Sven Bettscheider | 12 Aug 2011 11:06
Picon
Picon

Re: recursive to iterative mpn/mul_fft?

In function mpn_fft_fft(...)

if (K == 2){...}
     else
     {
       int j;
       int *lk = *ll;
mpn_fft_fft (Ap,     K >> 1, ll-1, 2 * omega, n, inc * 2, tp);
       mpn_fft_fft (Ap+inc, K >> 1, ll-1, 2 * omega, n, inc * 2, tp);
       /* A[2*j*inc] <- A[2*j*inc] + omega^l[k][2*j*inc] A[(2j+1)inc]
           A[(2j+1)inc] <- A[2*j*inc] + omega^l[k][(2j+1)inc] 
A[(2j+1)inc] */

     }

Is it possible to implement the red lines with using a loop (while, for)?

Am 10.08.2011 19:15, schrieb Torbjorn Granlund:
> Sven Bettscheider<Sven.Bettscheider <at> gmx.de>  writes:
>
>    Is it possible to change the following functions So that they work
>    iteratively rather than recursively?
>
> I am not sure I follow you.  These functions compute the FFT transforms
> iteratively.
>
> The addition, subtraction, and multiplies by roots-of-unity are done
> using function calls, which are not in themselves calling the
> transformation functions.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane