To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Heritage persistent IDentifiers (SWHIDs) must be used instead of copying and pasting the url from the address bar of the browser (as there is no guarantee the current URI scheme will remain the same over time).
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
LUdivine-PLUQ * Clean up of all base cases * Only one routine, and automated switch to all implementations FTRTRI/FTRTRM * Optimize base cases Conversion double -> float for small moduli: * should be done in each routine, not only gemm Simplification of helpers: * currently all mmhelpers have Amax,Amin,Bmax,Bmin, Cmax,Cmin,Outmax, Outmin, and all related features for delayed reductions. * this is not suited for other FieldTraits (say Generic, Multiprec,...) TODO: - write a by-default minimal mmhelper - specialize the mmhelper with delayedModular trait with all the machinery * The NeedPreaddreduction system is error-prone and ugly: ==> introduce AddHelpers - carry max min outmax outmin info when used with a DelayedModular FieldTraits - decide when a mod is required in this case - empty otherwise. - Two bool params: add/sub switch, and inplace switch. CharPoly: How to handle polynomial arithmetic * Option 1: generic representation, fixed Poly1Dom domain type, built when needed - store polynomials as template type Polynomial which is assumed to provide basic std::vector<Element> methods; - build a Poly1Dom when arithmetic needs to be done - convert Polynomials back and forth to a givvector -> no genericity wrt Polynomial representation and domain * Option 2: generic domain type, generic representation, built when needed - pass the type PolRing as template argument (unused in the signature) - requires to explicitly specify the template arg list -> incompatible with the solution trait system (generates partial template specializations) * Option 3: generic domain type, generic representation, built only once - pass the PolRing object along all functions that ultimately need it -> heavy impact on sage & LinBox functions API (ex LinBox::charpoly(PolDom, P, A), FFPACK::CharPoly(PolDom, N, P, A, lda)) * Option 4: let polynomials know their domain - add a reference to the PolDom in the Polynomial object (class Poly inherit from givvector and adds a ) * Option 5: Option 3 for FFPACK and 4 for LinBox - FFPACK: use the usual polynomail/PolRing interface defined in Givaro (Polynomials do not know their domains) - LinBox: wrap Givaro Polynomials and PolRing such that a Polynomial knows its Domain -> allow charpoly (P,A)