Discussion :

[méphistopheles]

Bonjour.

Je programme en vb.
il se trouve, que j'aurais besoins d'un calcul du cosinus d'un nombre avec une centaines de décimales exactes.
or la fonction vb n'en renvoie que 15
j'ai donc naturellement pensé à faire une procédure récursive de calcul du cos.
malheureusement, le plus gros type vb ne renvoie que 15 décimales.
du coup, j'ai pensé à segmenter mes calculs en tranches de 15 décimales.
mais ce n'est pas utilisable dans une procédure récursive.
il me faudrais donc une version linéaire du calcul de la fonction cosinus.

ma fonction en vb est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
private function cosnum (n as double, dec as integer) as double 
do while n<=0 
  n=n+4*atn(1) 
loop 
if n<= 10^(-dec) then cosnum=n else cosnum=2(cosnum(n/2,dec))^2 -1 
end function

soit une fonction nomée cosnum avec comme parametre n ou n est le nombre d'appel et dec qui est le nombre de décimales demandées.

do while n<=0
n=n+4*atn(1)
loop
me permet de remettre le cosinus dans son équivalent positif s'il est négatif. (atn= arc tangente)

la condition est : si n inférieur à 10 ^-dec, alors cosnum renvoie n. sinon, cosnum renvoie 2*(cosnum(n/2,dec))² -1
ou cosnum(n/2,dec) réappele la fonction cosnum avec n/2 en paramettre et en rappellant le nombre de décimales demandées.

si vous connaissez la vertion litéralleoù si vous avez une idée...
merci

nota: une version de ce sujet existe déja sur le forum vb :http://www.developpez.net/forums/vie...er=asc&start=0

[afrikha]

il me faudrais donc une version linéaire du calcul de la fonction cosinus.

regarde du coté du developpement limité

[Le Furet]

cos(x)=1 - x^2/2! + x^4/4! - x^6/6! + ...

Le dénominateur en (2k)! assure une convergence rapide (mais commence quand même par ramener x dans [0;pi/2].

Néanmoins, il me semble que ce n'est pas comme ça qu'on procède dans les implémentations sur calculatrice.

Voir : http://www.trigofacile.com/maths/trigo/calcul/cordic/cordic.htm

Par contre, je ne suis pas certain que calculer pi par 4*atn(1) soit une bonne idée : c'est lent (tandis que pi est une constante dont il est très facile d'avoir plein de décimales. Par exemple, de tête, pi ~ 3.14159265358979323846264) et tu n'as pas la même précision que celle demandée par ton calcul, c'est étrange...

[méphistopheles]

en fait, Visual basic n'est pas une methode de calculette mais bien de pc.

la constante pi n'est pas une constante définie en vb. l'arc tangente est la methode la plus courte pour la détermienr. il et évident que pour le degré de précision que je demande, je ne peux pas me permettre un pi aproché comme cela mais pour l'instant, je cherche la fonction cosinus. avoir plus de décimales de pi n'est pas un problème.

merci pour la suite, je vais l'essayer.

->africa heu, je veux bien mais pour me taper les dérivation, je vais m'amuser tiens...



salut

[Le Furet]

Ce que je veux dire, c'est que si c'est implémenté comme ça sur une calculatrice, c'est qu'il y a des raisons. Et il est très (très) vraisemblable que Visual Basic l'implémente comme ça aussi (ou éventuellement avec des approximants de Padé, qui en général convergent plus vite que les développements en Série entière).

Quant à Pi=Atn(1), je vois mal comment VB, qui d'après ce que tu dis ne renvoie que 15 décimales pour la fonction cosinus, en renverrait davantage pour la fonction Arc Tangente. Du coup, tu n'as plus qu'une précision de 15 chiffres sur l'argument de ton cosinus, et il est complètement illusoire d'espérer calculer un cosinus précis avec plusieurs centaines de chiffres. En plus de ça, c'est pas terrible de recalculer atn(1) à chaque appel de fonction cosinus.

Le Pi que je te donne a déjà plus de décimales justes que celui de VB, mais si tu en veux davantage, va là : http://ns3131.ovh.net/~pi314/decimales.html

