Probleme de calcul

invite68a88160 · 17/07/2008, 21h06

Salut je suis en train de faire un programme pour un pic18f et j'ai des probleme de résultat dans mes calcul.

En fait les calculs sont très complex et utilise des float.

Le problem est dans les divisions

J'aimerais avoir la précision d'un calcul sur PC
Je programme avec mikroB ou MikroC

J'ai le bon calcul mais en 2 temps ... valeur entière et le reste(MOD

Sa parrait peut-etre bizarre mais est-ce possible d'additionné les 2 nombre pour avoir ma vrai valeur ?

Exemple de calcul

t = -0.08033532

rr1 = 280.46061837 + 360.98564736629 * (733655.4321 - 2451545) + 0.000387933 * t * t - t * t * t / 38710000

rr2 = rr1 - 360 * longint(rr1 / 360)

Merci de me dépanné je rush sa fait un bon bout de temps.

invite0e5af214 · 17/07/2008, 23h05

C'est quoi longint() ???

Et remplace 360 par 360.0

verdict ?

**Seb.26** · 18/07/2008, 00h10

et sur PC, ça donne quoi ton truc ???

invite68a88160 · 18/07/2008, 01h10

Le probleme c'est qui perd de la précision ... et quand le calcul dure quelques 40 lignes de code ben en perdre de la préckision un petit peu par si et par la ben sa fait très grosse différence a la fin.

J'ai vérifié le calcul ligne par ligne avec un logiciel que j'ai créé sur le PC
Excemple Pc = 123.1234 Pic = 123.1217
Voila mon probleme

A voir en vidéo sur Futura · Aujourd'hui

invite74b5b8f7 · 18/07/2008, 08h43

Salut,

J´ai eu le même problème (sur des MSP430 de chez TI), mes fonctions de transfert (filtres passe bas Bessel second ordre) avait des coefficients trop faibles (xx10^-6, etc...) et sur uC mon filtre oscillait même avec une valeur fixe en entrée alors que sur PC tout allait bien (copier/coller du filtre et pas d´oscillation).
En désespoir de cause, je me suis fait une cellule du premier ordre (coefficients déjà un peu plus grand) qui travaille en entier...
La difficulté est d´utiliser au maximum la capacité des long et de gérer le plus de restes possibles en fonction de la précision que tu veux.
Je les gères sur 3 "niveaux" et j´ai fait une simulation sur PC (en entier c´est pareil) pour vérifier que je ne perd pas des valeurs au fur et à mesure (simulation du fonctionnement non-stop de la carte pendant 300 jours et je n´ais pas perdu une seule unité...)
Le seul problème c´est qu´il faut pouvoir trouver un coefficient qui fera que tous tes nombres seront des entiers pour pouvoir tout rediviser à la fin (et on ne sait pas à quoi servent tes calculs)

Tu t´es renseigné sur la précision des float/double?

**Seb.26** · 18/07/2008, 11h01

Envoyé par danca

J'ai vérifié le calcul ligne par ligne avec un logiciel que j'ai créé sur le PC
Excemple Pc = 123.1234 Pic = 123.1217
Voila mon probleme

Normalement, c'est pas possible, ou alors il y a des bugs dans ta lib math.h

Essaye en double pour voir

invite74b5b8f7 · 18/07/2008, 11h42

Si, c´est tout à fait possible, ca dépend de la précision des float/double, par contre je crois que c´est du au compilateur et non au microcontrolleur (mais pas sur) car c´est lui qui code les réels comme il veut et qui fait le traitement des opérations en réels avec les instructions disponibles sur le uC.

http://fr.wikipedia.org/wiki/IEEE_754

Et le fait de faire plusieurs opérations successives fait que l´erreure s´accumule et qu´elle peut devenir importante...
La seule valeur sûre c´est l´entier!

**Seb.26** · 18/07/2008, 13h45

Envoyé par lil-vince

Si, c´est tout à fait possible, ca dépend de la précision des float/double

NON.

Un float en C/C++, c'est > 31bits, et un double c'est > 63bits ...

Ne confonds pas normalisation des types de données d'un language et normalisation de représentation de nombres binaires

Y'a pas à chercher plus loin ...

**Seb.26** · 18/07/2008, 13h48

Envoyé par lil-vince

La seule valeur sûre c´est l´entier!

que dalle ... ou alors tu commence tout tes programmes par :

Code:

