We are hiring ! See our job offers.
https://hal.archives-ouvertes.fr/hal-02128878
Raw File
Tip revision: 4201397494d9af8b687117e8ff4d85a8944f5c5a authored by Software Heritage on 11 June 2019, 10:15:02 UTC
hal: Deposit 298 in collection hal
Tip revision: 4201397
TODO
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)
back to top