Quoi?! tous les réels dans seulement 8bits?
Salut à tous!
Un truc m'échappe sur le fonctionnement de la mémoire, pour faire court et pas vous ennuyer je vais juste donner un exemple.
Pour déclarer des réels en JAVA, on utilise le type double, correspondant à 8bits dans la RAM.
Pourtant y a une infinité d'éléments dans l'ensemble des réels, n'est-ce pas?
Alors Comment ces 8bits arrivent-ils à contenir cette infinité?
je remercie d'avance ceux qui prendront la peine de m'expliquer ^^'
Cordialement!
Bonjour,
les doubles sont codés sur 8 Octets soit 64 bits ce n'est pas une représentation des réels juste une toute petite classe de fractionnaires, l'erreur absloue est de croire que ce sont tous les réels. Attention la commutativité n'est pas assurée!
lien incontournable :http://docs.oracle.com/cd/E19957-01/..._goldberg.html
JR
Dernière modification par jiherve ; 25/05/2013 à 11h57.
l'électronique c'est pas du vaudou!
Bonjour,
Ce n'est pas 8 bits, mais 8 octets, soit 64 bits.
Mais le problème est le même : il est clair qu'on ne représente pas TOUS les réels, en fait, seule une petite partie est représentable (de tout manière, quoi que l'on fasse, il est impossible de représenter une infinité de données).
De fait, il y a de très nombreux "trous" dans la représentation des réels, c'est pourquoi les calculs sont toujours approximatifs, et que le résultat dépendra de l'ordre des opérations, puisque les erreurs sont faites à chaque calcul élémentaire.
Oups, croisé avec jiherve
Bonjour,
J'ajouterai un mot : c'est la raison pour laquelle il ne faut pas (sauf cas particulier) comparer des réels avec le signe "=" ou "==" ou "!=", mais avec un truc du genre abs(A-B) < epsilon.
La valeur epsilon étant une valeur petite, par exemple 1.E-15.
Bonjour,
Pour les pros The pitfalls of verifying floating-point computations (David Monniaux).
@+
Not only is it not right, it's not even wrong!
Bonjour,
Il ne faut pas comparer à une valeur absolue, mais à une valeur relative.Envoyé par Dlzlogic
Par exemple, si on compare Epsilon = 10-15 à des données de l'ordre de 1020, alors notre Epsilon est trop petit, car ça fait une dynamique de 35 chiffres significatifs, alors que le type double n'en fait que 15 à 17 ...
Pour reprendre les données de l'ordre de 1020, il faudrait utiliser un Epsilon de l'ordre de 1020/1015 = 105.
C'est un truc que j'ai souvent vu être complétement ignoré, même par des pros dits "confirmés".
Oui, tu as tout à fait raison.
La valeur 1.E-15 n'était qu'un simple exemple. Dans le cas de mon programme de CAO-DAO, l'epsilon est de l'ordre de 1.E-3.
Dans le cas de test, type "erreur", c'est 1.E-50.
Ce que j'ai voulu dire c'est simplement qu'une comparaison à 0 (zéro) est toujours à éviter.
Il est vrai que la comparaison à une valeur absolue ou à une valeur relative peut être un choix suivant les cas.
Cependant, dans certains contextes, les essais de comparaison à une valeur relative se sont révélés catastrophiques.
Je ne crois pas qu'il y ait de méthode "tout terrain" chaque cas a ses spécificités.
Bonne soirée.
Bonjour,
J'avais précisé, car comme la réponse s'adresse à un débutant, il faut éviter d'être affirmatif avec une valeur précise, alors qu'elle ne doit pas l'être.
Il est vrai que tous ces tests peuvent poser des problèmes, et qu'il faut réfléchir aux calculs faits, pour savoir où on va.
Le problème est évidemment "il faut réfléchir aux calculs faits, pour savoir où on va", beaucoup trop de programmeurs étant fréquemment largués dès qu'il s'agit d'ordres de grandeur, quel que soit le domaine d'application.