Je ne vois pas non plus ce que viennent faire les dérivations dans le message d'Afrikha. Il te parle juste de la formule que j'ai mise en haut de mon premier post, qui est le Développement en Série Entière (et non le développement Limité, même si ça y ressemble) de la fonction cosinus.

[Edit : tu as peut-être cru que je dénigrais VB avec mon histoire de calculatrice ? Ce n'était pas le cas, je n'ai rien contre ce langage.]

[j.p.mignot]

en ce qui concerne les dérivées je pense qu'il a voulu parler du développement de Taylor
f(x) = somme 0..infin f(n)(0) / n! sans remarquer que pour cos f(2n+1)(0)=0 et f(2n)(0) = (-1)^n

En ce qui concerne les développements en série entière on peut converger plus vite en limitant non pas à 0..Pi/2 mais 0..Pi/4 ( < 1 => x^n->0) et utiliser suivant le cas cos ou sin.

En ce qui concerne la résolution de cos(x), si le codage dans un langage donné ne permet pas de "digitaliser" les float au-dessous d'une certaine précision, il ne sera pas possible de donner un résultat avec la précision requise. Il faut alors créer son propre cryptage sur plus de bit pour pouvoir effectivement conserver la "finesse" de x^(2n)/(2n)! si non on a de zéros ou des valeurs sans signification.

Cela n'est pas forcement un mince problème.

[xxiemeciel]

Salut,

Pour calculer un cosinus en informatique il me semble qu'il faut decomposer en serie entiere, pour un cosinus c simple, tu utilises les formules d'Euler pour decomposer ton cosinus en exponentiel et ensuite tu decompose tes exponentiel en serie entiere

Les formules sont presentes dans l'article de meta programmation de developpez.com

http://loulou.developpez.com/tutoriels/cpp/metaprog/

avec les formules c tres simple a programmer

XXiemeciel

[mathieu_t]

pour un cosinus c simple, tu utilises les formules d'Euler pour decomposer ton cosinus en exponentiel et ensuite tu decompose tes exponentiel en serie entiere

Ou bien tu utilises la formule de Taylor (ce qui est pareil mais en plus rapide car on arrive à la formule direct, le développement de l'exponentielle étant issu aussi du développement de Taylor)... Et comme l'a dit j.p.mignot, il faut quand même règler la finesse en règlant un n...

[j.p.mignot]

régler n c'est théoriquement très facile car il s'agit d'une série alternée dont il est très facile de majorer le reste. Par conséquence vouloir une précision de 10^-m permet de fixer à coup sur le nombre n ( fonction de x ) de la somme partielle. Le problème n'est pas là! si la valeur de n vaut par exemple 200 il faut encore être capble de coder ( 2*200)! < et les précedents> , leurs inverses, x^(2*200) < et les précedents> en faire des multilications et additions avec une precision suffisante pour garantir que la somme partielle ait toujours le nombre requis de chiffres significatifs.

A mon avi le codage des infiniments petits / infiniments grands qui sont sous-entendus dans la question d'origine pourrait faire l'objet d'un débat fort intéressant (et fort utile dans certaines occurences )!

[random]

quand on a besoin d'allier grande précision et taille de nombre très différente si les besoins sont ponctuels on peut assez facilement
se créer une librairie adaptée
par contre si on travaille toujours dans ce type d'univers il existait un
logiciel assez bien fait qui permettait de travailler avec une précision de 1500 chiffres en restant relativement performant il s'agit d'ubasic

ps après recherche la dernière verson est rendue à 2800 chiffres

[Jean-Marc.Bourguet]

Je ne connais pas les basic actuels... mes derniers contacts avec les langages de cette famille date d'il y a 15 ans environ. Mais j'ai quand même des doutes sur l'intérêt d'utiliser un langage interprété quand on veut calculer avec une centaine de décimales.

La première question à se poser, c'est de la représentation des données. Est-ce que tu veux faire de la virgule flottante, ou de la virgule fixe? De toute façon, la technique consiste à représenter le nombre dans une grande base choisie de sorte que tu puisses facilement faire des calculs exacts sur les nombres entiers inférieurs à cette base (2^15 ou 2^16 a une densité plus grande, 10000 permet de convertir facilement en décimal). Si je ne me trompe pas, tu vas simplement devoir implémenter l'addition, la soustraction et la multiplication sur les nombres représenté dans cette base, tu ne devras faire de divisions qu'avec un entier relativement petits, inférieur à ta base.

Ensuite tu réduis ton argument entre 0 et PI/2.

CORDIC est une technique. Il y a moyen de l'appliquer sur des nombres décimaux. Il te faut une table de tangeante (ou d'arc tangeante, je ne sais plus) pour une série d'angles déterminés mais elle est relativement facile à batir (une 50aine d'angles pour la version décimale pour avoir 100 chiffres significatifs). C'est l'approche que je prendrais. Tu n'as même pas besoin de la multiplication complète, tu auras ici simplement à multiplier par des entiers inférieur à 10. En calcul nécessaire, il te faudra environ 100 multiplication par un entier inférieur à 10 et 100 additions.

