cosinus et sinus - Page 1

Comment est faite la fonction cos et sin et comment la définir sur -100 et 100?

Je viens d'essayer ça:
cos x = 1 - x^2/(2!) + x^4/(4!)-x^6/(6!)+....
sin x = x - x^3/3!+x^5/(5!)-x^7/(7!)+...

Et plus on développe, plus la précision est élevé.

Vous avez quoi comme astuce très rapide? Sans table cos et sin?

Une table de COS et de SIN
Ou bien tu utilises les ROM_CALLS sin et cos que tu multiplies par 100 après.
Mais le mieux reste une table, je ne comprends vraiment pas pourquoi tu refues d'en utilier une...

Outre la méthode de la table, il n'existe pas une formule pour définir cos et sin entre -100 et 100?

Oui. Si tu veux vraiment une précision énorme tu peux en plus faire une interpolation linéaire sur ta table après (et ça te permet aussi de réduire la taille de ta table...)

Sinon tu peux utiliser l'algorithme de CORDIC (google...), mais à moins que tu veuilles implémenter une fonction ultra-précise ce n'est pas nécessaire.

Tu peux aussi essayer l'interpolation avec une fraction rationnelle (demande à Maple...)

J'ai vu ça, et ou je pourrais trouver des infos pour la création et l'utilisation de table de cosinus et sinus le plus petit possible?

Le plus petit possible : tu prends 8 bits de précision et tu codes jusqu'à 90°, mais sur 32 valeurs. Ça te prendra 32 octets.

Je viens de regarder la méthode de CORTIS, mais pensez-vous qu'il soit plus intressant de coder cette algo ou d'utiliser une table précalculé, bien sûr entre 0 et 90°,

Donc je réalise une table de cos, par exemple je veux une précision de 8 bits donc un entier de 2 bits et les chiffres après la virgule sur 6 bits, je remplit un tableau de 64 octets en prenant ma calculatrice et en partant de 0 à pi/2.

L'entier après la virgule peut ne faire qu'1 bit puisqu'un cosinus ne sera jamais supérieur ou égal à 2, et que dans la plage de valeurs que tu as choisie, tu n'as que des valeurs positives. Donc ta mantisse tient sur 7 bits (soit une multiplication par 127, ce qui est relativement proche de tes 100)

Ah oui, c'est l'algorithme de CORDIC.

Si tu n'as pas besoin d'une grande précision (par exemple pour un jeu), les séries de Taylor suffisent. Tu peux même les arrêter très vite.

Et pour l'évaluation de tes polynomes, utilise le schéma de Horner: a0+x(a1+x(a2+x(a3+x(...)))), pas la méthode naïve: ...+a3*x³+a2*x²+a1*x+a0 ou a0+a1*x+a2*x²+a3*x³+....

geogeo : demande les sources des fonctions trigo de pedrom...

vince> il ne vaut mieux pas

L'entier après la virgule peut ne faire qu'1 bit puisqu'un cosinus ne sera jamais supérieur ou égal à 2, et que dans la plage de valeurs que tu as choisie, tu n'as que des valeurs positives. Donc ta mantisse tient sur 7 bits (soit une multiplication par 127, ce qui est relativement proche de tes 100)

Oui tu as raison puisuqe je vais de 0 à pi/2. En effet j'ai regardé et il semble que une précision de 6 bits soit vraiment suffisant mais autant en utiliser 7.

Si tu n'as pas besoin d'une grande précision (par exemple pour un jeu), les séries de Taylor suffisent. Tu peux même les arrêter très vite.

Oui j'ai essayé ça aussi et ça fonction bien.

Et pour l'évaluation de tes polynomes, utilise le schéma de Horner: a0+x(a1+x(a2+x(a3+x(...)))), pas la méthode naïve: ...+a3*x³+a2*x²+a1*x+a0 ou a0+a1*x+a2*x²+a3*x³+....

Oui pour diminuer le nombres de multiplications, c'est très pratique.

geogeo : demande les sources des fonctions trigo de pedrom...

Loin de là, je cherche à développer moi même cette algo et non retaper à droite et à gauche, j'ai toujours fait ça.



Bon j'ai réalisé un algo en assembleur utilisant l'algo de CORDIC, ça semble très bien fonctionner mais pensez-vous qu'il soit mieux de réaliser une table de cos et sin de 128 valeurs dans chaque table ou d'utiliser l'algo de CORDIC?

Dans le cas d'une table de cos et sin, 128 valeurs c'est beaucoups? Le mieux est d'y mettre que des entiers? Et est-il plus interessant d'utiliser une marge entre 0 et pi/2 ou 0 à 127?