{
 char test_char;
 ASSERT(sizeof(test_char)=1;
 short test_short;
 ASSERT(sizeof(test_short)=2;
...

**Seb.26** · 18/07/2008, 13h50

Si tu veux en avoir le cœur net, regarde tes *_EPSILON, *_DIG, *__MIN et *_MAX ...

invite68a88160 · 18/07/2008, 16h25

Envoyé par Seb.26

NON.

Un float en C/C++, c'est > 31bits, et un double c'est > 63bits ...

Ne confonds pas normalisation des types de données d'un language et normalisation de représentation de nombres binaires

Y'a pas à chercher plus loin ...

Le probleme c'est que avec un Pic que se soit float ou double c'est maimum 32bits

En fait ce que je recherche c'est une précision d'une calcultatrice.
J'ai tout essayé ... J'ai segmenté le calcul des divisions.

En fait j'ai des float de 7 entier au moin et autant de décimal ... donc la il se perd

**Seb.26** · 18/07/2008, 17h22

Envoyé par danca

Le probleme c'est que avec un Pic que se soit float ou double c'est maimum 32bits

C'est pas lié au PIC, mais à ton compilo ...
Il n'est pas ISO ... double >= 64bits

invite68a88160 · 18/07/2008, 17h55

Envoyé par Seb.26

C'est pas lié au PIC, mais à ton compilo ...
Il n'est pas ISO ... double >= 64bits

Ok .. je vais regarder ... j'utilise MikroC ou MikroB et sa compile juste 32bits

Merci je vais vérifier avec un autre compilateur

**Seb.26** · 18/07/2008, 21h08

Et oui, car si ton compilo sur PC est ISO (ce qui est presque certain) , il va calculer en 64b pour les double, mais si ton compilo PIC n'est pas ISO et qu'il utilise un flot quand tu demande un double, le résultat ne sera pas identique ...

Pour vérifier, tu peux faire (sur PC) le calcul en float, puis en double ... tu devrais obtenir mes mêmes éccart qu'entre le double PIC et le double PC ( si ton double PIC est en fait un float )

petit test : si sur PC tu calcule en float, et sur PIC aussi, tu obtiens des résultats différents ?
( regarde bien la valeur des octets en RAM, et pas simplement le résultat d'un printf ou de ce qu'affiche le débugger ... )

invite74b5b8f7 · 19/07/2008, 14h11

Ne confonds pas normalisation des types de données d'un language et normalisation de représentation de nombres binaires

Je ne confond pas, j´ai mis le lien pour voir d´où vient l´erreure (s´il ne se rappelait pas du codage) et c´est peut-être que nos compiulos ne sont pas aux normes, mais le fait est que moi aussi mon compilo ne représente les double que sur 32 bits...

J´ai donc résolut le problème en faisant mes calculs en entiers et en gérant les restes...

La seule valeur sûre c´est l´entier!

que dalle ... ou alors tu commence tout tes programmes par :
Code:

{ char test_char; ASSERT(sizeof(test_char)=1; short test_short; ASSERT(sizeof(test_short)=2;

Je sais pas si c´est que je suis pas encore réveillé mais j´ai pas bien compris ta blague!

Pour vérifier, tu peux faire (sur PC) le calcul en float, puis en double ... tu devrais obtenir mes mêmes éccart qu'entre le double PIC et le double PC ( si ton double PIC est en fait un float )

Justement c´est ca, vu que les double sont codés sur seulement 32bits!

Posté par danca Voir le message
J'ai vérifié le calcul ligne par ligne avec un logiciel que j'ai créé sur le PC
Excemple Pc = 123.1234 Pic = 123.1217
Voila mon probleme

Normalement, c'est pas possible, ou alors il y a des bugs dans ta lib math.h

Tu vois que c´est possible...

**Seb.26** · 19/07/2008, 14h38

Envoyé par lil-vince

Justement c´est ca, vu que les double sont codés sur seulement 32bits!

Donc il faut changer de compilo, le tient ne sait pas faire ce que tu lui demande ...

Ou alors passer par une LUT si c'est possible ...
( mais change quand même de compilo !!! ... ou ajoute une lib maison pour gérer correctement les double )

invite74b5b8f7 · 19/07/2008, 14h58

ou ajoute une lib maison pour gérer correctement les double

C´est vrai, j´y avait pas pensé, j´y réfléchirai...
Par contre je ne vais pas changer de compilo tout de suite (c´est à mon boulot et ca ne plairait surement pas trop à mon patron d´en acheter un autre...surtout que ca marche très bien comme ca, au moins c´est moi qui gère la précision que je veu...)

Probleme de calcul