alg lin et flottants

frederic han · Message par **frederic han** » ven. sept. 19, 2008 12:16 pm

J'ai des problemes en mode plus de 15 chiffres:
A:=matrix([[2.0^1024]])
me donne bien
[[0.1797693134862316e309]] (a condition d'avoir un digits d'au moins 15)

mais det(A) plante
et A^(-1) passe en 12 chiffres,
[[5.562684646268e-309]]
du coup
A*A^(-1) est infini.

Message par **parisse** » ven. sept. 19, 2008 6:07 pm

en effet, un effet de bord des contextes indépendants dont inv ne tenait pas compte, j'espère que ce sera corrigé lundi.
merci!

frederic han · Message par **frederic han** » lun. sept. 22, 2008 10:40 am

je viens de tester la version du 22/9 9h
c'est mieux, mais il reste encore:

A:=matrix([[2.0^1024]])

En 15 chiffres:
1/A et A^(-1) passent encore en 12 chiffres alors que inv(A) et A^(-1.0) restent bien en 15 chiffres

En 12 chiffres:
1/A fait bien [[0.0]]
det(A) fait bien undef

mais A^(-1.0) tourne fou.

voila
Fred

frederic han · Message par **frederic han** » lun. sept. 22, 2008 10:53 am

encore un truc du meme genre:

rand(-1.0,1.0) reste en 12 chiffres quelque soit digits

Message par **parisse** » lun. sept. 22, 2008 11:07 am

Oui, rand renvoie un double, si tu veux avoir un flottant multi-precision, il faut que tu fasses 2 conversions exact puis evalf
evalf(exact(rand(-1.0,1.0)),30)
En fait, rand utilise la fonction C rand() et divise par la longueur de l'intervalle.
Je pourrais faire un rand qui tienne compte du nombre de digits, mais est-ce que la conversion en flottant multiprecision suffit ou est-ce qu'on s'attend a avoir plus de reponses possibles par rand (i.e. plusieurs appels a la fonction C rand() le nombre etant propotionnel au nombre de digits)?

frederic han · Message par **frederic han** » lun. sept. 22, 2008 7:16 pm

Il me semble qu'on attend un tirage uniforme sur l'intervalle a la precision par defaut, donc ca risque d'etre plus couteux, mais ca me semble delicat que des fonctions non entieres ne tiennent pas compte du Digits non?
A la limite ca serait moins source d'erreur que rand ne retourne que des entiers.

Message par **parisse** » lun. sept. 22, 2008 7:35 pm

Pour l'instant, le rand(approx..approx) etait surtout utilisé pour faire un peu de simulation en lycée, et je ne me suis pas vraiment inquiété de la précision! Ce que je voulais surtout dire, c'est qu'avec les tirages aléatoires basés sur un tirage de la fonction C unsigned rand(), la multiprécision n'avait pas beaucoup de sens. Si on veut de la multiprécision, je suis d'accord qu'il faut plusieurs tirages... je vais d'abord regarder s'il n'y a pas de fonction de GMP ou mieux MPFR qui font ça...

Message par **parisse** » mar. sept. 23, 2008 1:59 pm

Je viens de mettre a jour xcas linux, avec rand qui s'adapte a la precision. Plus precisement, si les arguments sont des doubles, rand est inchange (l'ecart relatif entre 2 aleatoires generes est donc de 2^(-31) sur une machine 32 bits), par contre pour des arguments flottants multi-precision, la granularite depend de la valeur des flottants multi-precision (plusieurs appels a unsigned rand() sont donc faits).

frederic han · Message par **frederic han** » mer. sept. 24, 2008 12:21 pm

OK, ca marche pour rand
avait tu vu mon post sur 1/A et A^(-1) en 15 chiffres (inv(A) et A^(-1.0) marchent en 15)
et A^(-1.0) en 12 chiffres me donne undef alors que A^(-1) et les autres donnent 0

Message par **parisse** » mer. sept. 24, 2008 12:37 pm

Oui, la raison c'est que pour les puissances non entieres il y a automatiquement conversion en exp/ln. Pas de problemes pour ln en numerique, par contre l'exp (en utilisant le dvpt en series) bouclait car A^n/n! n'etait jamais plus petit que epsilon. J'ai rajoute un nombre maxi d'iteration, ca ne boucle plus, mais le resultat n'a aucune raison d'etre utilisable (heureusement on peut s'en douter vu que ca repond [[undef]]).