nth_prime

[Niels Möller]

Seth Troisi <braintwo at gmail.com> writes:

> All that's left is a small number of conceptional questions
> * Does anyone know the reason for "ASSERT (n <= GMP_NUMB_MAX);"
> in mpz_primorial_ui.c?

It's possible to compile gmp with artificially small type for mp_limb_t,
only 4 or 8 bits. This assert will crash in a clear way if that causes
problems. Maybe gmp_primesieve should take an unsigned long argument
rather than mp_limb_t?

> * What should happen on calls for nth_prime(p, 0) return? It feels
> undefined but setting p = 2 makes sense as a reasonable default.

I think your docs said that it returns 2, and that seems reasonable to
me. Not sure what the mathematic convention for numbering primes is,
though. At least pari's starts numbering primes with p_1 = 2, p_2 = 3,
... But numbering from 0 is usually preferable in a C library.

> * Would you accept a fix for ~20 instances of missing SpacesBeforeParens[4]
> in test files[3]?

I think so.

> * Why do some places use gmp_printf("%Zd") vs mpz_out_str(stdout, 10, <X>)
> see [4]

I don't think we have attempted any consistensy here. Just like one can
use can either puts(s) or printf("%s", s) when one doesn't need any
other features of printf. I think local consistency is probably more
important; if all other nearby output is done with gmp_printf, it's
probably better to stick to that even where mpz_out_str would do.

And I think mpz_out_str is older than gmp_printf.

> * Is it bad if the signature is "unsigned long int" in gmp-h.in but
> "unsigned long" in implementation? see [5]

I don't think so, that's just two equivalent names for the same type.
Myself, I usually write just "short" or "long", and don't use the longer
forms "short int" or "long int".

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.