gros calculs

[parisse]

bon, il semble que le coupable est la fonction foisplus de gausspol.cc, si on met ligne 5747 #if 0 au lieu de #ifndef RTOS_THREADX, ca corrige un bug. Mais je ne comprend pas pourquoi, au moins pour le moment...

[parisse]

bon, j'ai trouvé, c'était deux erreurs tout bête:

Code : Tout sélectionner

diff gausspol.cc gausspol.cc~
5749c5749
<     double ans=1;
---
>     ulonglong ans=0;
5782,5783c5781
<       convert<gen,ulonglong>(pb,de,res->t);
---
>       convert<gen,ulonglong>(p,de,res->t);

[frederic han]

Superbe!

Ce coup ci on obtient meme la grosse relation
(en moins de 10s avec un linux amd64 sur: Intel(R) Core(TM) i5-2435M CPU @ 2.40GHz,
et moins de 7s pour les gros determinants Q02 et Q12)


voici un resume:

/* le cas generique */
w1:=[u_11,u_21,u_31,v_11,v_21,v_31] ;
w0:=[u_10,u_20,u_30,v_10,v_20,v_30] ;
Q:= (x,y)->{ [[0,0,0,u_1,u_2,u_3,v_1,v_2,v_3],[0,0,0,x[0],x[1],x[2],x[3],x[4],x[5]],[0,0,0,y[0],y[1],y[2],y[3],y[4],y[5]],[u_1,x[0],y[0],x[0]*y[0],0,0,0,0,0],[u_2,x[1],y[1],0,x[1]*y[1],0,0,0,0],[u_3,x[2],y[2],0,0,x[2]*y[2],0,0,0],[v_1,x[3],y[3],0,0,0,(-(x[3]))*y[3],0,0],[v_2,x[4],y[4],0,0,0,0,(-(x[4]))*y[4],0],[v_3,x[5],y[5],0,0,0,0,0,(-(x[5]))*y[5]]];} ;
S:= (W)->W[0]*W[1]*W[2]-W[3]*W[4]*W[5] ;
/* On exprime que les points w0 et w1 de P5 sont sur l'hyp S */
v_30:=u_10*u_20*u_30/(v_10*v_20) ;
v_31:=u_11*u_21*u_31/(v_11*v_21) ;
tmp:=normal((S(w0+b*w1))/b) ;
a0:=coeff(tmp,b,1) ;
a1:=-coeff(tmp,b,0) ;
normal(S(normal(a0*w0+a1*w1))) ;
w2:=normal(a0*w0+a1*w1) ;
/* verification que le point w2 est bien sur le diviseur cubique */
normal(S(w2)) ; //doit faire 0
/* Attention, il faut utiliser les matrices creuses pour le calcul des 3 determinant */
Q01:=det_minor(Q(w0,w1)) :;
Q02:=det_minor(Q(w0,w2)) :;
Q12:=det_minor(Q(w1,w2)) :;
RRR02:=u_11*u_21*u_31*a0^2 :;
RRR02:=normal(RRR02) :;
RRR12:=u_10*u_20*u_30*a1^2 :;
RRR12:=normal(RRR12) :;
RRR01:=w2[0]*w2[1]*w2[2]*(a0*a1)^2 :;
RRR01:=normal(RRR01) :;
/* Verification de la relation entre les 3 quadriques */
bigrela:=normal(RRR01*Q01+RRR02*Q02+RRR12*Q12); // doit faire 0

[parisse]

J'ai mis a jour les packages deb et les versions 32 bits win et mac. J'obtiens sur un AMD 2.8GHz (virtualise) des temps tres proches des tiens (a 10% pres).

[frederic han]

Je n'ai pas reussi a calculer ces determinants avec macaulay2 ni avec sage. J'ai peut etre manqué la bonne instruction.
en tout cas, sous macaulay2
Q02=det(M02,Strategy=>Cofactor);
m'a semble trop long. (alors que pour M01 la strategie Cofactor etait bien plus rapide que sans strategie)
J'ai tente d'utiliser des sparses sous sage mais je n'ai pas vu d'amelioration pour le determinant.

Bref le seul autre logiciel avec qui j'ai pu comparer completement ce calcul est maple15

sur une linux amd64.

giac099 (paquet .deb) faisait les 3 determinants Qij en 14.44s et la relation en 8.57s
maple15 version 64bits faisait les 3 determinants Qij en 2.3s et la relation en 6.65s

C'est donc tres bien et je ne sais pas faire cet exemple avec un autre logiciel libre.

Merci

Fred

[parisse]

Donc il y a encore de la marge de progression sur les determinants (ce qui ne m'etonne pas trop, peut-etre que la fonction foisplus devrait faire plus de tests de type ou etre neutralisee).

[parisse]

Et en effet, on peut calculer les determinants en un peu plus de 1 seconde en supprimant les denominateurs avant de calculer le det. Je suis en train de mettre a jour giac instable en consequence.
Pour le normal final, ca ne change rien et ca reste donc plus lent que maple, probablement a cause de la representation interne, au-dela de 7 variables, il y a allocation memoire pour chaque monome, et comme tu as une dizaine de variables... On pourrait changer le reglage et passer a 11 variables en allocation directe en changeant HAS_POLY_VARS_OTHER de 1 a 2, ca accelererait la, mais ca ralentirait pour tous les problemes ou il y a peu de variables.

[frederic han]

Salut, le det minor est bien ameliore.

cette fois:

(cf les fichiers http://people.math.jussieu.fr/~han/rech ... s-laurent/ )

giac099 (paquet .deb) faisait les 3 determinants Qij en 2.56s et la relation en 8.58s
maple15 version 64bits faisait les 3 determinants Qij en 2.35s et la relation en 6.65s

mais je n'ai pas fait de tests avec des denominateurs compliques pour voir si ca faisait perdre du temps a giac par rapport a l'ancienne version.

NB: le source 0.9.9 du 27/9 donne un Pb de compilation:
vecteur.cc: In function ‘void giac::smallmodrref(std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > >&, giac::vecteur&, std::vector<int, std::allocator<int> >&, std::vector<int, std::allocator<int> >&, longlong&, int, int, int, int, int, int, int, int, bool)’:
vecteur.cc:4758: error: ambiguous overload for ‘operator*’ in ‘giac::max(const giac::gen&, const giac::gen&, const giac::context*)(((const giac::gen&)(& giac::gen((cmax - c)))), giac::context0) * (double)modulo’
gen.h:791: note: candidates are: giac::gen giac::operator*(const giac::gen&, const giac::gen&)
modpoly.h:105: note: giac::modpoly giac::operator*(const giac::gen&, const giac::modpoly&)
make[1]: *** [vecteur.lo] Erreur 1

[parisse]

oui, il faut mettre giacmax maintenant.
Je suis en train de regarder avec 11 variables en adressage direct, mais ca buggue!

[parisse]

j'ai corrige le bug de l'adressage direct en 11 variables (dans index.h il manquait un ++source à un endroit), mais ca ne gagne presque rien (10.4s au lieu de 10.8s sur le normal final chez moi), ca ne vaut pas le coup, de toutes façons l'écart avec maple est tout-à-fait raisonnable:-)