Les fonctions trigonométriques de PedroM boguent dans tous les sens, d'ailleurs.

geogeo
: Bon j'ai réalisé un algo en assembleur utilisant l'algo de CORDIC, ça semble très bien fonctionner mais pensez-vous qu'il soit mieux de réaliser une table de cos et sin de 128 valeurs dans chaque table ou d'utiliser l'algo de CORDIC?

A toi de voir ce qui te convient le mieux

Dans le cas d'une table de cos et sin, 128 valeurs c'est beaucoups?

Ça dépend, 128 valeurs pour coder jusqu'à PI/2 c'est très riche si c'est seulement pour diriger une balle. 128 valeurs pour couvrir 2*PI rad, c'est plutôt pauvre, mais suffisant pour diriger une balle.

Le mieux est d'y mettre que des entiers?

Bah dans un octet que veux-tu mettre d'autre ?

Et est-il plus interessant d'utiliser une marge entre 0 et pi/2 ou 0 à 127?

Je trouve personnellement que c'est mieux de couvrir 2*PI rad ça permet d'utiliser très facilement la table. Parce qu'en ne couvrant que PI/2 valeurs dans ta table, elle devient moins simple à exploiter.
Là encore, à toi de voir ce qui te convient le mieux.
Une table qui couvre tout peut être utilisée immédiatement, mais prend plus de place qu'une table qui ne couvre qu'un quart de cercle (mais cette dernière table nécessite une fonction pour être exploitée et cette fonction prend de la place et du temps).

A toi de voir ce qui te convient le mieux

Je pense plutôt utiliser une table de COS et SIN, de plus je gagne énormément de ressources car il suffit juste de choisir la valeur voulu dans la table.

Ça dépend, 128 valeurs pour coder jusqu'à PI/2 c'est très riche si c'est seulement pour diriger une balle. 128 valeurs pour couvrir 2*PI rad, c'est plutôt pauvre, mais suffisant pour diriger une balle.

Je vais plutôt aller de 0 à pi/2 et utiliser 64 valeurs différente, ça suffit largement.

Bah dans un octet que veux-tu mettre d'autre ?

Oui bien sûr, mais faut que je réflechisse comment utiliser correctement les valeurs sorties par mes fonctions cos et sin.

Je trouve personnellement que c'est mieux de couvrir 2*PI rad ça permet d'utiliser très facilement la table. Parce qu'en ne couvrant que PI/2 valeurs dans ta table, elle devient moins simple à exploiter.
Là encore, à toi de voir ce qui te convient le mieux. Une table qui couvre tout peut être utilisée immédiatement, mais prend plus de place qu'une table qui ne couvre qu'un quart de cercle (mais cette dernière table nécessite une fonction pour être exploitée et cette fonction prend de la place et du temps).

Bah aller de 0 à Pi/2 ça suffit, ok il reste une fonction à réaliser pour aller au delà de pi/2 en modifiant le résultat. De plus ça me semble plus adapter pour un casse briques?

Merci de votre aide, je vais voir ce que je peux faire.

Comment faire pour que TIGCC accepte cette écriture:
for (int i=0;i<10000;i++);

Il y a référence à une norme C99, peut-on l'utiliser car il est vraiment pratique d'initialiser une variable dans une boucle dans le cas ou cette varaible ne sert qu'à cette boucle.

Merci Kevin, au point vu de la taille ou de la vitesse du programme ça n'a aucunes importances?

Une dernière chose:
Est-ce qu'il existe un moyen d'éviter une division de 100 lorsque je veux afficher correctement les coordonnées de la balle, car je fait, xpos=xpos+Tbl_pcos [x], où les valeurs de la table vont de 0 à 100, la table contient 64 items.

Je sais que je peux utiliser des nombres à virgule fixe dans ma table et donc extraire les bits qu'il faut pour avoir la bonne coordonnée de la balle, mais est-il plus interessant d'utiliser des nombres entier ou des nombres à virgule fixe?

geogeo a écrit :
[...]

Je vais plutôt aller de 0 à pi/2 et utiliser 64 valeurs différente, ça suffit largement.
[...]

Tu peux diviser la taille en mémoire par 2, puisque si tu as la table des Cos de 0 à Pi/2, celle des Sin est inutiles :
V x € [0 ; Pi/2], Sin(x) = Cos(Pi/2 - x), avec (Pi/2 - x) € [0 ; Pi/2], donc dans ta table des Cos.

@++

Oui j'ai remarqué ça aussi, d'ailleurs j'ai donné la formule en haut qui correspond à ce que tu dit. Merci de me l'avoir rappelé.

