Todo List

Member CanonicalTermConsumer::consumeRing (const VarNames &names)

fix this.

Member CliParams::add (auto_ptr< Parameter > param)

: fix that this doesn't actually take over ownership

Member Deformer::Deformer (Ideal &ideal, const IdealOrderer &deformationOrder, bool makeStronglyGeneric=true)

Implement makeStronglyGeneric == false.

Member DimensionAction::DimensionAction ()

Expand the description of this action.

File doxygen.cpp

Take a look at MsmSlice::baseCase for the case where the ideal is not simplified. Some of the base cases for the simplified case should apply as well for the non-simplified case, or at least it should be possible to modify them to apply.

Grep for TODO in upper case and add everything found by that as Doxygen todo's.

See if this idea works: If m is a minimal generator of I, and m has maximal exponent in some var, and has the unique minimum exponent in some other var, than we can do an inner split on that other var.

Add examples sections to library interface documentation. I believe there is a command for this in Doxygen. Especially specify what happens with the zero ideal, the whole ring ideal and when there are no variables.

Make a Slice Algorithm Module. Look into this set of classes and remove any smeels. Then document those classes that need it.

Add a gradedHilbertPoincareSeries function to library interface which dots each multigraded piece with some given vector, rather than (1,...,1) as for univariateHilbertPointcareSeries.

Go through the documentation in frobby.h and properly Doxify it and use LaTeX. Explain the mathematical background a bit, including definitions of each operation.

Do something to automatically get a Doxygen module of all things not in a Doxygen module. This is a good way to capture those things falling through the cracks by forgetting an ingroup directive. Perhaps do this as for the idea with a namespace above, but instead start a weakgroup in stdinc.h and end it in the bottom include.

Add all Frobby code to a FrobbyImpl namespace or some such. Perhaps do it by starting the namespace in stdinc.h, and then adding an include to the bottom of every .cpp file that closes the namespace.

Module Facade

Document each facade.

Class Facade

Replace this with ActionPrinter using aggregation instead of inheritance.

Member Frobby::alexanderDual (const Ideal &ideal, const mpz_t *reflectionMonomial, IdealConsumer &consumer)

don't use exceptions to propagate false internally.

Member Frobby::alexanderDual (const Ideal &ideal, const Ideal &reflectionMonomial, IdealConsumer &consumer)

doc.

Member Frobby::irreducibleDecompositionAsMonomials (const Ideal &ideal, IdealConsumer &consumer)

This can be improved to have no special cases, since the zero ideal does correpond to the identity, since the product of the zero ideal's generators is the empty product, which is the identity. At the same time we don't need the identity otherwise, since the whole ring is always redundant as an intersectand.

Member generateRandomFrobeniusInstance (vector< mpz_class > &degrees, size_t entryCount, const mpz_class &maxEntry)

: preserve state across calls.

Member Ideal::getSupportCounts (Exponent *counts) const

Make counts a vector<size_t>.

Member IdealFacade::printAnalysis (FILE *out, BigIdeal &ideal)

: describe.

Member IdealFacade::printLcm (BigIdeal &ideal, IOHandler *handler, FILE *out)

: describe.

Class IdealTree

: avoid unbounded recursion.

Class IntersectFacade

Merge this into IdealFacade.

Module IO

Take a look at the IO module, change it if it needs it, and then document it.

Add the IO classes to the IO module.

Describe the IO module.

Class IrreducibleIdealDecoder

: This seems redundant with IdealSplitter.

Class MsmSlice

expand and check comments.

Class Parameter

: rename to CliParam

File randomDataGenerators.h

Fix the name of the file, since not everything here is random, and consider the structure of the code. E.g. does generating Frobenius instances belong with the code generating monomial ideals? Should these methods be free functions? Should there be a facade which does nearly nothing but to call these functions? Should this be the place where the description of these ideals is presented? Shouldn't these be returning their output using a consumer? Shouldn't there be a clear mapping between these ideals' names as strings and the function creating them, rather than just having a static list in the Action that creates these?

Member rowReduceFully (Matrix &mat)

: do back substitution instead.

Member Slice::applyLowerBound ()

Rename lower bound to divisor.

Member Slice::getLowerBound (Term &bound, size_t var) const =0

rename lower bound to divisor.

describe how the real functionality is slightly more sophisticated.

Member Slice::simplifyStep ()=0

Is this method actually used, and does it return true iff this object changed?

Member SliceFacade::computeAssociatedPrimes ()

Add a bool encode option to choose between output as actual ideals or as it is being done now.

Member SliceFacade::computeDimension (mpz_class &dimension)

Nope, it is the Krull dimension. although that may be the same. Fix this doc.

why are there two dimension methods?

Member SliceFacade::computeIrreducibleDecomposition (bool encode)

Check whether encode being false is really only supported for writing to a file. If so, fix it and update this documention.

Class SliceStrategy

Inspect comments.

Class Term

Move the inline code out of the class declaration and add them as inline below the class declaration.

Duplicate the comments for overloads using the copydoc Doxygen command.

Rename term.h to Term.h.

Class TermConsumer

: consider merging this with BigTermConsumer;

Member TermTranslator::setInfinityPowersToZero (Ideal &ideal) const

Figure out what is going on with the continue in this method.

Class VarNames

make equality check for the same memory and thus return true very quickly if that is the case.

make copies share the same memory and use reference counting to deallocate the shared memory.

make this class immutable and make a VarNamesBuilder.

Rename to Ring or a similar name.

Member VarNames::addVarSyntaxCheckUnique (const Scanner &in, const string &name)

Move this somewhere more appropriate.