salut
voila, je cherche a faire une fonction de calcul de sinus (en asm)
la question que je me pose, c'est jusqu'a quel ordre aller dans le developpement limité pour avoir une approximation correcte
 
je reste dans l'intervalle [0;pi/2] pour éviter d'avoir un nombre trop élevé, mais apres, je me demande ou je dois arreter le developpement.
 
je pensais ordre 5 ou 7, mais est-ce que c'est suffisant sur cet intervalle ?
 
++ all

ptit up plz

Ben ca dépend de l'utilisation que tu fais de la valeur calculée!

ça dépend à partir de quel ordre tu es satisfait ...

l'utilisation de la valeur calculée, c pour tracer un graphe a l'aide d'un tableur (excel a priori).
les valeurs serviront a tracer le graphe de sin, mais aussi de fonctions paramétrées à base de sin et cos
bon, de tte facon, je vais faire les tests a l'ordre 5 et si je suis pas satisfait, je verai pour l'ordre 7

voila, j'ai fini, donc pour la petite histoire, j'ai en fait codé le cosinus (j'en déduirai le sinus, mais le cosinus est moins chiant a coder.)
 
je dois aller à l'ordre 12 pour obtenir quelquechose de satisfaisant avec mon cosinus. (avec un ordre inférieur, j'avais parfois des cos>1)
 
la, ca marche bien, je vais donc coder mon sin basé sur ca
 
++ all

vala, le sinus est codé lui aussi
ben tout fonctionne, on va voir ce que ca donne sur les fonctions paramétrées

Ah bon? Les deux DL se ressemblent pas mal pourtant

oui, mais ya une chose qui simplifie la vie : cos(-a)=cos(a)
du coup, une valeur absolue au debut de la fonction sur la valeur de l'angle, et c fini..
pareil apres des changement de variable
 
pour le sin, j'etais obligé de faire plusieurs cas (n'oublie pas que c t en asm, donc pas tres "coder-friendly", en tout cas , pas pour moi )

Autrement des tables précalculées c'est bien aussi...

Faudrait savoir!  
 
edit : au fait j'adore ta signature  

 
merci pour la signature
 
pour ce qui est de l'intervalle, je reste sur [0;pi/2] certes, mais après mon modulo
 
donc je peux tres bien calculer cos(-15) en le ramenant sur l'intervalle [0;pi/2]

 
oui, mais va faire ca en assembleur...
enfin, ca me semble difficile

Ben non justement.
Tu mets des valeurs statiques à un emplacement mémoire (enfin c'est comme ca qu'on fait ds les PICs) et si tu veux le sinus de 36° tu vas au 36eme emplacement de ton tableau...
Et s'il faut 36°43' tu fais une interpolation linéaire (ou tu arrondis car une precision d'un degré c'est souvent suffisant)

ah, pkoi pas, fodrait que je vois si c'est faisable
la, c du mips, mais c surtout mon premier programme donc je connais pas tout ca.
 
je testerai un jour quand j'aurais le temps, mais de toute facon, c'etait pas la consigne
 

ouais enfin bon, 1° de précision, c'est pas franchement folichon

c'est marrant ça, oui, c'est quoi le critère pour s'arrêter ?
 
en plus on a même pas de relation entre la précision et le degré du développement si ?

ben si tu peux donner epsilon(x)
 
je suis complètement hors du coût, mais à l'époque, il me semble avoir fait beaucoup de calcul comme ça

ah bon ? encadrer l'erreur en fonction du rang ?
 
 

on dit "trop cher"

effectivement, je ne pense pas qu'on ai réellement de renseignement sur la précision, mais on sait ce qui manque, en général, matérialisé sous la forme d'un o(x) ou O(x)
 
mais bon, je suis une bite en analyse et je c pas trop comment exploité ce truc
 
la bonne solution est de trouver le bon compromis précision/vitesse d'exécution

marne, je suis traumatisé, je fais lire un rapport rendu à ma mère, et là elle m'invente une faute en première page comme quoi j'aurais écrit coup au lieu de coût ...

hum, spa bien ca...

On peut aussi faire une approximation linéaire entre les 2 points hein...

Certainement pas lineaire si tu veux une precision raisonnable. Quadratique, j'aurais dit.

L'un est plus facile à réaliser que l'autre...  

Salut,
 
désolé de faire remonter ce topic à la surface.
 
Juste pour dire qu'on peut estimer l'incertitude en fonction du rang de développement :
 
en gros à chaque ajout d'un terme dans le développement limité, on passe d'un côté et d'un autre de la courbe recherchée (ici cosinus). Il suffit alors de faire la différence entre 2 courbes d'ordre consécutif (n et n+2) pour avoir l'incertitude de la première (ordre n) avec une légère surextimation (mais c'est moins grave que l'inverse quoiqu'on pourrait ralentir le calcul avec un ordre élevé non nécéssaire).
 
Donc, pour un développement limité à l'ordre n, abs(x^(n+2)/(n+2)!) donne l'incertude au point x (abs parce qu'on se fout un peu de quel côté de la courbe on est). Il 'suffirait' alors de calculer cette incertitude de proche en proche jusqu'à avoir satisfaction.