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 application]. 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. -- 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]