geogeo
: Merci Kevin, au point vu de la taille ou de la vitesse du programme ça n'a aucunes importances?

Ça n'a aucune importance. C'est juste une question de syntaxe acceptée.

Une dernière chose:
Est-ce qu'il existe un moyen d'éviter une division de 100 lorsque je veux afficher correctement les coordonnées de la balle, car je fait, xpos=xpos+Tbl_pcos [x], où les valeurs de la table vont de 0 à 100, la table contient 64 items.
Je sais que je peux utiliser des nombres à virgule fixe dans ma table et donc extraire les bits qu'il faut pour avoir la bonne coordonnée de la balle, mais est-il plus interessant d'utiliser des nombres entier ou des nombres à virgule fixe?

Ce que tu fais est déjà de la virgule fixe, mais avec une mauvaise base (100). Remplace ton 100 par 128, et ça ira beaucup plus vite. (Et oui, tu peux remplacer 1 par 127/128, on ne risque pas de remarquer normalement.)

OK, ce qui permettera de décomposer 128 par le compilateur en 2^7.

Enfin de compte j'ai pris une table de 256 octets pour sin et cos et je vais de 0 à 2pi, c'est bien plus simple.
Le code est vraiment rapide et simple.

Il me reste à trouver les calculs à réaliser pour que sin ou cos change de signe, j'ai déjà rouvé pour une collision suivant y avec l'écran, il me reste x.

J'ai un problème que je n'arrive pas à résoudre en 1 ligne.
Voilà, j'ai réalisé ce programme qui s'occupe de diriger une balle de 0 à 2pi en changeant l'angle de déplacement avec le curseur gauche et droit. Or je voudrais que cette balle rebondisse lorsqu'elle touche les bords de l'écran.

#include <tigcclib.h>

short xpos=0, ypos=0;
short pcos=0, psin=0;
unsigned short x_pcos=0, y_psin=0;

//64 octets, pcos
const char Tbl_pcos [256] = {127,126,126,126,126,126,125,125,124,123,123,122,121,120,119,118,117,116,114,113,111,110,108,107,105,103,101,99,97,95,93,91,89,87,85,82,80,77,75,72,70,67,64,62,59,56,53,51,48,45,42,39,36,33,30,27,24,21,18,14,11,8,5,2,0,-3,-6,-10,-13,-16,-19,-22,-25,-28,-31,-34,-37,-40,-43,-46,-49,-52,-55,-57,-60,-63,-66,-68,-71,-73,-76,-78,-81,-83,-86,-88,-90,-92,-94,-96,-98,-100,-102,-104,-106,-107,-109,-111,-112,-113,-115,-116,-117,-118,-119,-120,-121,-122,-123,-124,-124,-125,-125,-126,-126,-126,-126,-126,-126,-126,-126,-126,-126,-125,-125,-124,-124,-123,-122,-121,-121,-120,-119,-117,-116,-115,-114,-112,-111,-109,-108,-106,-104,-102,-101,-99,-97,-95,-92,-90,-88,-86,-84,-81,-79,-76,-74,-71,-69,-66,-63,-61,-58,-55,-52,-49,-46,-43,-40,-38,-35,-32,-28,-25,-22,-19,-16,-13,-10,-7,-4,-1,2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59,61,64,67,69,72,75,77,79,82,84,87,89,91,93,95,97,99,101,103,105,106,108,110,111,113,114,115,117,118,119,120,121,122,123,123,124,125,125,125,126,126,126,126,127};
const char Tbl_psin [256] = {0,-3,-6,-9,-12,-15,-18,-21,-24,-27,-30,-33,-36,-39,-42,-45,-48,-51,-54,-57,-60,-62,-65,-68,-70,-73,-75,-78,-80,-83,-85,-87,-90,-92,-94,-96,-98,-100,-102,-104,-105,-107,-109,-110,-112,-113,-115,-116,-117,-118,-119,-120,-121,-122,-123,-124,-124,-125,-125,-126,-126,-126,-126,-126,-126,-126,-126,-126,-126,-125,-125,-124,-124,-123,-123,-122,-121,-120,-119,-118,-117,-115,-114,-113,-111,-110,-108,-106,-105,-103,-101,-99,-97,-95,-93,-91,-89,-86,-84,-82,-79,-77,-74,-72,-69,-66,-64,-61,-58,-56,-53,-50,-47,-44,-41,-38,-35,-32,-29,-26,-23,-20,-17,-14,-11,-8,-4,-1,1,4,7,10,13,16,20,23,26,29,32,35,38,41,44,47,50,52,55,58,61,63,66,69,71,74,76,79,81,84,86,88,90,93,95,97,99,101,103,104,106,108,109,111,112,114,115,116,118,119,120,121,122,122,123,124,124,125,125,126,126,126,126,126,126,126,126,126,126,125,125,124,124,123,122,121,120,119,118,117,116,115,113,112,110,109,107,106,104,102,100,98,96,94,92,90,88,85,83,81,78,76,73,71,68,65,63,60,57,54,52,49,46,43,40,37,34,31,28,25,22,19,16,12,9,6,3,0};


