Functions variants

[Daniele Varrazzo]

On Sat, Apr 9, 2011 at 3:02 PM, Torbjorn Granlund <tg at gmplib.org> wrote:
> Daniele Varrazzo <daniele.varrazzo at gmail.com> writes:
>
>  Are the _ui variants of the functions just a convenience wrapper to
>  simplify writing C code without allocation/initialization of one of
>  the arguments, or are they wrapper for a implementation faster than
>  the algorithms used in the more generic case?
>
> The _ui variants are faster iff an argument is an 'unsigned long'.  It
> will then save the time to assign the unsigned long to an mpz_t
> variable, and perhaps for mpz_init/mpz_clear.
>
> If the value is already in an mpz_t, you should not extract it and call
> an _ui function.

Thank you for the explanation. I think my choices have gone in the
right direction then.

PostgreSQL offers functions/operators overloading so I was wondering
if it would have been a win to also define operators such as int (op)
mpz. However working with overloaded functions, I've noticed some
difficulties: whenever input types are not specified and/or when
casting rules would allow the use of more than one variant of the
operator, the database refuses to guess and gives an error. An
operation such as mpz(10) + 20 would become a problem because 20 can
be either a int4 type or an mpz, and I should have provided both the
definitions.

So the choice was between more liberal cast rules or multiple-defined
functions and operators. I have chosen a more liberal cast thus having
promotions int -> mpz or decimal -> mpq happen implicitly as there is
no loss of information and it simplifies other tasks. Losing an
eventual extra bit of performance of being able to invoke mpz_mul_ui
instead of mpz_mul is probably not so relevant in the context of GMP
used in the database.

-- Daniele