Motif binaire - Page 1

Je cherche a obtenir le motif binaire d'un char et de le mettre dans un tableau comme le fait la fonction suivante:

	for (i=0;i<8;i++)
	{
		tab[i]=(mot & (int) pow(2,i))/(int) pow(2,i);
	}

Mais je sais pas si c'est l'idéal de faire ca comme ca, j'ai essayé avec des structures et des unions mais sans reussite.
Merci de votre aide

Edited_3611

ok merci

Oui, surtout que avec pow ça ne marche pas.
Selon l'approximation effectuée, tu peux avoir 2 fois le même bit, et pas le suivant du tout.

C'est un peu exagéré de dire que ça ne marche pas : en pratique, les implémentations utilisent des puissances de 2, du coup tout se fait de manière exacte Mais c'est vrai que je ne crois pas que cette exactitude soit garantie par aucune norme (y compris IEEE), donc c'est effectivement une mauvaise idée ^^

Sauf ke sur TI se sont des puisances de 10!

Mais 10 étant un multiple de 2, ça ne pose pas de problème non plus ^^ (et à vrai dire, sur TI, c'est mieux puisque c'est presque garanti que ça marchera : on écrit un programme pour une plateforme unique, avec une seule implémentation de pow(), dont on connaît la qualité d'approximation -- bref, pas vraiment de problème ; alors que sur PC, il y a potentiellement plein d'implémentations différentes d'IEEE, avec des pow() qui arrondissent plus ou moins bien...)

Pollux> en fait je pensais surtout à l'approximation en entrée, vu que les paramètres sont convertis en float avant d'être passés à la fonction.

Ah non, ça par contre je crois qu'on est certain que ça ne pose pas de problème : IEEE garantit la précision des approximations pour les opérations de conversion/addition/multiplication... (heureusement, sinon ça serait difficile de faire des algorithmes portables)
Du coup (int)(float)x == x du moment que x est assez petit pour être représenté par un float. Le vrai problème, c'est que pow() n'offre aucune garantie de précision, et peut très bien commettre des petites erreurs, laquelle petite erreur pourrait impliquer que l'entier arrondi sera celui d'en-dessous :/

(heureusement, sinon ça serait difficile de faire des algorithmes portables)

Un algorithme qui s'appuie sur la précision des nombres est mal conçu de toutes façons.

Qu'est-ce que tu racontes ? Par exemple on va dire que tu programmes un logiciel pour une fusée. Comment est-ce que tu peux avoir la moindre idée de la correction de ton algorithme si tu n'as pas, au moins, une borne dans le pire des cas de l'erreur commise par l'addition ? Comment est-ce que tu comptes écrire un logiciel qui décide si oui ou non il faut éteindre le réacteur, tout en étant "indépendant" de la précision des nombres ? (à moins d'utiliser uniquement de l'arithmétique entière )

C'est d'autant plus crucial que, même si la précision n'est pas toujours primordiale quand tu n'as pas de boucles ou de feedback, une erreur d'un bit de poids faible cumulée sur plein d'itérations risque bien de devenir gigantesque (divergence).

Tu connais les opérations qui sont dangereuses en flottant. Tu ne les utilises pas si tu fais des calculs flottant. C'est aussi simple que ça.
Notamment les additions et soustractions de flottants qui sont deux opérations casse-gueules à souhait.

spectras :
Tu connais les opérations qui sont dangereuses en flottant. Tu ne les utilises pas si tu fais des calculs flottant. C'est aussi simple que ça.
Notamment les additions et soustractions de flottants qui sont deux opérations casse-gueules à souhait.

Euh, il faut pas utiliser des additions ou des soustractions quand on fait des calculs flottants ?

Non en effet. C'est le meilleur moyen d'obtenir un résultat faux.
C'est évident en plus ^^

Qu'est-ce que tu appelles un "résultat faux" ? Un résultat qui ne correspond pas à l'addition des réels (mais ça, on s'en serait un peu douté ), ou bien un résultat dont on ne sait absolument pas si l'erreur commise est d'un bit de poids faible ou de beaucoup plus que ça ?

Parce que bon, tes principes ils sont bien gentils, mais c'est pas avec ça que tu vas nous faire marcher un Airbus Comment tu t'y prendrais ?

L'erreur sur des flottants, ça se compte pas en bits hein . Je te rappelle que t'as un exposant devant, et pourvu que tu additionnes avec des grandeurs différentes, ton bit d'erreur se trouve multiplié par beaucoup.
Un résultat faux => un résultat avec une erreur supérieure à epsilon.

Par exemple euh je sais pas y'a plein de possibilités.

=> (a+b)+c == a+(b+c)
Attends-toi à des surprises si tu travailles sur des flottants ^^

=> (a + b - 1e0) / c
a = 1e0
b = 1e-42
c = 1e-42
Avec la bonne valeur pour 42, ce calcul sort 0, soit une erreur relative de 100%
(note que le /c ne sert à rien pour l'exemple, c'est juste pour éviter une réponse du style "oui mais 1e-42 c'est négligeable" par un des lecteurs du topic )

=> J'ai plus l'exemple en tête là mais en cours (vivi on a eu un cours sur les flottants en maths) la prof avait montré un exemple qui aboutissait à une erreur de 900%

Les additions de flottant, c'est un truc super casse-gueule. On a mis une Ariane au tapis à cause d'une erreur de flottant. Les missiles Patriot ont connu de nombreux problèmes liés à ce type d'erreur, dont un accident ayant tué 26 personnes. On ne reparlera plus évidemment de la fameuse imprécision de l'instruction FDIV du pentium, dont la cause a été remontée aux additions réalisées en interne. Ou encore la plateforme de pétrole Sleipner qui a coulé suite à une erreur de calcul de plus 47% dans le calcul des contraintes à sa conception.

Tiens juste une question....dans un programme à contexte mathématique, comment tu comparerais 2 flottants ?

spectras :
L'erreur sur des flottants, ça se compte pas en bits hein . Je te rappelle que t'as un exposant devant, et pourvu que tu additionnes avec des grandeurs différentes, ton bit d'erreur se trouve multiplié par beaucoup.

Mais loul quoi ! En parlant d'"erreur d'un bit de poids faible", je voulais dire "erreur d'un bit de poids faible de la mantisse, à exposant égal", me prend pas pour un con...

Par exemple euh je sais pas y'a plein de possibilités.

=> (a+b)+c == a+(b+c) Attends-toi à des surprises si tu travailles sur des flottants ^^

Mais loul quoi ! Bien sûr que l'addition de flottants n'est pas associative, mais ça ne veut pas dire pour autant qu'elle fait n'importe quoi... (et heureusement, d'ailleurs)
Et, ô surprise, avec des entiers, a+c > b+c n'est pas équivalent à a > b ! Mon dieu, il faut arrêter tout de suite de les utiliser !

=> J'ai plus l'exemple en tête là mais en cours (vivi on a eu un cours sur les flottants en maths) la prof avait montré un exemple qui aboutissait à une erreur de 900%

Bien sûr, je ne parle pas d'une borne magique qui ferait qu'une suite d'opérations arbitraires sur des flottants aurait une erreur bornée... Je parle d'une borne non-magique, parfaitement spécifiée, qui porte sur *une* opération. En l'occurrence, pour une addition a+b, l'erreur peut être bornée par exemple par le max d'un bit de poids faible de chacun des nombres. Pour ton exemple, a=1e0, donc si tu as dix chiffres significatifs, ce max est 1e-10 : (a + b) - 1e0 calculé en flottant vaut "a + b - 1e0 en réels" à 2e-10 près, donc quand tu le divises par c, tu as une garantie que le calcul est correct à 2e32 près Bref, le fait d'avoir une spécification claire pour le comportement de l'addition t'aurais permis de voir qu'effectivement, tu ne peux tirer aucune conclusion intéressante de ce calcul. De même, cette spécification claire peut te garantir que tel autre calcul te donnera, lui, des conclusions correctes... (et c'est tout l'intérêt de la chose)

Les additions de flottant, c'est un truc super casse-gueule.

Oui, mais ça ne veut pas dire que c'est la fête du slip non plus... (sinon on ne les utiliserait pas dans l'industrie, surtout quand des fusées ou des avions coûtant des millions de dollars sont en jeu)

On a mis une Ariane au tapis à cause d'une erreur de flottant.

C'est inexact voire faux : c'est un débordement d'un compteur inutilisé, qui a lancé une exception non rattrapée. Ca n'a rien d'une erreur d'arrondi, et ça serait également arrivé si le compteur en question avait été un entier...

Les missiles Patriot ont connu de nombreux problèmes liés à ce type d'erreur, dont un accident ayant tué 26 personnes.

Je ne connais pas les détails.

On ne reparlera plus évidemment de la fameuse imprécision de l'instruction FDIV du pentium, dont la cause a été remontée aux additions réalisées en interne.

Oui, mais j'aurais plutôt tendance à dire que c'est bien la preuve qu'une division précise au bit près est d'une importance significative ^^ (de même que, je sais pas, le fait que Windows ait une faille de sécurité exploitée et qu'on en parle beaucoup n'est pas la preuve que la sécurité, c'est mal ou c'est illusoire, mais plutôt que la sécurité, c'est important)

Tiens juste une question....dans un programme à contexte mathématique, comment tu comparerais 2 flottants ?

Muf ? Ca veut dire quoi ?

Mais loul quoi ! En parlant d'"erreur d'un bit de poids faible", je voulais dire "erreur d'un bit de poids faible de la mantisse, à exposant égal", me prend pas pour un con...

Bah oué mais il fallait préviser le à exposant égal. Et puis si tout tes calculs ont un exposant égal, tu peux utiliser des entiers hein ça sera pas plus compliqué.

Bien sûr, je ne parle pas d'une borne magique qui ferait qu'une suite d'opérations arbitraires sur des flottants aurait une erreur bornée... Je parle d'une borne non-magique, parfaitement spécifiée, qui porte sur *une* opération.

Oui, mais l'exemple portait sur un calcul simple, du même genre que celui que j'ai mis.

En l'occurrence, pour une addition a+b, [...] [...]De même, cette spécification claire peut te garantir que tel autre calcul te donnera, lui, des conclusions correctes... (et c'est tout l'intérêt de la chose)

A ceci justement que là le problème est évident parce que je l'ai isolé. Mais c'est un problème qui rode dans n'importe quel calcul en flottant, et qui sera pas aussi évident. Comment peux-tu avoir la garantie de ne jamais tomber sur le cas qui foire ? Comment peux-tu avoir la garantie que telle fonction que tu appelles, par exemple une TF ou le calcul d'une intégrale ne vas jamais tomber sur un cas qui merde ? Ou la résolution d'une équadiff ?
La réponse est : on ne sait pas prévoir ce genre de choses à l'avance dès que les calculs ne sont pas triviaux.

C'est inexact voire faux : c'est un débordement d'un compteur inutilisé, qui a lancé une exception non rattrapée. Ca n'a rien d'une erreur d'arrondi, et ça serait également arrivé si le compteur en question avait été un entier...

L'erreur d'origine était provoqué par une conversion d'un flottant en entier. C'est cette conversion qui a débordé, parce que le flottant en question a pris des valeurs non prévues, liées à des mesures donnant des valeurs différentes des versions précédentes.

Tiens juste une question....dans un programme à contexte mathématique, comment tu comparerais 2 flottants ?

Muf ? Ca veut dire quoi ?

Je sais pas moi, comment tu implémenterais par exemple ...euh le calcul d'une racine carrée ?


Mais c'est pas contre les flottants en général que j'en ai. Uniquement contre les additions et soustractions, sources de tous les problèmes potentiels. Le simple fait d'écrire "a = b - c" est déjà un bug latent selon les valeurs que b et c peuvent prendre.

spectras
:

Mais loul quoi ! En parlant d'"erreur d'un bit de poids faible", je voulais dire "erreur d'un bit de poids faible de la mantisse, à exposant égal", me prend pas pour un con...

Bah oué mais il fallait préviser le à exposant égal. Et puis si tout tes calculs ont un exposant égal, tu peux utiliser des entiers hein ça sera pas plus compliqué.

Quand je dis "une erreur d'un bit de poids faible sur le flottant x = 1.mmmmm*10^e", je veux dire que l'erreur est bornée *pour le flottant x et son exposant e* par 0.00001*10^e, mais évidemment si j'ai un flottant y dire "j'ai fait une erreur d'un bit de poids faible sur y" ne va pas donner la même amplitude d'erreur, c'est une évidence ^^ (donc rien à avoir avec de la virgule fixe)

Pour illustrer ce que j'ai dit, tu peux considérer que l'addition flottante de x et de y est le réel x'+y' où x' et y' réels valent x et y modulo une erreur de moins d'un bit de poids faible ^^ (enfin c'est une sur-approximation, en pratique IEEE 754 est nettement plus précis, au point même d'être déterministe)

Bien sûr, je ne parle pas d'une borne magique qui ferait qu'une suite d'opérations arbitraires sur des flottants aurait une erreur bornée... Je parle d'une borne non-magique, parfaitement spécifiée, qui porte sur *une* opération.

Oui, mais l'exemple portait sur un calcul simple, du même genre que celui que j'ai mis.

Bah à la limite même pour ton exemple qui est un "calcul simple", on peut trouver des bornes, mais elles ne font que souligner que ton calcul pose des problèmes de précision. La fonction f : (a,b,c) -> (a+b)+c (en flottant) et la fonction g : a+(b+c) (en flottant) ne diffèrent toutes les deux de h : (a,b,c) -> a+b+c (en réel) que par une fonction bornée par epsilon*(|a|+|b|+|c|)... Donc si tu as a = -b = 10^42 et c = 1, la borne est de l'ordre de 10^42, donc tu ne peux pas conclure grand-chose si tu trouves un résultat de 0 ou de 1...

En l'occurrence, pour une addition a+b, [...] [...]De même, cette spécification claire peut te garantir que tel autre calcul te donnera, lui, des conclusions correctes... (et c'est tout l'intérêt de la chose)

A ceci justement que là le problème est évident parce que je l'ai isolé. Mais c'est un problème qui rode dans n'importe quel calcul en flottant, et qui sera pas aussi évident. Comment peux-tu avoir la garantie de ne jamais tomber sur le cas qui foire ? Comment peux-tu avoir la garantie que telle fonction que tu appelles, par exemple une TF ou le calcul d'une intégrale ne vas jamais tomber sur un cas qui merde ? Ou la résolution d'une équadiff ?

En faisant attention, et en connaissant les garanties offertes par IEEE. Pour faciliter la tâche, IEEE garantit justement beaucoup de choses. Si ce n'était pas le cas et qu'on écoutait tes recommandations "aucune fonction flottante ne doit suivre de spec précise", effectivement ce serait nettement plus difficile.

La réponse est : on ne sait pas prévoir ce genre de choses à l'avance dès que les calculs ne sont pas triviaux.

Non, la réponse est : on peut le prévoir, mais c'est difficile. De même qu'éviter les buffer overflow en C, c'est difficile. D'ailleurs dans les deux cas on sait faire des analyses statiques du code pour prouver l'absence de buffer overflow ou la précision d'un calcul flottant... (mais dans les deux cas, ça reste très délicat à faire, et ce n'est pas complètement automatisé)

C'est inexact voire faux : c'est un débordement d'un compteur inutilisé, qui a lancé une exception non rattrapée. Ca n'a rien d'une erreur d'arrondi, et ça serait également arrivé si le compteur en question avait été un entier...

L'erreur d'origine était provoqué par une conversion d'un flottant en entier. C'est cette conversion qui a débordé, parce que le flottant en question a pris des valeurs non prévues, liées à des mesures donnant des valeurs différentes des versions précédentes.

Oui, mais ce n'est pas une question d'arrondi : c'est tout simplement la valeur qui était trop grande pour tenir dans un entier. Si on avait calculé avec des Vrais Réels (tm), il y aurait eu exactement le même problème. Et si on avait calculé avec des entiers parce que la valeur était entière, on aurait eu aussi le même problème.
(pour être plus concret :

  static double x = 0;
  for (;!fusée_en_orbite();)
    x += 1;

  static true_real x = 0;
  for (;!fusée_en_orbite();)
    x += 1, do_stuff_with((int)x);

  static int x = 0;
  for (;!fusée_en_orbite();)
    x += 1;

vont tous finir par déborder, ce n'est pas un argument pour ou contre les flottants)

Je sais pas moi, comment tu implémenterais par exemple ...euh le calcul d'une racine carrée ?

Tu veux l'implémenter par dichotomie ? Ben, comme avec des entiers, non ?

double sqrt(double x) {
  if (x>=1 && x<4) {
    double s = 1, bit = 0.5;
    while (s+bit != bit) {
      double t = s+bit;
      if (t*t >= x)
        s = t;
      bit *= 0.5;
    }
    return s;
  } else if (x<1)
    return sqrt(4*x)*0.5;
  else
    return sqrt(0.25*x)*2;
}

(disclaimer : pas testé)

Mais c'est pas contre les flottants en général que j'en ai. Uniquement contre les additions et soustractions, sources de tous les problèmes potentiels. Le simple fait d'écrire "a = b - c" est déjà un bug latent selon les valeurs que b et c peuvent prendre.

Ben oui, c'est un bug latent si on ne fait pas gaffe, mais c'est tellement indispensable qu'on est bien obligé de s'en servir... (et de faire gaffe)
Et le débat initial n'était pas vraiment "est-ce que les flottants c'est bien", mais plutôt "est-ce que c'est propre de dépendre de normes style IEEE sur les flottants pour s'assurer une précision suffisante ou encore la convergence numérique ?". A cette question je réponds oui, parce que justement comme tu le dis c'est déjà assez difficile comme ça de travailler avec des flottants, si en plus on doit supposer que le processeur peut faire comme il veut et rajouter une erreur non-déterministe de 3e-5 à chaque addition on est pas sorti de l'auberge...

Pollux :
(à moins d'utiliser uniquement de l'arithmétique entière )

Ton "" est largement déplacé, tu serais surpris de savoir le nombre d'engins embarqués (que ce soit dans les télécoms, l'aéronautique, etc) qui travaillent en virgule fixe.

Pollux :
C'est d'autant plus crucial que, même si la précision n'est pas toujours primordiale quand tu n'as pas de boucles ou de feedback, une erreur d'un bit de poids faible cumulée sur plein d'itérations risque bien de devenir gigantesque (divergence).

C'est à ça que servent les tests unitaires...

spectras :
On a mis une Ariane au tapis à cause d'une erreur de flottant.

... qui avaient été justement ômis lors du portage du code incriminé pour Ariane V.

Ximoon
:

Pollux :
(à moins d'utiliser uniquement de l'arithmétique entière )

Ton "" est largement déplacé, tu serais surpris de savoir le nombre d'engins embarqués (que ce soit dans les télécoms, l'aéronautique, etc) qui travaillent en virgule fixe.

Oui, mon "" voulait dire qu'utiliser uniquement l'arithmétique entière était le seul moyen pour un algorithme flottant d'être "indépendant" de la précision des nombres (mais à ce moment-là il n'est plus du tout flottant, d'où le smiley), pas que l'arithmétique entière n'était pas suffisante...

Pollux :
C'est d'autant plus crucial que, même si la précision n'est pas toujours primordiale quand tu n'as pas de boucles ou de feedback, une erreur d'un bit de poids faible cumulée sur plein d'itérations risque bien de devenir gigantesque (divergence).

C'est à ça que servent les tests unitaires...

Moui, enfin quand des vies sont en danger on peut avoir envie de garanties un peu plus probantes que ça ^^ (par exemple comme dit plus haut par analyse statique)

Oui, les analyses statiques sont obligatoires dans l'aéronautique, et tu dois avoir un code entièrement validé et certifié (même les outils de tests doivent l'être ) avant d'avoir l'autorisation de faire voler un avion. Mais ces mêmes tests n'ont (pour autant que je sache) pas été appliqués à la fameuse Ariane V.

Apparemment si, mais seulement après le fameux accident :

http://en.wikipedia.org/wiki/Ariane_5_Flight_501#Aftermath : The subsequent automated analysis of the Ariane code was the first example of large-scale static analysis by abstract interpretation.

Ouais mais c'était un peu tard pour le coup (sauf pour les suivantes s'entend )