[BACK]Return to TODO CVS log [TXT][DIR] Up to [local] / OpenXM_contrib / pari-2.2

File: [local] / OpenXM_contrib / pari-2.2 / Attic / TODO (download)

Revision 1.1.1.1 (vendor branch), Tue Oct 2 11:16:55 2001 UTC (22 years, 7 months ago) by noro
Branch: NORO
CVS Tags: RELEASE_1_2_1, PARI_2_2
Changes since 1.1: +0 -0 lines

Imported pari-2.2.1(alpha).

This file lists the things that ought to be implemented / fixed. It is
hopelessly incomplete right now, but it's a start. Most items require major
work, and may not be that desireable after all. If you intend to work on
any of these things, have a look at CVS.txt and drop an email to pari-dev.

Priority classification (first column): [subjective and debatable!]
5    as soon as possible
4    should be done
3    nice to have
2    maybe not
1    probably not
-    unclassified

***************************   BUGS (general)     ****************************
Unless specified otherwise, examples assume 32bit machine and default precision 

5  setrand(5);thueinit(x^3 + x^2 - 43690*x - 3529208)
   ***   non positive argument in mplog. \\ precision problem

4  precision problems in polgalois:
   setrand(7);
   polgalois(x^8+162644002617632464507038884216211529274267271168000002)
   gives wrong result at \p28 [32,-1,17], correct at \p38 [32,-1,15]

4  gcmp/gegal not transitive: [] == 0, [0] == 0, but [0] != []

4  rnfpolred is numerically unstable:
   ? rnfpolred(nfinit(quadpoly(904,y)),quadray(904,1))
     ***   division by zero in gdiv, gdivgs or ginv

4  qfbclassno(x < 0) may give a wrong result [e.g x = -2878367]

4  t_SER computations much too slow when number of terms increase, even
   when applying a trivial formula, e.g cos(x) at \ps 10000

3  many functions assume MAXVARN is a free variable, yielding bogus
   results if the input involve it (only affect library programming).

3  quadclassunit not reliable when fed non fundamental discriminants
   (infinite loop [e.g quadclassunit(-352)], wrong result)

3  ellinit over Q_2 doesn't work (AGM loses too much precision)

3  ellpointtoz over Q_p makes no difference between P and -P (corrected over
   C by a cheap trick)

3  recursive plot easily fooled. One could split intervals in 3 + make sure
   size of neighbouring intervals don't differ too much.

***************************   BUGS (GP specific) ****************************

5  life of GP variables too short in pathological cases:
   v = concat(v, [v=1,v=2]); concat(v, [v=1,v=2]) --> SEGV

4  changing primelimit from within forprime loop yields unpredictable results

3  after allocatemem() / default(parisize, ...), the rest of the command is
discarded (ends by a longjmp).

2  under GP after an error, memory is only recovered from "entire variables".
   Individual components of lists/vectors/matrices are left alone if the
   GLOBAL object wasn't modified during the last cycle (i.e only v[x] = ... 
   occured)

1  sum(i=1,3000, exp(-i^2)) --> overflow in R*R
   The "negligible" terms should be neglegted, not overflow because of the
   way the computation is done. [ Tough to correct! ]

***************************  DOCUMENTATION    ****************************

5  complete/update the tutorial (esp. section 11 and 12)

4  add examples for all functions in Chapter 3

4  separate chapter 4 and 5 and document the innards of PARI (entree,
   pariFILE, bloc ...)

2  HTML version (pod ? SGML ? yodl ???)

***************************   DEVELOPMENT     ****************************

5  write decent (specialized) benches

3  switch to autoconf

***************************   ALGORITHMS      ****************************

Kernel:
=======
5  check NaN in dbltor and related routines

4  benchmark / profile basic functions and see what needs to be done

4  finish t_REAL Karatsuba and diviiexact

4  inline level0 routines should operate on _limbs_, not on words.

3  inline more assembler kernels, alpha in particular (ix86 and sparc are
   already inline).

3  FFT for basic types and polynomials (say in A[X], for A = Z, F_q, ...)

2  add support for different multiprecision kernels (a la LiDIA)

