This file lists the things that ought to be implemented / fixed.  Most
items require major work, and some 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
0    no
-    unclassified

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

5  bnfinit sometimes gives wrong answers because we cheat on the value of
Bach's bound, using B := 0.3 log^2 D by default, where 0.3 should really be 12
(under GRH), or some suitably optimized bound following Bach's article. If
the prime ideals of norm <= B do not generate the classgroup, we may not detect it, and compute junk. Ex:
 * setrand(3); bnfinit(y^4 + 1190*y^2 + 1416100).cyc --> [8,2,2,2].
   Wrong. The correct structure is [8,4,2].

 * setrand(1414185642); bnfinit(y^4 + 635*y^2 + 403225).reg is twice
the correct value.

 * setrand(867341586); bnfinit(y^4 - y^3 + 6122*y^2 + 6121*y + 37466641).gen
is wrong [second one is principal]. Group structure and regulator are correct!

4  factorback should not accept [;] since matrix(0,2) is the only valid
   form of an empty matrix input, corresponding e.g to factor(1). But the
   empty matrix is used in many places as a marker for a void factorization.
   This convention should be encapsulated; then we may declare [;] invalid
   input.

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

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

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

3  mathnfmod([1,2;2,0]/3,2) --> SEGV: easy to fix locally. But the
   documentations specifies that the input must be integral and almost all
   routines can be broken (SEGV) by forging clever enough invalid inputs.

   PARI is not strongly typed, and thorough type checking is expensive if
   repeated over and over again on the same objects. Adding more quick
   specialized checks in each routine is not the solution: it will simply be a
   little harder to break, at the expense of unmaintainable code. A solution
   would be to allow dynamic GEN typing that would store type information once
   it's computed. How useful would this be ?

3  some functions assume MAXVARN is a free variable, yielding bogus
   results if the input involves it (only affects library programming).

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

1  O(x) * y --> O(x)
   O(y) * x --> O(y) * x
   [ design flaw in the current model for multivariate power series. Some work
   to change it, no application for this in the current PARI code... ]

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

-  v = vector(2); v[1] = v = 0  --> SEGV. Occurs with high probability if
   any variable is "deleted", while it (or part of it) is still in use 
   Reference count could be helpful here.

-  saving an object containing high variable numbers in binary form, then
   reading it back in a virgin session will create an invalid object,
   accessing undefined variables (SEGV).
   Should replace direct access to polx[] and polun[] arrays by a wrapper
   which would check variable number first. Or fill them completely on 
   startup.

4  changing primelimit from within forprime loop yields unpredictable results

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)

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

5  add examples for all functions in Chapter 3

4  document the innards of PARI (entree, pariFILE, bloc, CATCH/TRY, ...)

***************************  MISCELLANEOUS    ****************************

5  write more benches (specialized ones) 

2  switch to autoconf

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

Kernel:
=======
5  implement Jebelean-Krandick diviiexact

5  implement Mulders/Hanrot-Zimmermann Karatsuba short product t_REAL * t_REAL

4  support standard rounding modes in floating point operations

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

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

4  use divide & conquer approach in string / integer conversions

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

2  interval arithmetic

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

0  check NaN in dbltor and related routines
   [ not worth it ]

Misc:
=====
5  add an optional argument to content, denominator, numerator to specify
   the main variable

4  decent (non-prime) finite field package [ esp. in small characteristic ]

4  rnfkummer (non-prime degree)

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

3  PSLQ (algdep(x,n, -3)) is very slow, PSLQ Level2 (algdep(x,n, -4)) is even
   slower and very unreliable. Until somebody fixes this, use LLL.

3  zetak is very inefficient, unable to handle most fields of degree > 8, and
   gives mostly bogus results at high precision. E.g.
   \p300
   zetak(zetakinit(x^2-2),2) --> ~ 1e183
   Also, also close to (but not at) rationnal integers:
   ? zetak(zetakinit(x),3-1e-38)
   %1 = 7.41787592 E21
   To be rewritten...

3  have quadclassunit return bnf structure

3  2-adic initell

3  p-adic ellztopoint

0  graphics: allow FIG output (besides PostScript) [easier to edit!]
   [ use pstoedit ]

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

5  "PARI formats" have a %Z conversion character to print a GEN object. We
   should support  %m.nZ, %0nZ, %-nZ, etc. with standard meanings.

5  add (printf-style) library functions corresponding to GP routines print*

5  add a 'variable' as an optional last argument in content, denominator,
   numerator, as is done in divrem (cf. 2.6.2)

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

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

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  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  sparse representations for multivariate polynomials and matrices.

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

3  find a way to deal (generically) with "integral object + its content"
   [ rational arithmetic would be much more efficient, when polynomials or
     matrices are involved. Currently, the content is being recomputed all
     the time, removed, then multiplied back in ]

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

0  "mute" variables for t_POLMOD. Should have Mod(x,x^2+1) == Mod(y,y^2+1).
   [ too confusing ]

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

-  rework the semantics of "trap". 

-  Allow GP to trap an OS signal. Suppose that gp runs, say in nohup mode, and
   it takes several days to complete the program. In meantime several things
   can happen resulting in shutdown of the machine. On shutdown all programs
   receive SIGTERM signal. I would like gp to be able to trap this signal and
   when it receives one, to execute some gp command, e.g saving all settings
   with full accuracy (e.g writebin).

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

5  add a printf command: simple interface to pariputsf allowing only %Z
   conversion characters  (see related entry in LIBRARY DESIGN section)

5  remove limitation to 8 arguments for static functions (argvec[9])
   [ how to do this ??? ]

4  extend forprime(n=a,b,...) so that b can go over primelimit [cut [a,b]
   in large intervals, sieve out multiple of small primes there, then use
   isprime() on the rest]

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]

0  add a possibility to increase the maximal recursion depth (need to 
   increase the GP process stack: use setrlimit(RLIMIT_STACK,) + fork)
   [ was never requested and wouldn't be portable. Do it yourself before
   launching gp ]

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

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

2  write a GP scripts debugger

2  write a GP scripts profiler

0  a script to translate "legacy" GP code into something using GP2 function
   names [ was never requested, and GP2 was released in 1997 ]
