Karim Belabas on Tue, 02 Mar 2004 20:40:05 +0100

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Matrix initialization in Library mode

* Mikael Johansson [2004-03-02 13:09]:
> Now I've reached the point where I need to start involving the Pari 
> library, and promptly run into slight problems. I need to initialize a 
> (probably rather sparse) matrix with entries in {-1, 0, 1} for use with 
> either the keri or ker_mod_p library calls. The users guide gives in 
> section 4.3 an example on how to create a matrix by using the cgetg 
> command recursively - first for the root, and then for the columns of the 
> matrix; but on the other hand, the entries in section 4.5 specifying the 
> handling of t_MAT and t_COL state that these are introduced for specific 
> GP use and recommend that one uses standard malloced C matrices when 
> programming in library mode.

The docs say the _next_ two types (meaning t_STR and t_LIST) not the
_previous_ two (t_COL and t_MAT). You should use them.

You may use malloced matrices in libpari programming for utmost efficiency
but the odds are you will have to work much harder for a negligible gain
[ if not, I'm interested in a patch :-) ]

> Is there a way to build the matrix in malloced memory and then introduce 
> it to Pari for use of the rank calculation functions? Or should I ignore 
> the comment in section 4.5? The code example with cgetg allocated 4 t_COLs 
> of size 5 as the initialization for a 4x3 matrix - why 5?

Because your t_COLs have 1 codeword + 4 entries = 5. In the same spirit your
t_MAT has 1 codeword + 3 "entries" (columns) = 4.

> I obviously miss certain parts of the programming philosophy, and await 
> enlightenment hopefully.

This depends on the version of pari you are using. I would advise using the
developement version, _not_ the stable one. In this case, the command

   FpM_ker(GEN M, GEN p)

has replaced ker_mod_p. All the internal modular routines have been renamed
according to a consistant scheme, where prefixes indicate the type of the
arguments, followed by the operation. Here FpM stands for a M(atrix) whose
coefficients are in Fp (t_INTs assumed to satisfy to 0 <= x < p). FpX would
be a polynomial, FqX the same over a non-prime finite fields, etc.

Provided p < 2^32, you may use directly 

   Flm_ker(GEN m, ulong l)

(which would be called by FpM_ker anyway, but doing it yourself may reduce
memory usage by a non-negligible constant factor), where m is a t_MAT whose
columns are _not_ t_COLs but t_VECSMALLs = 1 codeword + entries which are
ordinary C long integers [assumed to satisfy 0 <= x < l in this particular

There is no such optimized routine for integer kernels, you have to use a
regular t_MAT of t_COLs with t_INT entries.

Note that the ZM_Flm(GEN M, ulong l) and Flm_ZM(GEN m) convert back and forth
between the two formats. You even have ZM_zm(GEN M) and zm_ZM(GEN m)
to convert without reduction mod l (and then ZM_zm will fail if an entry is
too large).

All this (and much more) from the new modular kernel needs to be documented. 
I will try to do this in the near future, but I have little free time...

Hope this helps,

Karim Belabas                     Tel: (+33) (0)1 69 15 57 48
Dep. de Mathematiques, Bat. 425   Fax: (+33) (0)1 69 15 60 19
Universite Paris-Sud              http://www.math.u-psud.fr/~belabas/ 
F-91405 Orsay (France)            http://pari.math.u-bordeaux.fr/  [PARI/GP]