Misc:
=====
5  don't assume that nf.zk is HNF. Allow using LLL-T2-reduced bases (with
   first element 1) --> huge improvement to all idealred computations (esp.
   bnfisprincipal, bnfinit)

4  graphics: allow FIG output (besides PostScript) [easier to edit!]

4  decent finite field package (remove all the nfxxxmodpr functions)

4  rnfkummer (doesn't work)

4  nfsubfields [use known subfields to discard blocs right away] (current uses
   far too much memory)

4  LLL over R (not stable). Clean up bibli1.c (remove duplicate code)

4  rethink the element_mul type of functions: multiplication table is O(n^3),
   polynomial multiplication + remainder is O(n^2) [+ can use Karatsuba/FFT]

3  \ and % (euclidean division) could accept more arguments (e.g t_REAL)
   x \ y := floor(x/y) if y > 0 and floor(x/y) + 1 if y < 0
   x % y := x - y(x\y) [ hence 0 <= x%y < |y| ]

3  zetak is very inefficient and unable to handle most fields of degree > 6

3  have quadclassunit return bnf structure

3  2-adic initell

3  p-adic ellztopoint

***************************   LIBRARY DESIGN   ****************************

4  a system of DEBUGLEVEL classes [e.g \g 5 "LLL" ] (such that the user can
   easily define new ones)

4  allow generic functions to process and produce t_SMALL's

4  remove all dependences on types ordering [if (typ(x) < t_POL) ...]

3  integrate Ilya's code for yet bigger prime tables (pari-dev-435). Unify
   functions using diffptr (if possible correcting the forprime bug above)
  
3  remove global variables gpi, geuler: their precision is unpredictable
   (at least as much as requested in last const[pi|euler](), possibly much
   more). Explicit call to mp[pi|euler] should be required. Will break
   existing code...

3  rename library functions following GP names

3  rewrite the generic functions (gadd/gmul/gdiv plus a couple of others) to
   use (two-dimensional) table lookups instead of switches

3  introduce "special" types for objects which are really containers and
   should be defined by a secondary type (e.g number fields, finite fields,
   p-adic fields, elliptic curves, ...). Would keep list of types small
   (and fast)

3  better representations for multivariate polynomials

3  type "element in" ([number|finite] field...), "point" on elliptic curve

3  find a way to deal (generically) with "integral object + its content"
   Application (e.g): fractional ideals much more efficient.

2  "mute" variables for t_POLMOD. Should have Mod(x,x^2+1) == Mod(y,y^2+1).

2  have some header magic (transparently) prepend some prefix (e.g "pari_")
   before all exported functions to prevent name conflicts. Build alias
   files for debuggers

2  should use vsnprintf instead of vsprintf in pariputsf. Requires GNU libio.
   [paripusf uses static buffer which should be ok for "most" purposes]

***************************   GP DESIGN       ****************************

5  remove limitation to 8 arguments for static functions (argvec[9])

4  use divide & conquer approach in string / integer conversions

4  let forprime(n=a, b, ...) work even if a,b above primelimit
   (maybe with a Warning), via simple sieve + pseudo primality test

3  split matrix_block in 2 parts: exploration + assignment. Would allow
   Math::Pari to use complicated x[][][][] constructs

3  changevar with explicit (incomplete) permutation. E.g
   changevar(p, [x,y], [a,b]) for x -> a, y -> b
   add a flag to substitute in succession or in parallel (e.g if a involves y)

3  possibility to save and load a session (variables, functions, defaults)

3  a type t_FILE [current: stream re-opened/flushed/closed after every single
   write(): disaster when one wants to write often to the same file]

3  add a possibility to increase the maximal recursion depth (need to 
   increase the GP process stack: use setrlimit(RLIMIT_STACK,) + fork)

***************************   TOOLS           ****************************

4  a script converting prototype to parser code (e.g GEN f(GEN,GEN) --> "GG")

3  a script to translate "legacy" GP code into something using GP2 function
   names

3  write a gp-to-C compiler (adding #defines in anal.c + modifying the
   table of functions in init.c, etc, to include the explicit function name).
   Should be easy: the code is mostly there.

3  write an analog of the 'echo' default which would print code as it is
   executed, not as it is read

2  write a GP scripts debugger (cf above)

2  write a GP scripts profiler (cf above)