gros calculs

[frederic han]

Bonjour j'ai une question,
lorsque l'on fait un normal(F) et que les ressources augmentent beaucoup. (>1.5G dans top)
Est ce que giac finit par interompre le calcul et retourne un resultat inacheve (en general trop gros pour etre affiche)?

Si oui, fait il cela sans warning ou message d'erreur?

merci

Fred

[parisse]

non, il n'y a pas de test des ressources utilisees, il y a donc de bonnes chances que le process soit tue par le noyau de l'OS.

[frederic han]

Merci pour la reponse,

mais du coup je suis un peu perdu avec normal. Je m'attendais a trouver 0 et j'obtient un resultat trop gros pour etre affiche.

Du coup j'ai essayer de specialiser avant le normal et apres et dans un cas ca fait 0 mais pas dans l'autre, il doit donc y avoir un Pb: (0.9.9 .deb amd64)

je mets la session ici:

http://people.math.jussieu.fr/~han/pbnormal.xws


NB: pour le forum, le lien sur ta page
http://www-fourier.ujf-grenoble.fr/~parisse/giac.html
est encore en pcm1.

Merci et

a+

Fred

[parisse]

salut,
j'ai corrige pour le lien, merci, je regarderai le pb la semaine prochaine, je te tiens au courant!

[parisse]

Le mystere s'epaissit, quand je lance les memes calculs avec icas au lieu de xcas, j'obtiens bien 0 pour rela2:=normal(rela)

[parisse]

Bon, je crois que j'ai un peu avance, si tu mets le parametre de la config du cas threads a 1, ca a l'air de marcher, il doit y avoir une erreur dans l'execution d'une multiplication ou d'un PGCD en parallele. Ca va pas etre simple de trouver ou...

[parisse]

ca devrait fonctionner maintenant, j'ai mis a jour le source et les binaires.

[frederic han]

Merci d'avoir regarde.

J'ai essaye le .deb amd64 testing.

Je ne vois pas trop de differences sous xcas. en thread 1 rela2 est bien nul mais pas en thread 2.

Je trouve aussi d'autres incoherences meme en thread 1.
Ex:
Je specialise le det avant son calcul:

q02:=det_minor(unapply(Q(w0,w2),u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test))
q01:=det_minor(unapply(Q(w0,w1),u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test))
q12:=det_minor(unapply(Q(w1,w2),u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test))

alors:
normal(unapply(Q02,u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test)-q02)
normal(unapply(Q12,u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test)-q12)
ne sont pas nul.
En revanche:
normal(unapply(Q01,u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test)-q01)
l'est bien.

D'autre part, avec la somme specialisee je trouve bien:
normal(unapply(RRR01*q01+RRR02*q02+RRR12*q12,u_10,u_20,u_30,v_10,v_20,v_30,u_11,u_21,u_31,v_11,v_21,v_31)(test)))

qui est nul donc les RRRij ont l'air corrects.


Voila ou j'en suis.
Bon courage
Fred

[parisse]

oui, il reste encore un probleme, et le pire c'est que j'ai des resultats erratiques (ca peut meme donner 0).
Bon en attendant tu peux toujours faire threads:=1 ou heap_mult(200000); pour bloquer la multiplication en parallele avec tas, je pense que je vais desactiver cet algo en parallele le temps que je trouve.

[parisse]

Bon, j'ai corrige un autre bug, cette fois-ci j'espere que c'est la bonne!

[frederic han]

Salut,
cette fois je vois bien une amelioration j'ai la meme chose en mode thread 1 ou 2.
Par exemple le calcul de rela2 devient correct en thread 2.

Cependant il reste un probleme meme en thread 1 que l'on voit dans det_minor.
Q02 n'a pas l'air correct en tout cas je trouve une difference entre avant et apres la specialisation.

J'ai essaye de specialiser moins de variables pour voir la limite ou l'erreur apparait:

