Re: dumb question about rationals

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Wed, Jun 08, 2005 at 02:07:42PM +0200, Vincent Torri wrote:
> Ok, thank you for your quick answer.
> 
> My aim is to construct rationals from any long. It seems that
>  r = gdiv (stoi (l1), stoi (l2));
> is working (l1 and l2 are long int).

Yes.

> In that case, should I construct r, that is, should I call cgetg ?

No, gdiv will do it for you.

> If no, what is the precision of the rational ? 

Infinite

> May i change it after this operation ?

Yes, you can convert it to a real with finite precision by multiplying
it by 1. with the precision you want or by calling gaffect.

> Also, I've not well undestood the use of cgetg.

cgetg() allocate objects on the PARI stack. Objects return by standard
PARI functions are already allocated somewhere and usually on the stack,
so you only need to use cgetg() when you want to build objects
piece-wise. For example if you don't want PARI wasting time checking if
l1 and l2 are coprime (because you know it is the case), you can do

r=cgetg(3,t_FRAC); r[1]=stoi (l1); r[2]=stoi (l2);

instead of

gdiv (stoi (l1), stoi (l2));

but usually it is done for vectors and matrices.

> cgetg (N, t_FRAC) allocate a rational whose components (numerator and 
> denominator) are coded on N*32 bits, right ?

No, it is the length of the topmost part of the object. For a t_FRAC it
is always 3 (1 codeword + 1 numerator + 1 denominator).

> In case that there is an overflow, does PARI increase the precision of the 
> rational itself, or is there an error message (or something else) ?

PARI functions never modify their input. Instead they allocate memory
in the stack to store the result, so an overflow is not possible since PARI 
will alway allocate enough memory.

> I ask that because the computations I do lead to intermediate rationals 
> with large coprime numerator and denominator (I don't know the limit of 
> these numbers).

If you need to handle very large numbers, you can try to build PARI with
GMP support which is much faster in that case.

Cheers,
Bill.