CoCoALib Task Table (Genova)

This table summarises the state of current and imminent tasks in CoCoALib. The first tasks are considered to be the most pressing. Full descriptions of the tasks are given below.
All time estimates and completion dates are to be considered approximate.

This section contains a short description of each task. A time estimate for a task assumes "full-time" working; as ever for software, time estimates can be wildly inaccurate (usually hopelessly optimistic).

Abstract Gaussian Reduction Currently matrix gaussian (row) reduction is implemented several times (e.g. for DetByGauss and RankByGauss). Make a single generalized "abstract" implementation. Time est.: 3 weeks. Abbott

BigInt/BigRat: Non-const return values for BigInt/BigRat fns Many fns returning a BigInt value return a const value; this was done to prevent compilation of funny expressions such as factorial(10)++. After seeing Scott Meyers's video about "rvalue references", it is clear that making the return value const would prevent C++ from using "move" operations on such const results. This is a highly undesirable restriction; so the constness should be removed from the return types Time est.: 2 days. Abbott

Buffering when printing out power products Michael reported poor performance when using sockets on M$ platforms. Cause was many short messages. Review use of buffering when sending PPs. Time est.: 1 week. Abbott

CanonicalPolyHom for polynomial rings The homomorphism R[x,y,z] into R[x][y][z] is, mathematically speaking, quite canonical, and also the viceversa. We should make this kind of homomorphisms easier to define (automatically?). Even though intuitively it looks quite obvious, it might be quite tedious to define it properly (e.g. we should probably forbid quotienting, and should we consider the symbols in R?) Should it be called "CanonicalHom"? I believe not, since applying such a homomorphism is very costly compared with homomorphism coming from a ring construction step. Time estimate: 1-3 weeks. Abbott+Bigatti

ChangeCoeffHom PolyRingHom can be quite inefficient when one just want to change coefficients (e.g. R[x] into K[x]). No operation of pp's exponents is needed, just copy the pp. Time estimate: 1 day. Abbott+Bigatti

Check use of global variables In the interests of thread safety check the use of global(static) variables; rectify if necessary. Time est.: 1 week Abbott

Clean up DistrMPoly etc. The designs of DistrMPoly, DistrMPolyInlPP, and DistrMPolyInFpPP are poor (due to scope creep during development). While the code does appear to work well, it is fragile and hard to understand/maintain. Before redesigning (see task), some cleaning up should be done to highlight unused features. Time estimate: 1 week. Abbott+Bigatti

Clean up OpenMath The OpenMath code looks to be hasty first prototype. It needs to be cleaned (and probably redesigned). Many of the input operations are missing or dodgy. Time est.: 2-3 weeks (for new design and impl). Abbott+Bigatti

Clean up OpenMathXML In OpenMathXML.H the class definitions are publicly visible. Is this necessary? If they can be moved to the .C file then I can remove the (costly) include of iostream in the header file. Time est.: 1-2 days. The .C file is full of all sort of ancient stuff including debugging code -- needs a major overhaul. Time est.: 2-3 weeks. Abbott+Bigatti

Clean up OrdvArith The file OrdvArith.C is full of commented out old code. Check that this code can be deleted, and either delete it or reactivate it. Time est.: 1-2 days. Abbott+Bigatti

Clean up ReductionCog inheritance ReductionCog concrete classes are based on Poly or Geobucket. Make two Abstract classes to avoid repeated code. Bigatti

CoCoA5 arguments Reconsider all cocoa-4 functions with more than one argument and decide if arguments should be swapped. Abbott + Bigatti

CoCoA5 automatic CanonicalHom Investigate with a suitably large class of example which Mixed Ring Arithmetics should be allowed in CoCoA-5 (e.g. f/LC(f)). A good rule could be that only "cheap" (or single-step?) automatic conversion are allowed (i.e. not PolyAlgebraHom) to avoid hidden expensive mapping, for example, when multiplying objects in a big for-loop. Moreover the ring of the result must be the ring of one of the operands, and it must be "obvious" which one (this rules out many PolyAlgebraHom). Time est.:1-3weeks Abbott + Bigatti