INT_HANDLER OldInt1 = NULL;
INT_HANDLER OldInt5 = NULL;

unsigned char ball_sprite [] = {0b00111100,
		0b01111110,
		0b11111111,
		0b11111111,
		0b11111111,
		0b11111111,
		0b01111110,
		0b00111100};

void _main(void)
{	
	OldInt1 = GetIntVec (AUTO_INT_1);
	OldInt5 = GetIntVec (AUTO_INT_5);
	SetIntVec (AUTO_INT_1, DUMMY_HANDLER);
	SetIntVec (AUTO_INT_5, DUMMY_HANDLER);
	
	ClrScr ();
	GrayOn ();
	
	short rad=124;
	
	xpos=LCD_WIDTH/2; ypos=LCD_HEIGHT/2;
	
	x_pcos=xpos*128; y_psin=ypos*128;
	pcos=Tbl_pcos [rad];
	psin=Tbl_psin [rad];
	
	Sprite8 (xpos,ypos,8,ball_sprite,GetPlane (0),SPRT_OR);
	
	while (!_keytest (RR_ESC))
	{
		//SetPlane (1); ClrScr ();
		
		Sprite8 (xpos,ypos,8,ball_sprite,GetPlane (0),SPRT_XOR);
		x_pcos+=pcos;	y_psin+=psin;
		xpos=x_pcos/128;
		ypos=y_psin/128;
					
		if (_keytest (RR_DOWN)) rad-=2;
		if (_keytest (RR_UP)) rad+=2;
		
		if (rad<0) rad=255;	
		if (rad>255) rad=0;
		
		if (xpos==0) rad=[4]???[/4];
		if (xpos+8==LCD_WIDTH-1) rad=[4]???[/4];
		if (ypos==0) rad=255-rad;
		if (ypos+8==LCD_HEIGHT-1) rad=255-rad;
		
		pcos=Tbl_pcos [rad];
		psin=Tbl_psin [rad];
		
		//printf_xy (0,0,"%d",rad);
		//printf_xy (0,10,"%d",tsin);
		
		Sprite8 (xpos,ypos,8,ball_sprite,GetPlane (0),SPRT_OR);
		DrawPix (xpos+4, ypos+4, A_NORMAL);
		for (int i=0;i<10000;i++);
	}
	
	GrayOff ();
	SetIntVec (AUTO_INT_5, OldInt5);
	SetIntVec (AUTO_INT_1, OldInt1);
}

x_pcos, correspond à la valeur réelle de la coordonné x de la balle.
y_psin, correspond à la valeur réelle de la coordonné y de la balle.
pcos, valeur du cosinus en cours.
psin, valeur du sinus en cours.
xpos, ypos, coordonnées de la balle.
rad=angle

Les 2 tables Tbl_pcos et Tbl_psin vont de 0 à 255:
0=0
63=pi/2
127=pi
191=-pi/2
255=2pi

Pour effectuer un rebond, il suffit de modifier le 'signe' de pcos ou psin, or je veux obtenir ce signe et le bonne angle dans les 2 tables Tbl_pcos et Tbl_psin.

Si j'effectue un rebond de la balle suivant y, soit le haut et le bas de l'écran, je fait tout simplement rad=255-rad; Or je n'arrive pas à trouver le calcul pour changer le signe de pcos avec des rebonds suivant x soit le coté gauche ou droit de l'écran.

if(xpos==0 || xpos+8==LCD_WIDTH-1)rad=128-rad;
Ça me paraît correct d'après mes petits shémas.
Mais fais comme moi : un shéma et tu trouveras toi-même la formule...

En plus tu as su trouver tout seul pour y... D'ailleurs c'est 256, pas 255.

J'ai essayé ça fonctionne pas, j'avais trouvé 255-(rad+128); et ça fonctionne à moitié, j'ai fait des schémas et des calculs et je trouve des formules qui bug.

Il faut aussi que tu vérifies que rad ne dépasse pas l'intervalle [0;256[ puisque tu l'utilises en indice de tableau.