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 ]