CoCoAServer: Improve documentation for adding new operations Improve documentation for ServerOp and RegisterServerOps. Just collect neatly all emails with Eduardo for adding new operations to the server. Time est.: 1 day. Bigatti

CoCoAServer: Names for I/O fns Change read/write into input/output for fn names in server. This will be more coherent with the naming convention used in the library. Time est.: 1 day. Abbott+Bigatti

CoCoAServer: Polys with rational coefficients to CoCoAServer Modify CoCoAServer to allow polys with integer coeffs, and to allow fractions when coeffs are rationals. Time est.: 2 weeks. Bigatti

CoCoAServer: simplify output Simplify the way to send output in CoCoA4io.C: some functions print the object itself, others print the assignment to the communication variable. All objects should have a direct printing function (then called by the assignment function). Bigatti

CoCoAServer: supervisor Exhume CoCoALib supervisor from version 0.95 (not in CVS). Compare with what Stefan Kaspar has implemented. Time estimate: 2 weeks - 1 month. Abbott

Compatibility of IsRational and IsInteger In a fraction field should applying IsInteger to numerator and denominator give the "same" result as applying IsRational to the whole element?. Time est.: decision + 3 days. Abbott

ConstRefRingElem and ConstRefPPMonoidElem Christof has suggested a way to remove the need for ConstRefRingElem and ConstRefPPMonoidElem. Check to see whether his idea will actually work in practice; if so, implement. Time est.: 3 days. Abbott

Deg incompatible PP orderings The "idealization" of a graded module with a PosTo type ordering cannot use directly the same grading as used in the components of the module. One way to circumvent the problem would be to allow PP orderings which are not degree compatible. Another solution would be to extend the grading on the module components by prepending a single value (which is the position) -- but this would require creating and using a different grading. We must decide what is the cleanest way forward, and then implement it. Time est.: ??? Abbott+Bigatti+Caboara

Degree dimension in myWDeg The PPMonoid (public) member functions myWDeg do not check the dimension of the supplied degree. At the very least there should be an assertion. Perhaps degree objects should be resizable?? Time est.: 1-2 days (discussion and implementation) May need a new error. Abbott+Bigatti

Diagonal Matrix Inheritance Zero matrices and Identity matrices are special cases of diagonal matrices. Maybe the inheritance reflect this. This could be used to simplify the code for optimized multiplication (to do) and equality tests (done). Time est.: 2 weeks. Abbott+Bigatti

Documentation for OrdvArith and PPOrdering The documentation for OrdvArith and PPOrdering is mixed up and very incomplete. Make a clean separation, and complete it. Time est.: 1 week. Abbott

Documentation for PPMonoidElem The documentation for PPMonoid should be split into PPMonoid and PPMonoidElem. Make a clean separation, and complete it. Time est.: 1 week. bigatti

Documentation for creating new rings The documentation about how to create new types of ring is inadequate. Make better documentation, perhaps using existing rings as illustrative examples. Time est.: 2 weeks. Bigatti

Examples for convert and IsInteger and IsRational The convert function does not handle overflow and underflow correctly when producing a double value. Use scalbn and C error codes to achieve correct behaviour. Add an example program showing how to use convert and related functions (e.g. IsInteger and IsRational). Time est.: 4 days. Abbott

Faster eval homomorphism Produce a better implementation of the polynomial ring "evaluation homomorphism"; perhaps even a better default implementation? Time est.: 2 weeks. Abbott+Bigatti

GBEmbeddings for ideal/module operations GBEmbeddings need to be cleaned up, made easier and more complete (including case of FractionField coefficients). In some ideal/module operations embeddings are done and undone uselessly? Bigatti+Caboara

GUI+GMP memory allocation problem CoCoA5 in the GUI sometimes crashes (confirmed only on MacIntel OS X, so far), apparently due to a memory allocation problem in GMP with running inside the GUI. A specific failing example is X := (10^131070-1984)/(10^131232); The problem goes away if GMP is configured to use a threadsafe allocator ./configure --enable-cxx --enable-alloca=malloc-reentrant However it is not a good idea to require that GMP be configured this way because the GMP documentation reports that it may adversely effect run-time performance. There appears to be no problem in the GUI when such large numbers do not arise during the computation. What to do? If we cannot find a satisfactory technical solution, at least a note must be added to the documentation. Abbott + Bigatti