test2:=op(randvector(3))
qq02:=det_minor(unapply(Q(w0,w2),v_10,v_20,u_31)(test2));
qq01:=det_minor(unapply(Q(w0,w1),v_10,v_20,u_31)(test2));
qq12:=det_minor(unapply(Q(w1,w2),v_10,v_20,u_31)(test2));
les 3 ci dessus m'ont l'air OK car
normal(unapply(RRR01*qq01+RRR02*qq02+RRR12*qq12,v_10,v_20,u_31)(test2))
donne bien 0.

En revanche, la specialisation suivante n'a plus l'air correcte meme en thread 1.

qq02:=det_minor(unapply(Q(w0,w2),v_10,u_20,u_31)(test2));
qq01:=det_minor(unapply(Q(w0,w1),v_10,u_20,u_31)(test2));
qq12:=det_minor(unapply(Q(w1,w2),v_10,u_20,u_31)(test2));
normal(unapply(RRR01*qq01+RRR02*qq02+RRR12*qq12,v_10,v_20,u_31)(test2))

voila ou j'en suis.
a+
Fred

[parisse]

il faut une bete de course pour faire tes calculs! Je ne peux pas essayer ici, sauf avec Q01 qui a l'air de se comporter normalement, car ca prend trop de temps, peut-etre la semaine prochaine avec une machine plus puissante... d'une manière ou d'une autre il va falloir arriver à isoler le bug sur des cas plus petits.

[parisse]

Autre suggestion pour isoler le bug: faire
heap_mult(10^9)
avant les calculs de det, pour forcer à ne pas utiliser la multiplication par tas et tester si la specialisation avant et apres chaque determinant donne la même chose (avec un normal de la différence).

[frederic han]

Salut,
oui c'est une relation que j'ai trouvee grace a xcas, et je ne pense pas qu'il y ait beaucoup de logiciels capables de la verifier!

Bon la plus petite erreur que je trouve est en specialisant v_10,u_20,u_31.
heap_mult(10^9);
test3:=op(randvector(3));
qq02:=det_minor(unapply(Q(w0,w2),v_10,u_20,u_31)(test3));
qqq02:=det_minor(unapply(Q(w0,w2),v_10,u_20,u_31,u_30)(test3,12345));
alors:
normal(unapply(qq02,u_30)(12345)-qqq02)
n'est pas nul,

Fred

[parisse]

j'ai réussi à bien simplifier, la matrice suivante pose problème

Code : Tout sélectionner

M:=[[0,0,0,0,0,0,0,v_2,v_3],[0,0,0,0,0,u_30,v_10,v_20,(u_30)/(v_20*v_10)],[0,0,0,0,0,0,((u_30)*v_11^3-u_11*u_21*u_31*v_10^3)/(v_11*v_10),1,(u_30^2*v_11^3*v_21^3+u_11^2*u_21^2*u_31^2*v_10^3*v_20^3)/(v_21^2*v_20^2*v_11^2*v_10^2)],[0,0,0,((-u_30*v_11^2*v_21^2+u_11^2*u_21*u_31*v_10^2*v_20^2)),0,0,0,0,0],[0,0,0,0,(((-u_21)*u_30*v_10*v_11*v_21^2+(-u_21)*u_30*v_11^2*v_20*v_21+u_11*u_21^2*u_31*v_10^2*v_20^2)),0,0,0,0],[u_3,0,0,0,0,(u_30*(-(u_30^2)*v_11^2*v_21^2+u_11*u_21*u_31^2*v_10^2*v_20^2)),0,0,0],[0,v_10,0,0,0,0,1,0,0],[v_2,0,((u_30)*v_21^3-u_11*u_21*u_31*v_20^3),0,0,0,0,1,0],[v_3,0,(u_30^2*v_11^3*v_21^3+u_11^2*u_21^2*u_31^2*v_10^3*v_20^3)/(v_21^2*v_20^2*v_11^2*v_10^2),0,0,0,0,0,0]];

C'est suffisamment rapide pour pouvoir espérer debugguer