Bonjour,
j'utilise CC5X avec MPLAB et je me suis apercu que les floattant était codés sous 24 bits, quelqu'un pourait-il m'expliquer comment se fait ce codage.
Merci
-----
Bonjour,
j'utilise CC5X avec MPLAB et je me suis apercu que les floattant était codés sous 24 bits, quelqu'un pourait-il m'expliquer comment se fait ce codage.
Merci
Bonne lecture:
http://fr.wikipedia.org/wiki/Virgule_flottante
Il y a une régle du jeu (pas humaine à comprendre) avec une mantisse et un exposant et des bits de signe. C'est de la curiosité malsaine (et inutile) de la chercher
Edit: Oui Jack, tu me donnes raison
Bonjour
Dandet je ne te suis pas il faut comprendre la notation flottante cela évite des catastrophes, et là je n'exagère pas!
Donc une saine lecture:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Les flottants ne sont pas les "réels", contrairement à ce que le programmeur lambda croit, ce sont des nombre rationnels et ils appartiennent à un ensemble de cardinal fini.
JR
Bon, c'est pas les équations de Maxwell non plus, mais il est vrai qu'on a plus trop besoin aujourd'hui de fouiller trop de ce côté.
A moins d'être maso et de travailler avec des nombres flottants en assembleur.
A+
Ce que je veux dire, c'est que le (dé)codage d'un flottant est difficile pour un être humain normal. Et dans cette opération, il y a 99,999 % de chance de se tromper (avec en plus le problème du big ou little Indian ). Donc je considère cette opération inutile et du niveau de la masturbation intellectuelle. La seule fois ou j'ai eu a le faire, c'était au niveau d'une transmission RS232 et c'était pour déterminer l'ordre de transmission des octets...... et j'ai utilisé un logiciel de conversion binaire->flottant pour éviter les erreurs
Plutôt ENDIAN peut-êtreproblème du big ou little Indian
Exact Docteur Watson
Bonsoir
Que nenni Daudet il importe de savoir si un flottant reçu par une transmission est bien encore conforme au codage car sinon toutes les vérifications du style : si x < 2.0 et x >= 0.0 alors .... peuvent se terminer par: floating point error goto kaboum (exemple vécu).
Autre conséquence de l'ignorance du codage les boucles du genre
x := 0.0
while x /= 2.456 loop
.....
x := x + 0.004
end loop
on pourrait croire que la boucle s'effectuera 615 fois et bé non c'est une boucle infinie car en IEE754 32 bits
2,456 => 401D2F1B => 2.4560001
0,004 => 3B83126F => 4.0000002e-3
et le ratio ne fait pas 614 et le cumul ne passera jamais par 2,456!!!
Autre piège la granularité : essayes donc de faire(par soft) une horloge dont le pas soit par exemple de 1/50 eme de seconde et qui ne retarde pas au bout de qqs heures (exemple également vécu j'en ris encore).
Le flottant c'est souvent la solution des feignants mais il faut savoir être feignant en connaissance de cause !
JR
Pas trop d'accord
transmission
La transmission de donnée doit toujours se faire avec, au minimum, une parité globale ou mieux un CRC. Et c'est pas en examinant la structure interne du flottant que l'on détecte l'erreur.
boucle
1/ faire une boucle avec un flottant et ne pas mettre while x <= 2.456 loop (en VB6, en C la syntaxe est différente). C'est ne pas savoir programmer. On se fait pas prendre deux fois ......normalement
2/ faire une boucle avec un flottant, c'est qu'on a pas de problème de temps d'exécution ou que l'on a un Pentium IX
C'est pas parce qu'on connait la structure interne de la représentation d'un flottant qu'on évite ce genre d'erreur
Par contre, débugger une transmission qui merpute les octets dans le sens ou on l'attend pas, c'est intéressant d'avoir un logiciel qui vous donne en décimal la valeur retournée par le flottant. Mais je fais pas ça à la paluche !
Oui mais imagine que par suite d'une agression externe ton message se trouve avoir le bon CRC mais que le contenu du message soit pourri , en clair le CRC c'est celui du message pourri dans ce cas que fais tu ?
Je penses que tant que l'on reste les pieds sur terre on ignore beaucoup de phénomènes!
Calculer en flottant c'est aussi rapide qu'en entier quelquefois même plus rapide!
JR
FAUX, si le CRC est bon, la probabilité que le message soit niqué quand même est de 0,00000001%
FAUX, une multiplication de deux entiers est plus rapide que la multiplication de deux flottants (sauf sur un processeur qui a un opérateur flottant câblé, genre DSP, mais pas sur un PIC ou un 8051)
Tu n'as pas bien luFAUX, si le CRC est bon, la probabilité que le message soit niqué quand même est de 0,00000001%
FAUX, une multiplication de deux entiers est plus rapide que la multiplication de deux flottants (sauf sur un processeur qui a un opérateur flottant câblé, genre DSP, mais pas sur un PIC ou un 8051)
J'explique parce que manifestement comme je l'ai écrit certains phénomènes sont inimaginables pour les gens qui ne se sont jamais frotté à l'avionique ou a fortiori au spatial : imagine une mémoire dans laquelle tu stockes un message à émettre que ce message soit émit par un dispositif qui en calcule automatiquement le CRC mais qu'entre le moment ou tu écris le message et celui ou celui ci est émit (<50ms) tu te manges une bonne bouffée de neutrons qui flippent qqs bits alors tu émets un message au contenu pourri mais dont le CRC est juste et là tu n'a plus que tes yeux pour pleureren clair le CRC c'est celui du message pourri dans ce cas que fais tu
Donc JUSTE
Tous les processeurs sérieux (Pxx, Power PC, etc etc) ont une alu flottante, PIC et 8051 sont des amusettes!
Donc JUSTE encore.
Sur T800 la multiplication flottante était plus rapide que celle en entiers en effet la mantisse n'a que 24 bits(en comptant l'implicite) alors qu'un entier 32 bits en a 32(en comptant le bit de signe).
Un petit détail pour finir un code correcteur d'erreur est conçu pour détecter et corriger un certains nombre d'erreurs par exemple les codes de Hamming utilisés pour sécurisé les mémoires DRAM on une distance de 4 il détectent 2 et corrigent 1 erreur, s'il y a 3 erreurs c'est la loterie, il est donc extrêmement difficile d'avoir une assurance lorsque le canal de transmission a un taux d'erreur supérieur à celui que le code couvre!
JR
On est pas, sur ce forum, dans le spatial, ni dans une centrale nucléaire. Donc les pollutions aux neutrons lents, lourds ou rapides, les pollutions aux rayons alpha, béta ou omèga c'est pas le problème ici.
PIC et 8051 sont peut être un amuse gueulle mais, si on faisait un sondage, les utilisateurs de ce forum compilent et font tourner plus de ligne de "C" sur ces pauvres bestioles de bas étage que sur des DSP ou autres.
Quand au correcteur de Hamming, y en a pas des masses sur les DRAM de PC
Et je vois pas en quoi savoir interpreter les 24 bits d'un flottant change quelque chose au Schmiliblic.
Re
Sur le PC lambda oui mais sur celui qui sert de serveur à Futura je suis sur qu'il y en a.
Sur les machines que j'utilise au boulot aussi car pour pouvoir faire tourner des simulations pendant 3 semaines non stop il faut se prémunir contre les neutrons, eh oui même au sol il suffit d'attendre plus longtemps!
Avec les nouvelles techno cela va devenir le problème de tout le monde :
DDR2 10x plus sensible que SDRAM !!!!
Pour ce qui est de l'utilité de savoir comment sont codés les flottants c'est vrai que pour le commun des mortels cela ne sert à rien mais si on se dit électronicien et informaticien de surcroit c'est le BA BA!
En plus c'est le sujet de ce fil!
Cordialement.
JR
Et je répéte :
1/ Que ceux qui ont du correcteur de Hamming sur leur PC léve la main ( c'est pas la foule enthousiaste !)
2/ Qu'interpréter du flottant à la paluche sert à rien (y a de bon soft pour ça)
Et c'est mon dernier mot
re
1 je n'ai jamais écrit qu'il fallait se le palucher à la main car depuis qu'internet existe il y a de bons sites pour ça!
http://babbage.cs.qc.edu/IEEE-754/Decimal.html
2 page au hasard chez Micronhttp://www.micron.com/products/modul...?Select=Select
La moitié ou presque des référence sont des barettes ECC.
J'ai écrit : serveur ou PC professionnel
Décidément encore une lecture trop rapide!
JR