HTML Make sure that all HTML files are XHTML compatible: e.g. lower-case element names, double quotes around attribute values. Applies to "static" HTML files, and ones generated by some program/script. Time est.: 3 days. false Caboara+Bigatti+Abbott inactive 2007-12-04 Complete implementation of Hilbert driven GBasis. Time est.: 4 weeks?? Abbott+Bigatti

Hilbert: final Convert into C++ the main code of Hilbert in CoCoA4. Waiting for the special univariate polynomials and the verification of Hilbert's requirements for PPWithMask. Time est.: ??? Bigatti+Abbott

Hilbert: optimized use of PPWithMask Change Hilbert code so that it uses PPWithMask instead of C type eterm. Might require some changes in the implementation of PPWithMask. Use PPVector. Time est.: 4+ weeks. Bigatti

Hilbert: reorganization and cleaning Change univariate and multivariate Hilbert code is unified using inheritance. Time est.: 1+ weeks. Bigatti

Homogeneous lists It appears it can be useful to have a (template?) class for "Homogenous lists", i.e. vectors (?) of RingElems/PPMonoidElems having the same owner. It should be reference counted. It would be quite useful for the generators of an ideal: to avoid making copies, to guarantee that all elements are in the same ring. A bit like PPVectors....
[2009-07: first step for actual implementation: "HasUniqueOwner" in tmp.H]
[2010-06: second for actual implementation: example with RingElemVector]
[2011-01: STOP is it worth ref counting with new C++? study paper] Abbott+Bigatti

Improve CanonicalHom Could modify CanonicalHom so that it can cope with more than a "single step" in the tower of ring ctors. Is this idea worth implementing? Time est.: 2 weeks (= 1 week deciding, and 1 week impl and testing). Abbott+Bigatti

Improve example programs The example programs could be clearer and easier to navigate through. For instance, one program could refer to others which are in some way related to it. Some of the examples should be especially simple, focussing on a single idea. Ideas for which examples to add can be taken from questions on the forum (e.g. "How do I do this in CoCoALib?"). A first hasty pass was completed on 2007-03-09, but a second pass will be needed. Abbott+Bigatti

Improve separation of library & server code Several pieces of code specific to the server are in the directory containing the library source. If possible, move the server specific code into the directory for the server sources. The prime candidates are GlobalInput, GlobalOutput (and so on), and RegisterServerOps and its auxiliaries. Time est.: 2-3 weeks Abbott+Bigatti

Inheritance-ready GReductor/Do_GBasis Compare Do_GBasis-like functions in order to prepare code for migration to inheritance class GMill. Time est.: 1-2 weeks. Caboara

Init. of myZero/myOne in rings All concrete ring ctors currently "naughtily" create the zero and one elements of the ring. This is naughty because the ring has not been completely constructed at that point, so conceivably calling a virtual member function might behave unexpectedly. The member functions myZero and myOne could construct the cached value upon demand (but they must also decrement the reference count when construction occurs). The current code seems to work fine on every platform tried so far, but some "good style" guides say one shouldn't call virt.mem.fns. in the ctor. Decide what to do, do it, AND DOCUMENT IT. Abbott

IsMonomial and IsHomog for DUP Decide whether IsMonomial and IsHomog are useful for Dense Univariate Polys. Adjust impl accordingly. Time est.: 1 week. Abbott+Bigatti

Makefiles Several CoCoALib/CoCoA-5 Makefiles need revision. In particular, make clean; make -j2 check builds libcocoa.a twice -- this is undesirable. Time est.: 2-3 days Abbott

