Page 1 sur 1
alg lin et flottants
Publié : ven. sept. 19, 2008 12:16 pm
par frederic han
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.
Publié : ven. sept. 19, 2008 6:07 pm
par parisse
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!
Publié : lun. sept. 22, 2008 10:40 am
par frederic han
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
Publié : lun. sept. 22, 2008 10:53 am
par frederic han
encore un truc du meme genre:
rand(-1.0,1.0) reste en 12 chiffres quelque soit digits
Publié : lun. sept. 22, 2008 11:07 am
par parisse
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)?
Publié : lun. sept. 22, 2008 7:16 pm
par frederic han
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.
Publié : lun. sept. 22, 2008 7:35 pm
par parisse
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...
Publié : mar. sept. 23, 2008 1:59 pm
par parisse
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).
Publié : mer. sept. 24, 2008 12:21 pm
par frederic han
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
Publié : mer. sept. 24, 2008 12:37 pm
par parisse
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]]).