C++ factorial, primorial

[Marc Glisse]

On Sun, 29 Jun 2014, Tor Myklebust wrote:

> On Sun, 29 Jun 2014, Marc Glisse wrote:
>
>> 1) factorial(42)
>> 2) factorial(z)
>> 3) mpz_class::factorial(42)
>> 4) mpz_class::factorial(z)
>> 5) gmpxx::factorial(42)
>> 6) gmpxx::factorial(z)
>> 7) z.factorial()
>> 
>> 1 is bad, as said above. 7 is not so good because most of the time we want 
>> to compute factorial of an int and don't want to convert it to mpz_class 
>> first. All the others seem ok to me. Supporting both 3-4 and 5-6 seems 
>> unnecessary. 5-6 have the advantage that a user can write:
>> using gmpxx::factorial;
>> and then use 1 and 2.
>
> There doesn't seem to be a namespace gmpxx in existing gmp, so 5 and 6 seem a 
> little weird.  (If there were, and mpz_class were in namespace gmpxx, Koenig 
> lookup would make 5 and 6 unequivocally the right thing to do.)

There are no static functions in mpz_class either, so I don't think it is 
that much weirder to type gmpxx::factorial than mpz_class::factorial. I 
don't have a strong preference. I was in favor of 3-4 when I wrote the 
first email, but warmed up to 5-6 in the second one.

> Now...mpz_class is a typedef for __gmp_expr<mpz_t, mpz_t>.  __gmp_expr is an 
> implementation detail that client code shouldn't touch.  What about tossing 
> __gmp_expr into namespace gmpxx, leaving mpz_class as a typedef in the 
> top-level namespace?  Maybe you break the ABI doing this (or maybe not), but 
> you can move everything into a namespace where you can freely define free 
> functions without worrying about pollution.

It does break the ABI. And if I am going to break the ABI, I would rather 
wait until there are better reasons to do it than the factorial function.

>From a user perspective, it would not make a lot of difference. We would 
still use mpz_class, write a+b, call floor(f), etc. And we would call 
gmpxx::factorial(42), which is the only place the user would see that 
namespace.

-- 
Marc Glisse