MemPool via BOOST The BOOST implementation of pools is measurably faster than MemPoolFast (about 20 percent, or 35 percent when the MemPool alloc fn is not inlined). We should make a MemPool wrapper for a BOOST pool. JAA thinks it is worth keeping MemPool for the moment as it offers a debugging mode. NOTE: the BOOST singleton_pool impl is threadsafe but is about 5 times slower than their plain pool. BOOST does not offer a non-singleton pool which is threadsafe (don't know why); JAA cannot see how to use a singleton pool as the impl inside a (dynamically created) MemPool. Check that BOOST pool interface is superset of MemPool interface; perhaps revise MemPool interface to be closer to that of BOOST pools? See file pool.C for an example of how to use BOOST pools. Abbott

Module and FGModule Decide whether module and FGModule should be merged or kept distinct. Note that the documentation for FGModule is largely absent. A considerable overhaul is needed. Time est.: 3 weeks. Abbott+Bigatti

More operations on ideals generated by monomials more operations on ideals generated by monomials. Now we have Gbasis/interreduction, intersection, colon, multiplication, for sqfr: AlexanderDual, PrimaryDecomposition. Bigatti

Mysterious test failures on Digital Alpha Investigate mysterious bugs which cause some tests (ComputeSyz) to fail on Digital Alpha when compiled with optimization. No idea when we might get it fixed. JAA thinks it is probably a compiler bug. Time est.: <1 week Bigatti+Abbott

NTL integration Without doubt NTL offers some impressive implementations of algorithms for dense univariate polynomials and matrices of integers (or rationals?). Some NTL functions should be integrated into CoCoALib as a pilot project for understanding how conditional builds can be achieved -- CoCoALib should build equally easily with or without NTL cooperation (of course, some operations may be missing from a CoCoALib with NTL support). Time estimate: at least 3-4 weeks Abbott+Caboara

Names of GlobalInput, etc The names GlobalInput, GlobalOutput, GlobalLogput and GlobalErrput are cumbersome (perhaps even ugly). Devise better names, and ideally remove the need for the annoying parentheses. Time est.: ??? Abbott

NaturalMap Implement NaturalMap for creating the natural (partial) ring hom between two rings, if possible. We'll also need a function to say whether NaturalMap would succeed or fail. An initial partial implementation would be acceptable. Time est. 2 weeks. Abbott

Normaliz integration & extension Clean prototype CoCoALib interface to "Normaliz": use the namespace normaliz or Normaliz (Christof does not care about capitalization). Also add interfaces to more Normaliz fns. Time estimate: about 1 week Bigatti+Soeger

Normalization of GCDs Improve the way GCDs are normalized inside fraction fields. JAA has already emailed a bad example where coeffs are rationals where num & den each have almost 100 digits but true result is is just 3x+4. Time estimate: about 2 weeks Abbott

Normalization of fractions Improve the way fractions are normalized inside fraction fields. JAA has already emailed a bad example where coeffs grow to 8000000 digits. Time estimate: about 2 weeks Abbott

Optimized matrix multiplication Matrix multiplication is currently done in a "dense" way (maybe because the programmer is a bit dense :-) make it work more efficiently when at least one arg has a special structure (e.g. sparse, diagonal, completely zero, etc). No sure idea how to do this in a general way -- maybe each matrix could give an indication of how "clever" it is at multiplying (perhaps an estimate of run-time cost???) Time est.: 2 weeks. Abbott+Bigatti

PartialRingHom To better reflect the underlying maths, and to avoid some nasty surprises introduce a "partial RingHom" type (from which RingHom will probably derive). Check all pseudo-ctors, to make sure they return a partial or full ringhom appropriately. Here is a problematic example which stimulated the thought of making partial ringhoms separate: let (partial) phi:QQ-->ZZ, and let psi:ZZ-->QQ, then the composition psi(phi) looks like a ringhom QQ-->QQ but it is not!! We must be careful when composing: with full ringhoms we can take short cuts, but if the inner ringhom is partial then taking shortcuts can produce wrong results (but is probably OK in some cases too). Time estimate: 1-2 weeks. Abbott + Bigatti

Permutation iterator Write a permutation iterator: defining operator++ and operator[] for accessing the k-th index. The following algorithm (taken from Wikipedia) generates the next permutation lexicographically after a given permutation. It changes the given permutation in-place.

   1. Find the largest index j such that a[j] < a[j + 1]. If no such index exists, the permutation is the last permutation.
   2. Find the largest index l such that a[j] < a[l]. Since j + 1 is such an index, l is well defined and satisfies j < l.
   3. Swap a[j] with a[l].
   4. Reverse the sequence from a[j + 1] up to and including the final element a[n].

Time est: 2-3 days. Abbott

Positive gradings Right now only gradings with non-negative entries are allowed (because only ordering matrices with non-negative entries are allowed) Design how to deal with negative entries. Tiem est: ??? Bigatti

Power of matrices and ideals Still missing: negative powers for matrices, optimized implementations? Time est: 2-3 days. Abbott + Bigatti

PowerProduct type Christof observed that having a type PowerProduct would be more comprehensible than PPMonoidElem. Discuss, decide, and implement (if appropriate). An abbreviated name could be PowerProd. Time est: 1 week. Abbott + Bigatti

Reconsider The "New" prefix A current naming convention uses the prefix "New" for certain functions which create new values (e.g. NewFractionField). However, the use of the prefix is not universal (e.g. RingElem ctor), and the prefix is somewhat C++-ish. An alternative could be to use the prefix "Make". We should also review precisely when it is appropriate to use the prefix, and document why. Time est.: 1-2 weeks. Abbott+Bigatti

Redesign DistrMPoly etc. The designs of DistrMPoly, DistrMPolyInlPP, and DistrMPolyInFpPP are poor (due to scope creep during development). While the code does appear to work well, it is fragile and hard to understand/maintain. Given that this code forms a major part of the foundations of CoCoALib, it is essential that this code be redesigned and rebuilt before version 1.0. The new design must be cleaner, easier to understand, and no slower (in any circumstance). Probably the best period for undertaking this work is early 2007; it is work which produces "invisible progress". It is quite likely that other work on the library will be suspended during the rewrite. Time estimate: 1-2 months. Abbott+Bigatti

Redmine: move task table to Redmine We really need to move to a proper task management program. Redmine seems like a good choice for our purposes. We are currently waiting for Fronda to set up a Redmine server for us. Time est.: 1 week after Redmine is installed. Abbott+Bigatti

Reduce wasteful alloc/free in RingTwinFloat Several internal ops in the impl of RingTwinFloat make wasteful alloc/free cycles. Replace most of these by use of "workspaces" held by the ring (so alloc/free occur only when ring is created/destroyed). CHECK thread safety of this idea!! Time est.: 1 week (mostly for testing). Abbott

Registration system for dtor of globals Consider implementing a registration system for dtors of global variables. To use a new global variable you just have to register a (pseudo-)dtor for it, so that it can be destroyed during destruction of the global manager. Time est.: 2-3 weeks Abbott

Replace SmartPtrIRC by boost The BOOST library offers a sophisticated smart ptr implementation. Can we use that instead of SmartPtrIRC? If so, there will be several consequential changes to the rest of the library. Analysis will require several days; no time estimate for consequential changes. The real problem is that BOOST is huge. Abbott+Bigatti

Requirements analysis of interactive language Review of the requirements for the new interactive language and how they interact. The aim is to produce a report which analyses the various compromises and then indicates a final choice to proceed with for the production of a parser. All decisions should be justfied so that a later reconsideration could be effected cheaply. Time est.: 3-4 weeks. Abbott+Bigatti+Caboara+Figari

Ring of infinitesimals A ring for computing with first order infinitesimals would be handy for some. Time est.: 2 weeks (for design, impl, and testing). Abbott

RingDUPZ (for Hilbert) Special concrete class for univariate polynomials over Z; inspired by the efficient implementation of unipoly for Hilbert from CoCoA-4. Time est.: 2-3 weeks. Bigatti+Abbott

RingDUPZ (generic) Concrete class for univariate polynomials over any ring. Inspired by the efficient implementation of unipoly for Hilbert from CoCoA-4. Time est.: 1-2 weeks. Bigatti+Abbott

RingElemVector (same ring, ref counted) As a useful particular case of Homogenous lists (task) We have a prototype in RingElemVector: reference counted (copy on write) vector of RingElems in the same ring. It can be used for generators and gbases of ideals (in order to avoid copies)
[2010-06: first prototype as ex-RingElemVector] Abbott+Bigatti

Self-saturating (and cleanup for GB code) Buchberger's algorithm for non-homogeneous input can be implemented as a self-saturating process (similar to what was done for Toric by Bigatti): Input polynomials will be homogenized with h; then every power of h which is a factor of a polynomials in the running computation may be cancelled out. This might be a mathematically clean way to interpret sugar (for GradingDim 1). Theory is all set. Clean implementation waits for task sugar and GReductor/Do_GBasis Bigatti+Caboara+Abbott

Socket Test The way the cocoa-4 function testing whether the socket and server are working provokes an error from CoCoAServer. This is a bad design! Time est.: 2-3 days (for design, impl, and testing). Bigatti

Sundries Here are some ideas for algorithms to implement in CoCoALib. Factorization over the reals, complex root finding. Abbott

Template fns for power There are two algorithms for powers: sequential and quadratic. Is it possible to write template functions working for RingElems, PPMonoidElem, matrices, ideals...? How many types are involved? Should it include also the trivial cases (0, 1)? and the negative powers? Will need unification of multiplication syntax. Time est.: 1 week Abbott

Template fns in io.H The presence of the template functions in io.H requires that iostream be included, but iostream is rather lengthy, so compilation becomes slow. How to rectify the situation? Time est.: < 1 week! Abbott

Toric Mill Design and implement Toric Mill using inheritance to "choose" between the different concrete algorithms (currently Toric uses part of the old C code which is NOT thread-safe). This will be pilot design for the Groebner Mill. Time est.: almost 1 month. Bigatti+Abbott

Tuples iterator Vaguely related with permutation iterator Time est: 2-3 days. Abbott+Bigatti

Unified RingFp Unify the three different implementations of RingFp, RingFpLog, RingFpDouble -- perhaps use a SmallFpArith object to choose the implementation? Abbott

Unordered PPMonoids Consider modifying existing polynomial code so that it tolerates PPMonoids which are not arithmetically ordered (e.g. PPMonoidModSquares). The elements of the PPMonoid must be ordered so that polynomials have canonical forms. Multiplication of a polynomial by a PP will be more complicated: there may be zero divisors, terms may merge, terms may swap ordering, etc. Decide how invasive such a change would be, and whether implementing it is worthwhile. Bigatti+Abbott

Warnings We have sometimes wandered whether some commands should return an error or not, for example "content(f)" when the coefficient ring is a field. Mathematically "1" is a correct answer, but probably it means that the program is not doing what is intended by the user. Maybe a "warning" mechanism could be usefully applied to such cases. Bigatti+Abbott

Weyl algebra Weyl algebras have been revived: need proper testing. Bigatti+??

ZZ or GMP's mpz_class? Do we want our own separate class for big integers, or should we simply use GMP's own mpz_class. If we use our own class, we can modify it as we like (e.g. put in ref counts, see next task), but then we also have to write lots of tedious forwarding functions. Time est.: 2 weeks to decide, and 2 weeks to implement (if the decision favours reimplementation). Abbott

ZZ ref count Decide whether to use reference counts inside ZZ values. This would avoid the wasteful copying when ZZ values are returned from functions (but the new C++ standard offers a completely general mechanism for avoid these wasteful copies). Could reference counting provide benefits in other cases? Time est.: 1 week to decide, and 2 weeks to implement (if the decision favours implementation). Abbott

Development stages

To describe the progress of each subtask (contributing C++ code to the library), I suggest using the following scheme for identifying what has been done, and what is still to be done. The intention is that normally all lower numbered stages be completed before progressing to the higher numbered stages. For other types of task, the task description should give an indication of progress.

• (1) subproject start (incl specification of subproject)


• (2a) abstract algm design, choice of data-structures, etc.
• (2b) initial test set
• (2c) early prototype, mostly works, maybe some bugs


• (3a) late prototype, fully working, almost no bugs
• (3b) comprehensive test cases


• (4a) final C++ version (incl. relevant build commands)
• (4b) maybe extra tests
• (4c) portability and quality control issues
• (4d) documentation


• (5a)-(5d) independent verification of stages (4a)-(4d)

Status

For each task, the table indicates the current "status". Here are the main choices for the status:

• active being worked on currently
• inactive not being worked on currently (but work should begin fairly soon)
• waiting progress suspended until some other task has progressed enough
• resting temporarily suspended (e.g. holiday)
• other explanation of actual status is with task description

Tasks we believe to have been completed are moved from the table to here.
The dates are only approximate and this table is updated less often than it should be (too much work on CoCoALib ;-).