[ODK] Meeting 2019 05 17

ODK Linbox meeting 2019-05-17 CR

on laisse tomber l'idée de l'héritage de LiftingCOntainerBase
- pb: nextdigit attend un Ivector residue. ON aurait pu le résoudre en faisant: -> dans le cas RNSDixon: Ivector = matrix -> dans Base: templater la classe par Ivector = BlasVector par défaut et faire IVector=BlasMatrix dans MultiModliftingContainer
- la reconstruction devrait alors se faire modulo le produit des pi pour construire
- la division par p doit se faire par p1x..xpl donc on perd les optim ===>>>> ne pas hériter
Dixon RNS (cf https://cs.uwaterloo.ca/~astorjoh/p92-chen.pdf) -> decision de faire l=1 (1 seul modulo p de storjohann) de 23 et une base RNSq de nombres premiers > à p
- option: faire tout le calcul dans la base RNSq avec l'astuce de la reduc mod p dans la base (cf Giorgi&Al.)
fix sur getpointer
Dixon refacto:
toujours ready for review
LinBox error debug contracts: PR en WIP -> laisser ENSURE REQUIRE (possiblement implémentés par des asserts)

API utilisateur:

On veut accélerer 2 et 3.

paralleliser les codes rns au niveau CRT pour fgemv<ZZ>: s'appuyer sur l'existant:
- compose helpers et RNSModular dans fflas_fgemm/fgemm_classical_mp.inl -> à adapter dans fflas_fgemv_mp.inl:

dans le benchmark ajouter une

option 4 pour un Parallel<RNSModulus, grain> H(Grain)
option 5 pour un Parallel<RNSModulus, Threads> H(t)
option 6 pour Compose<Parallel<Row, Threads, Parallel<RNSModulus, grain> >
option 7 pour Compose<Parallel<Parallel<RNSModulus, Threads>, Parallel<Row,grain >
regarder où on passe selon les appels
fixer si besoin le code pour que les routines passent bien le bon nombre de threads au appels internes
mettre les données en tableau (1 tableau par valeur fixée de n et bitsize)

2e tache

dans la branche sage: exposer les pDet pSolve, pEchelon, pRank, etc et enlever le patch. Merge la branch #26932 en cours de révision pour l'intégration des releases.