Le développement en série autour de 0 est une autre technique possible. Vraissemblablement plus couteuse en calcul. 70! c'est environ 10^100, donc il te faudra au minimum 35 termes puisque tu va devoir traiter des nombres plus grand que 1, chaque terme nécessitant une multiplication de 100 chiffres par 100 chiffres, une division par un entier inférieur à ta base et une addition de 100 chiffres. Soit a peut près le cout du calcul par CORDIC par terme.

L'utilisation de ta formule de cos de l'angle moitié pose un problème (après la correction nécessaire due au fait que le cos d'un angle petit, c'est 1): il te faudrait calculer les termes intermédiaires avec beaucoup plus de chiffres significatifs que le résultat final.

[random]

les basics n'ont pas la côte mais à ma connaissance ubasic est le seul
langage créé essentiellement pour manipuler de grands nombres
il est très rudimentaire et l'interface dont je me souviens ferait sourire
par contre tester si un nombre de 1500 chiffres était premier se faisait
sans autre programmation que l'utilisation des fonctions fournies et sans avoir à créer des classes et bibliothèques spécialisées qui resteraient à optimiser

[Jean-Marc.Bourguet]

les basics n'ont pas la côte mais à ma connaissance ubasic est le seul
langage créé essentiellement pour manipuler de grands nombres

Les langages ayant des entiers non limites sont quand meme nombreux. Sans chercher mathematica, matlab, python, pas mal de lisp... je me demande meme si APL n'etait pas dans ce cas.

Mais effectivement je me suis mal exprime, je parlais de l'implementation dans un langage interprete qui n'en dispose pas naturellement d'une telle possibilite, pas de l'utilisation dans un langage interprete qui en fournit les primitives.

[progfou]

Peut-être peux-tu regarder du côté de la librairie GMP, qui implémente justement les calculs sur les grands nombres...
Par contre, je ne sais pas si c'est supporté en VB, j'ai jamais fait de VB, je ne trouve pas que ce soit un bon langage pour des développements un peu avancés...
Mais c'est un avis personnel

[Le Furet]

Je ne comprends pas l'intérêt de régler n a priori dans ce genre de calculs. Pourquoi ne pas interrompre le calcul lorsque le dernier terme rajouté est plus petit qu'une tolérance fixée ?

Mais quand bien même, sauf erreur, on est en présence d'une série alternée dont la valeur absolue du terme général tend vers 0, donc le reste au rang N est toujours plus petit que le terme de rang N.

La seule difficulté de ce problème est de coder une bibliothèque de gestion des grands nombres avec les 4 opérations. Une fois ça fait, le calcul du sinus ne pose pas de problème...

[j.p.mignot]

C'était déjà mon avi dans mon post du 15 nov. pour réduire n, on peut limiter x à 0 Pi/4 (en prenant le développement en série entiere de cos ou sin suivant la cas )

[méphistopheles]

merci à tous, j'ai fini par utiliser une dll c codée par un ami pour résoudre mon problème.

salut