 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
none
Guest
|
 Posted: Sun Mar 19, 2006 6:06 pm Post subject: problème de flottant |
 |
|
Je dois travailler avec des flottants pour tracer l'axe d'un repère.
J'ai une routine qui renvoie un pixel en fonction de coordonnées
flottantes (des double).
Maintenant, je dois dessiner un tiret de, disons -1.0 jusqu'à 1.0 tous
les 0.1, donc -1.0, -0.9, ..., 0.0, ..., 1.0
Apparemment, partir de -1.0 et ajouter 0.1 à chaque pas, ça ne
fonctionne visiblement pas. Pour le tiret du milieu, quand je compare ma
valeur à 0.0, ça me renvoie faux :/ Alors que pourtant, je n'ai fait
qu'incrémenter ma valeur de 0.1.
Je pense que c'est un problème récurrent mais j'ai vraiment du mal à
comprendre.
Comment faire proprement pour avoir -1.0, -0.9, etc .. ? |
|
| Back to top |
|
 |
Cyrille
Guest
|
| Posted: Sun Mar 19, 2006 7:06 pm Post subject: Re: problème de flottant |
|
|
none none a écrit :
| Quote: | Je dois travailler avec des flottants pour tracer l'axe d'un repère.
J'ai une routine qui renvoie un pixel en fonction de coordonnées
flottantes (des double).
Maintenant, je dois dessiner un tiret de, disons -1.0 jusqu'à 1.0 tous
les 0.1, donc -1.0, -0.9, ..., 0.0, ..., 1.0
Apparemment, partir de -1.0 et ajouter 0.1 à chaque pas, ça ne
fonctionne visiblement pas. Pour le tiret du milieu, quand je compare ma
valeur à 0.0, ça me renvoie faux :/ Alors que pourtant, je n'ai fait
qu'incrémenter ma valeur de 0.1.
Je pense que c'est un problème récurrent mais j'ai vraiment du mal à
comprendre.
|
Toute représentation classique des flottants entraîne des imprécisions.
Quand on additionne des flottants, les imprécisions s'additionnent
également. Après avoir ajouté dix fois 0.1 à -1., tu n'as plus vraiment
0. et c'est normal (mais normalement tu dois avoir quelque chose de très
proche, surtout que tu utilises des double).
| Quote: | Comment faire proprement pour avoir -1.0, -0.9, etc .. ?
|
// de -1 à 1 par pas de 0.1
for ( int i = -10; i <= 10; i++ )
{
double d = i * 0.1;
// dessiner ce qui correspond à d...
}
L'idée étant de calculer le plus souvent possible avec des entiers, dont
la précision est parfaite, et de passer aux flottants seulement quand
c'est nécessaire. Quand c'est un problème simple de discrétisation comme
ici c'est facile.
Sinon, quand tu compares des flottants, tu peux intégrer une certaine
marge d'erreur. Ainsi tu remplaces
x == y
par
std::abs( x - y ) < epsilon
Avec epsilon une constante que tu as défini à l'avance.
Si ça ne te convient toujours pas, cherche sur Google
"arbitrary-precision float", mais c'est vraiment pour des besoins exigeants.
--
If you want to get anything done in this country you've go to complain
till you're blue in the mouth. |
|
| Back to top |
|
|
Jean-Marc Bourguet
Guest
|
|
| Back to top |
|
|
Sylvain
Guest
|
| Posted: Sun Mar 19, 2006 7:06 pm Post subject: Re: problème de flottant |
|
|
none none wrote on 19/03/2006 18:46:
| Quote: | Je dois travailler avec des flottants pour tracer l'axe d'un repère.
J'ai une routine qui renvoie un pixel en fonction de coordonnées
flottantes (des double).
Maintenant, je dois dessiner un tiret de, disons -1.0 jusqu'à 1.0 tous
les 0.1, donc -1.0, -0.9, ..., 0.0, ..., 1.0
Apparemment, partir de -1.0 et ajouter 0.1 à chaque pas, ça ne
fonctionne visiblement pas. Pour le tiret du milieu, quand je compare ma
valeur à 0.0, ça me renvoie faux :/ Alors que pourtant, je n'ai fait
qu'incrémenter ma valeur de 0.1.
Je pense que c'est un problème récurrent mais j'ai vraiment du mal à
comprendre.
Comment faire proprement pour avoir -1.0, -0.9, etc .. ?
|
un flottant est nécessairement une valeur définie + ou - sa précision,
et cette précision dépend de la taille alloué au type; historiquement le
type float a la taille des registres du CPU/CoPro, le type double le
double; sur ces n bits de stockage sont codés le signe, l'exposant et la
mantisse (la valeur décimale compris entre 0 et 0.99999999..).
chaque opération flottante génère une incertitude relative sur le
résultat (tel qu'on nous l'apprenait en TP de chimie par exemple); donc
tous tests stricts est voué à l'échec et doit plutôt être codé en
comparant l'écart entre la valeur courante et la valeur supposé d'une
part et la précision du type utilisé d'autre part.
concrétement:
ne pas coder if (f == 1.0) {}
mais if (fabs(f - 1.0) < 1e- {}
ce type de codage est indispensable lors que vous n'avez pas d'autre
choix que d'utiliser des flottants (et que des flottants); partout ou
cela n'est pas indispensable on réalisera les opérations en entiers et
on convertit (ou seulement exprime) en flottants au dernier moment.
dans votre cas, vous devriez coder:
for (tick = -10; tick <= 10; ++tick){
// calcul des coord. en entiers (les pixels sont des entiers)
// évaluation d'un libellé comme "tick / 10.0"
}
Sylvain. |
|
| Back to top |
|
|
Arnaud Meurgues
Guest
|
| Posted: Sun Mar 19, 2006 7:06 pm Post subject: Re: problème de flottant |
|
|
none none wrote:
| Quote: | Apparemment, partir de -1.0 et ajouter 0.1 à chaque pas, ça ne
fonctionne visiblement pas. Pour le tiret du milieu, quand je compare ma
valeur à 0.0, ça me renvoie faux :/ Alors que pourtant, je n'ai fait
qu'incrémenter ma valeur de 0.1.
|
Benvenue dans le monde des flottants.
En informatique, la représentation des nombre rationnels (et
irrationnels) n'est pas exacte. Certaines valeurs ne sont simplement pas
représentable.
Pour simplifier, supposons qu'un nombre flottant entre 0 et 1 (interval
[0,1[) soit représenté sur 3 bits représentant les puissances négatives
de 2.
Ainsi :
000 = 0
001 = 0*2^(-1) + 0*2^(-2) + 1*2^(-3) = 0*0,5 + 0*0,25 + 1*0,125 = 0,125
010 = 0,25
011 = 0,375
100 = 0,5
101 = 0,625
110 = 0,75
111 = 0,875
Avec une telle représentation, si l'on écrit
float x = 0.5
on a bien une représentation exacte.
Mais si l'on écrit
float x = 0.1
la valeur représentée sera en fait 0,125 (ou 0, selon la manière dont
est converti un nombre non représentable en nombre représentable).
De la même manière, les additions entre flottants seront empruntes de la
même inexactitude.
Ainsi, si vous décrémentez de 0,5 jusqu'à 0 par pas de 0,1, vous risquez
(dans cet exemple) d'arriver à 0 en 4 étapes car les pas seraient en
fait de 0,125.
L'on peut aussi, lorsque la précision supérieur au pas (prenez un pas de
0,3, par exemple) "rater" le 0 et n'avoir donc jamais exactement le 0.
Travailler sur des flottants est un exercice extrêmement délicat en
informatique, et il vaut mieux s'en abstenir si l'on n'a pas une
conscience aigüe de tous ces problèmes (et en avoir conscience ne suffit
d'ailleurs pas).
Dans votre cas, il serait plus prudent, par exemple, de tout multiplier
par 10 et de travailler avec des entiers.
| Quote: | Comment faire proprement pour avoir -1.0, -0.9, etc .. ?
|
Avec des flottant, on ne peut pas...
--
Arnaud |
|
| Back to top |
|
|
none
Guest
|
| Posted: Sun Mar 19, 2006 8:06 pm Post subject: Re: problème de flottant |
|
|
Arnaud Meurgues a écrit :
| Quote: | Comment faire proprement pour avoir -1.0, -0.9, etc .. ?
Avec des flottant, on ne peut pas...
|
Merci à tous pour ces réponses rapides. Je vais travailler le plus
possible avec des entiers. |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Mon Mar 20, 2006 11:06 am Post subject: Re: problème de flottant |
|
|
Sylvain wrote:
| Quote: | none none wrote on 19/03/2006 18:46:
Je dois travailler avec des flottants pour tracer l'axe d'un
repère. J'ai une routine qui renvoie un pixel en fonction de
coordonnées flottantes (des double).
Maintenant, je dois dessiner un tiret de, disons -1.0
jusqu'à 1.0 tous les 0.1, donc -1.0, -0.9, ..., 0.0, ...,
1.0
Apparemment, partir de -1.0 et ajouter 0.1 à chaque pas, ça
ne fonctionne visiblement pas. Pour le tiret du milieu,
quand je compare ma valeur à 0.0, ça me renvoie faux :/
Alors que pourtant, je n'ai fait qu'incrémenter ma valeur de
0.1.
Je pense que c'est un problème récurrent mais j'ai vraiment
du mal à comprendre.
Comment faire proprement pour avoir -1.0, -0.9, etc .. ?
un flottant est nécessairement une valeur définie + ou - sa
précision,
|
Strictement parlant... Un flottant a une valeur précise ; il n'y
a pas de + ou -. Pour des raisons évidentes (représentation
finie), les flottants ne peuvent pas représenter tous les réels
(ni toutes les rationnelles) ; malheureusement pour none none,
0.1 est une des valeurs qu'ils ne peuvent pas représenter. Ce
qui fait qu'il n'ajoute pas 0.1 à chaque passage dans la boucle,
mais quelque chose de proche.
| Quote: | et cette précision dépend de la taille alloué au type;
historiquement le type float a la taille des registres du
CPU/CoPro, le type double le double; sur ces n bits de
stockage sont codés le signe, l'exposant et la mantisse (la
valeur décimale compris entre 0 et 0.99999999..).
|
Ça dépend des formats, mais en IEEE (le format le plus répandu
aujourd'hui), la valeur décimale de la mantisse s'étend de 0.5 à
1.0-epsilon (ou epsilon est 2^-53, je crois). Il y a aussi des
valeurs spéciales, identifiées par une valeur spéciale dans
l'exposant -- 0.0 est sans doute celle qu'on rencontre la plus
souvent.
| Quote: | chaque opération flottante génère une incertitude relative sur
le résultat (tel qu'on nous l'apprenait en TP de chimie par
exemple);
|
Là aussi, ça dépend du point de vue. La valeur du résultat est
bien définie. Seulement, dans certains cas, elle sera différente
de celle du résultat de l'opération sur les réels. Mais
attention : dans son cas, ça ne serait pas souvent le cas. Et
statistiquement, souvent, ces différences s'anullera. Son
véritable problème, c'est que la valeur qu'il ajoute n'est pas
ce qu'il veut.
| Quote: | donc tous tests stricts est voué à l'échec et doit plutôt être
codé en comparant l'écart entre la valeur courante et la
valeur supposé d'une part et la précision du type utilisé
d'autre part.
|
Ça dépend de l'application ; souvent, les valeurs en entrée sont
déjà des approximations, et c'est tout à fait normal de prendre
en compte des epsilons quand on cherche une valeur précises --
en fait, ce qu'on veut, au niveau de l'application, c'est déjà
x+/-epsilon (avec un epsilon qui dépend de l'application).
Mais ce n'est pas une règle générale ; ça dépend de
l'application. Et il faut bien ne pas oublier que si on définit
un isEqual() approximatif, alors isEqual(a,b) && isEqual(b,c)
n'implique plut isEqual(a,c) -- ce qui peut faire échouer
certaines algorithmes.
Il y a pire, évidemment, et certains algorithmes, pour certaines
valeurs (qui n'apparaîtront pas dans vos tests, évidemment)
peuvent ne pas converger avec les opérations sur des flottants,
alors qu'ils convergeront bien avec les mêmes opérations sur des
réels.
La question est assez complexe et ne se prete pas à une réponse
simple dans le news -- le mieux, c'est de googler pour « what
every computer scientist should know about floating point
arithmetic », et lire l'article (de David Goldberg) avec
attention. (C'est disponible à beaucoup d'endroits sur la
toile.)
| Quote: | concrétement:
ne pas coder if (f == 1.0) {}
mais if (fabs(f - 1.0) < 1e- {}
|
Si tu sais que dans ton application, la précision des valeurs
est de l'ordre 1e-8. Dans les rares cas où je me sers des
flottants, je m'arrange pour que les valeurs soient toujours
exactes. En revanche, dans une application où je traiterais des
valeurs lues des instruments de mésure électronique, la
précision serait plutôt de l'ordre 1e-2 ou 1e-3 -- les
instruments ne peuvent pas me donner de plus, de toute façon.
C'est le genre de règle naïve qui donne l'air de marcher,
parfois, mais donne aussi des résultats trompeurs dans d'autres
cas.
| Quote: | ce type de codage est indispensable lors que vous n'avez pas
d'autre choix que d'utiliser des flottants (et que des
flottants); partout ou cela n'est pas indispensable on
réalisera les opérations en entiers et on convertit (ou
seulement exprime) en flottants au dernier moment.
|
Ça, en revanche, c'est un conseil excellent. Moins on fait avec
les flottants, moins on risque de se faire avoir (et moins
l'analyse de la correction de ce qu'on a fait est simple).
| Quote: | dans votre cas, vous devriez coder:
for (tick = -10; tick <= 10; ++tick){
// calcul des coord. en entiers (les pixels sont des entiers)
// évaluation d'un libellé comme "tick / 10.0"
}
|
C'est certainement la solution dans son cas. Au moins qu'il
n'affiche 17 décimaux ou plus, il verra les valeurs auxquelles
il s'attend.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
Sylvain
Guest
|
| Posted: Tue Mar 21, 2006 12:06 am Post subject: Re: problème de flottant |
|
|
kanze wrote on 20/03/2006 11:41:
1- tu as le droit de quoter correctement (et donc ne pas laisser des
blocs entiers sans aucun rapport avec ce que tu développes)
2- puisque apparemment ce que tu aimes développer le plus est l'art de
la contradiction (ni systématiquement intéressante, ni spécialement en
charte), je me sens obligé d'indiquer que ce "bizutage" me laisse de glace.
| Quote: | un flottant est nécessairement une valeur définie + ou - sa
précision,
Strictement parlant... Un flottant a une valeur précise ; il n'y
a pas de + ou -. Pour des raisons évidentes (représentation
finie), les flottants ne peuvent pas représenter tous les réels
(ni toutes les rationnelles)
|
donc "strictement parlant", je te laisserais maintenant monologuer ce
type de platitude.
| Quote: | 0.1 est une des valeurs qu'ils ne peuvent pas représenter.
|
et t'as décréter ça tout seul sans même connaître la précision de son
type double !! ben tu vois un Cray tout bête se représente parfaitement 0.1
| Quote: | qui fait qu'il n'ajoute pas 0.1 à chaque passage dans la boucle,
mais quelque chose de proche.
|
tu expliques ça à qui ???????? 4 personnes l'ont déjà dit.
| Quote: | Ça dépend des formats, mais en IEEE (le format le plus répandu
aujourd'hui), la valeur décimale de la mantisse s'étend de 0.5 à
1.0-epsilon (ou epsilon est 2^-53, je crois).
|
la valeur absolue de la mantisse est toujours comprise entre 1 et la
base de dénombrement (le premier bit étant caché car toujours
prédictible, cette mantisse se ramène en base 10 à une quasi partie
fractionnaire pure (un nombre décimale sans partie entière)
tout ceci étant hors chartre, google IEEE.
| Quote: | Il y a aussi des valeurs spéciales, identifiées par une valeur
spéciale dans l'exposant -- 0.0 est sans doute celle qu'on
rencontre la plus souvent.
|
de l'exposant *et* de la mantisse.
soit il y a le nombre zero (E = 0; F = 0; S = 1)
tu as juste oublié:
-0 (E = 0; F = 0; S = 1)
-Infinity
Infinity
NaN
| Quote: | Là aussi, ça dépend du point de vue. La valeur du résultat est
bien définie.
|
on va dire ça; tabl[4325] est "indéfini" mais savoir comment le dernier
bit d'un flottant est arrondi par tous les unités flottantes de tous les
fondeurs est "définie" .. "selon le point de vue de James".
| Quote: | Seulement, dans certains cas, elle sera différente
de celle du résultat de l'opération sur les réels. Mais
|
c'est quoi "réels", c'est pas dans IEEE 754 ni dans IEEE 854.
| Quote: | attention : dans son cas, ça ne serait pas souvent le cas.
|
c'est cela, "pas souvent" j'vous dis, et même, à vue de nez, pas toujours.
| Quote: | Et statistiquement, souvent, ces différences s'anullera.
|
grotesque.
| Quote: | Son véritable problème, c'est que la valeur qu'il ajoute n'est
pas ce qu'il veut.
|
12ième porte ouverte, merci quand même.
| Quote: | Ça dépend de l'application ; souvent, les valeurs en entrée sont
déjà des approximations, et c'est tout à fait normal de prendre
en compte des epsilons quand on cherche une valeur précises --
en fait, ce qu'on veut, au niveau de l'application, c'est déjà
x+/-epsilon (avec un epsilon qui dépend de l'application).
|
ça a un rapport avec la question, le fil, la chartre ???
ou c'est juste une envolée de plus ?
| Quote: | Mais ce n'est pas une règle générale ; ça dépend de
l'application. Et il faut bien ne pas oublier que si on définit
un isEqual() approximatif, alors isEqual(a,b) && isEqual(b,c)
n'implique plut isEqual(a,c) -- ce qui peut faire échouer
certaines algorithmes.
|
oui, seulement si tu ne sais pas coder ton isEqual.
| Quote: | Il y a pire, évidemment, et certains algorithmes, pour certaines
valeurs (qui n'apparaîtront pas dans vos tests, évidemment)
peuvent ne pas converger avec les opérations sur des flottants,
alors qu'ils convergeront bien avec les mêmes opérations sur des
réels.
|
si "réel" voulait signifier "précision arbitraire" (via une librarie
es-spéciale et non une simple unité de calcul flottant) c'est faux
également.
| Quote: | concrétement:
ne pas coder if (f == 1.0) {}
mais if (fabs(f - 1.0) < 1e- {}
Si tu sais que dans ton application, la précision des valeurs
est de l'ordre 1e-8.
|
?!?? non, si tu sais que tu utilises des float (32bits), on utilisera
1e-12 avec des doubles et 1e-14 avec des long doubles.
| Quote: | Dans les rares cas où je me sers des flottants,
je m'arrange pour que les valeurs soient toujours
exactes.
|
c'est pas du n'importe quoi là ??, tu as répété après tout le monde que
tous les nombres flottants ne pouvaient pas avoir une représentation
exacte de leur valeur, mais toi, abracadabra, tu t'"arranges" avec eux
et hop "c'est exact"; tiens codes donc exactement 7/5
| Quote: | En revanche, dans une application où je traiterais des
valeurs lues des instruments de mésure électronique, la
précision serait plutôt de l'ordre 1e-2 ou 1e-3 -- les
instruments ne peuvent pas me donner de plus, de toute façon.
|
si, si, c'est vraiment du n'importe quoi. (pousse la porte d'un labo de
physique au moins une fois, tu verras c'est intéressant).
| Quote: | C'est le genre de règle naïve qui donne l'air de marcher,
parfois, mais donne aussi des résultats trompeurs dans d'autres
cas.
|
[disait Confusius]
| Quote: | Ça, en revanche, c'est un conseil excellent. [...]
|
?!? te sens pas non plus obliger de distribuer tes bons points.
| Quote: | C'est certainement la solution dans son cas. Au moins qu'il
n'affiche 17 décimaux ou plus, il verra les valeurs auxquelles
il s'attend.
|
ok, on t'expliquera un jour comment utiliser printf.
Sylvain. |
|
| Back to top |
|
|
Arnaud Meurgues
Guest
|
| Posted: Tue Mar 21, 2006 9:06 am Post subject: Re: problème de flottant |
|
|
Sylvain wrote:
| Quote: | 2- puisque apparemment ce que tu aimes développer le plus est l'art de
la contradiction (ni systématiquement intéressante, ni spécialement en
charte), je me sens obligé d'indiquer que ce "bizutage" me laisse de glace.
|
Je doute qu'il y ait quelque forme que ce soit de « bizutage ». Mais une
chose est sûre : votre ton à vous est extrèmement désagréable dans la
plupart de vos messages.
| Quote: | 0.1 est une des valeurs qu'ils ne peuvent pas représenter.
et t'as décréter ça tout seul sans même connaître la précision de son
type double !! ben tu vois un Cray tout bête se représente parfaitement 0.1
|
« un Cray tout bête », c'est déjà une expression étrange.
Par curiosité, quelle genre de représentation binaire des flottants
utilise ce Cray tout bête pour représenter 0.1 de manière exacte ?
| Quote: | tout ceci étant hors chartre, google IEEE.
|
Ce n'est pas plus hors charte que vos réponses dans le fil « pb
iwebbrowser2 ». Mais si ça vous amuse de développer l'incohérence en
plus du mépris...
| Quote: | Il y a aussi des valeurs spéciales, identifiées par une valeur
spéciale dans l'exposant -- 0.0 est sans doute celle qu'on rencontre
la plus souvent.
de l'exposant *et* de la mantisse.
|
Il n'a pas dit le contraire.
| Quote: | soit il y a le nombre zero (E = 0; F = 0; S = 1)
tu as juste oublié:
-0 (E = 0; F = 0; S = 1)
-Infinity
Infinity
NaN
|
Il dit que 0.0 est celle qu'on rencontre le plus souvent. Il n'a pas
fait un inventaire. bon, c'est sûr, il faut savoir lire pour s'en
apercevoir, ce que rage et mépris ne rendent pas facile.
| Quote: | Là aussi, ça dépend du point de vue. La valeur du résultat est
bien définie.
on va dire ça; tabl[4325] est "indéfini" mais savoir comment le dernier
bit d'un flottant est arrondi par tous les unités flottantes de tous les
fondeurs est "définie" .. "selon le point de vue de James".
|
Ne pourrait-ce pas être indiqué par numeric_limits<float>::round_style
(tiens, ça c'est en charte) ?
Du coup, ça n'est indéterminé que si numeric_limits<float>::round_style
renvoie round_indeterminate.
| Quote: | Mais ce n'est pas une règle générale ; ça dépend de
l'application. Et il faut bien ne pas oublier que si on définit
un isEqual() approximatif, alors isEqual(a,b) && isEqual(b,c)
n'implique plut isEqual(a,c) -- ce qui peut faire échouer
certaines algorithmes.
oui, seulement si tu ne sais pas coder ton isEqual.
|
Comment peut-on coder un isEqual approximatif (différent du =, donc) et
transitif ?
| Quote: | Il y a pire, évidemment, et certains algorithmes, pour certaines
valeurs (qui n'apparaîtront pas dans vos tests, évidemment)
peuvent ne pas converger avec les opérations sur des flottants,
alors qu'ils convergeront bien avec les mêmes opérations sur des
réels.
si "réel" voulait signifier "précision arbitraire" (via une librarie
es-spéciale et non une simple unité de calcul flottant) c'est faux
également.
|
Je pense qu'ici, réels signifie réels, mathématiquement parlant.
Selon vous, une suite qui converge avec des réels converge
obligatoirement avec des flottants ?
| Quote: | concrétement:
ne pas coder if (f == 1.0) {}
mais if (fabs(f - 1.0) < 1e- {}
Si tu sais que dans ton application, la précision des valeurs
est de l'ordre 1e-8.
?!?? non, si tu sais que tu utilises des float (32bits), on utilisera
1e-12 avec des doubles et 1e-14 avec des long doubles.
|
Et avec des floats ?
| Quote: | Dans les rares cas où je me sers des flottants, je m'arrange pour que
les valeurs soient toujours
exactes.
c'est pas du n'importe quoi là ??, tu as répété après tout le monde que
tous les nombres flottants ne pouvaient pas avoir une représentation
exacte de leur valeur, mais toi, abracadabra, tu t'"arranges" avec eux
et hop "c'est exact"; tiens codes donc exactement 7/5
|
Je suppose qu'il ne vous est pas venu à l'esprit qu'il pouvait
s'arranger pour n'avoir à utilier que des nombres représentables.
En tout cas, merci pour votre contribution aussi riche et aimable. C'est
un bonheur à voir.
--
Arnaud |
|
| Back to top |
|
|
Benoit SIBAUD
Guest
|
| Posted: Tue Mar 21, 2006 9:06 am Post subject: Re: problème de flottant |
|
|
| Quote: | (ni toutes les rationnelles) ; malheureusement pour none none,
0.1 est une des valeurs qu'ils ne peuvent pas représenter. Ce
qui fait qu'il n'ajoute pas 0.1 à chaque passage dans la boucle,
mais quelque chose de proche.
|
Codage en binaire (IEEE float 32 bits, double 64 bits, long double 80
bits), prenons le cas des float par exemple :
- 1.0 = (-1)^0 * 2^(127-127)(1.00000000000000000000000)
- 0.1 ~ (-1)^0 * 2^(123-127)(1.10011001100110011001101...)
- 0.9 ~ (-1)^0 * 2^(126-127)(1.11001100110011001100110...)
--
Benoît Sibaud |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Tue Mar 21, 2006 11:06 am Post subject: Re: problème de flottant |
|
|
Sylvain wrote:
| Quote: | kanze wrote on 20/03/2006 11:41:
2- puisque apparemment ce que tu aimes développer le plus est
l'art de la contradiction (ni systématiquement intéressante,
ni spécialement en charte), je me sens obligé d'indiquer que
ce "bizutage" me laisse de glace.
|
C'est plutôt que j'aime la correction, et quand on poste des
bêtises, je me sens obligé à les corriger. J'ai une assez faible
tolérance de l'incompétence.
| Quote: | un flottant est nécessairement une valeur définie + ou - sa
précision,
Strictement parlant... Un flottant a une valeur précise ; il
n'y a pas de + ou -. Pour des raisons évidentes
(représentation finie), les flottants ne peuvent pas
représenter tous les réels (ni toutes les rationnelles)
donc "strictement parlant", je te laisserais maintenant
monologuer ce type de platitude.
|
Quand on veut écrire des programmes correctes, il faut savoir
exactement ce qu'on manipule comme données.
| Quote: | 0.1 est une des valeurs qu'ils ne peuvent pas représenter.
et t'as décréter ça tout seul sans même connaître la précision
de son type double !! ben tu vois un Cray tout bête se
représente parfaitement 0.1
|
Je vois que tu n'as jamais programmé sur un Cray. Il utilise (ou
utilisait) un format binaire. Pas le même que IEEE, évidemment,
mais c'était base 2, quand même.
| Quote: | qui fait qu'il n'ajoute pas 0.1 à chaque passage dans la
boucle, mais quelque chose de proche.
tu expliques ça à qui ???????? 4 personnes l'ont déjà dit.
|
D'autres l'avaient bien dit. Je ne me suis donc pas senti obligé
à corriger leur postings. Tu suggérais que le problème était du
à des erreurs d'arrondi dans l'addition. Je ne fais que
corriger ton erreur.
| Quote: | Ça dépend des formats, mais en IEEE (le format le plus
répandu aujourd'hui), la valeur décimale de la mantisse
s'étend de 0.5 à 1.0-epsilon (ou epsilon est 2^-53, je
crois).
la valeur absolue de la mantisse est toujours comprise entre 1
et la base de dénombrement (le premier bit étant caché car
toujours prédictible, cette mantisse se ramène en base 10 à
une quasi partie fractionnaire pure (un nombre décimale sans
partie entière)
|
Je suggère que tu lis l'article que j'ai cité. Et aussi ce que
tu as posté et auquel je répondais, où tu disais que la mantisse
se situe entre 0 et 1. Selon la façon d'interpréter l'exposant,
la mantisse se situe soit dans l'intervale [1/b;1[, soit dans
l'intervale [1;b[. Il ne s'approche jamais à 0.
Le fait que dans certaines représentations, il est possible de
ne pas stocker le bit de poids forts n'entre pas en ligne de
jeux ; quand on travaille au niveau de la représentation
physique, il faut bien en tenir compte.
| Quote: | Il y a aussi des valeurs spéciales, identifiées par une
valeur spéciale dans l'exposant -- 0.0 est sans doute celle
qu'on rencontre la plus souvent.
de l'exposant *et* de la mantisse.
|
La mantisse entre en compte dans l'évaluation de la valeur
spéciale. Il suffit de régarder l'exposant pour savoir si on a
une valeur spéciale ou non -- pour un double, si l'exposant est
0 ou 1023, on a une valeur spéciale : 0.0, un dénormal, une
infinité ou un NaN.
| Quote: | soit il y a le nombre zero (E = 0; F = 0; S = 1)
tu as juste oublié:
-0 (E = 0; F = 0; S = 1)
-Infinity
Infinity
NaN
|
Étant donné que je n'ai rien énuméré, je n'ai rien oublié. Dans
la pratique, parmi ces valeurs spéciales, c'est sûrement 0.0
qu'on voit la plus souvent.
| Quote: | Là aussi, ça dépend du point de vue. La valeur du résultat
est bien définie.
on va dire ça; tabl[4325] est "indéfini" mais savoir comment
le dernier bit d'un flottant est arrondi par tous les unités
flottantes de tous les fondeurs est "définie" .. "selon le
point de vue de James".
|
Selon la norme IEEE. (Mais je n'ai pas l'impression que tu l'as
lu.)
| Quote: | Seulement, dans certains cas, elle sera différente
de celle du résultat de l'opération sur les réels. Mais
c'est quoi "réels", c'est pas dans IEEE 754 ni dans IEEE 854.
|
C'est dans la mathématiques. Je vois mal un mathématicien (ou un
informaticien) qui ne les connaît pas.
[...]
| Quote: | Ça dépend de l'application ; souvent, les valeurs en entrée
sont déjà des approximations, et c'est tout à fait normal de
prendre en compte des epsilons quand on cherche une valeur
précises -- en fait, ce qu'on veut, au niveau de
l'application, c'est déjà x+/-epsilon (avec un epsilon qui
dépend de l'application).
ça a un rapport avec la question, le fil, la chartre ???
ou c'est juste une envolée de plus ?
|
Ça a un rapport avec comment on utilise les flottants dans un
programme.
| Quote: | Mais ce n'est pas une règle générale ; ça dépend de
l'application. Et il faut bien ne pas oublier que si on
définit un isEqual() approximatif, alors isEqual(a,b) &&
isEqual(b,c) n'implique plut isEqual(a,c) -- ce qui peut
faire échouer certaines algorithmes.
oui, seulement si tu ne sais pas coder ton isEqual.
|
Sans connaître ce qu'il doit faire, je ne sais effectivement pas
comment le coder. Et ce qu'il doit faire dépend de
l'application. Si c'est simplement :
bool
isEqual( float a, float b )
{
return a == b ;
}
c'est vrai qu'il est transitif. Mais alors, pourquoi la
fonction ? Et que veut dire « approximatif » ? Dès que tu
commences à faire jou-jou avec des +/- epsilon, il cesse d'être
transitif. Parfois, ça va, mais il faut bien savoir ce qu'on
fait.
| Quote: | Il y a pire, évidemment, et certains algorithmes, pour
certaines valeurs (qui n'apparaîtront pas dans vos tests,
évidemment) peuvent ne pas converger avec les opérations sur
des flottants, alors qu'ils convergeront bien avec les mêmes
opérations sur des réels.
si "réel" voulait signifier "précision arbitraire" (via une
librarie es-spéciale et non une simple unité de calcul
flottant) c'est faux également.
|
N'importe quel informaticien doit savoir au moins ce que sont
les nombres réels. Je m'étonnerais qu'on puisse avoir un bac S
(ou même un bac L) sans les avoir vus.
| Quote: | concrétement:
ne pas coder if (f == 1.0) {}
mais if (fabs(f - 1.0) < 1e- {}
Si tu sais que dans ton application, la précision des
valeurs est de l'ordre 1e-8.
?!?? non, si tu sais que tu utilises des float (32bits), on
utilisera 1e-12 avec des doubles et 1e-14 avec des long
doubles.
|
Et tu as tiré ces valeurs d'où ? De ton chapeau ? (Et pourquoi
la différence entre double et long double, étant donné qu'ils
ont la même représentation sur des plateformes les plus
courantes ?)
| Quote: | Dans les rares cas où je me sers des flottants, je m'arrange
pour que les valeurs soient toujours exactes.
c'est pas du n'importe quoi là ??, tu as répété après tout le
monde que tous les nombres flottants ne pouvaient pas avoir
une représentation exacte de leur valeur, mais toi,
abracadabra, tu t'"arranges" avec eux et hop "c'est exact";
tiens codes donc exactement 7/5
|
Je m'arrange à ne pas avoir 7/5. Comme ça, le problème ne se
pose pas.
| Quote: | En revanche, dans une application où je traiterais des
valeurs lues des instruments de mésure électronique, la
précision serait plutôt de l'ordre 1e-2 ou 1e-3 -- les
instruments ne peuvent pas me donner de plus, de toute
façon.
si, si, c'est vraiment du n'importe quoi. (pousse la porte
d'un labo de physique au moins une fois, tu verras c'est
intéressant).
|
J'ai travaillé longtemps comme ingenieur en électronique. Je
sais que dans les labos de recherche, il existe des instruments
de mesure plus précis. Mais dans l'industrie, c'est rare d'avoir
plus de deux ou trois chiffres décimaux, et encore. Dans
l'électronique, par exemple, les resistances qu'on utilisent
d'habitude ont une précision de 10%.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
Yoxoman
Guest
|
| Posted: Tue Mar 21, 2006 11:06 am Post subject: Re: problème de flottant |
|
|
Sylvain <noSpam (AT) mail (DOT) net> a écrit :
| Quote: | 2- puisque apparemment ce que tu aimes développer le plus est l'art de
la contradiction (ni systématiquement intéressante, ni spécialement en
charte), je me sens obligé d'indiquer que ce "bizutage" me laisse de glace.
|
Ce qu'écrit James m'interesse. D'ailleurs, si le message t'était
uniquement destiné, je pense qu'il t'aurait plutôt envoyé un mail.
Qu'est-ce qui te dérange dans le fait qu'une personne approfondisse ou
remette en cause ce que tu dis ? Si tu as des problèmes à ce niveau,
trouve un autre groupe. Ici, c'est hors charte.
--
"Yo!"
Martin Heidegger (trad. Terrence Malick) |
|
| Back to top |
|
|
Sylvain
Guest
|
| Posted: Wed Mar 22, 2006 11:06 pm Post subject: Re: problème de flottant |
|
|
Arnaud Meurgues wrote on 21/03/2006 09:21:
| Quote: |
« un Cray tout bête », c'est déjà une expression étrange.
Par curiosité, quelle genre de représentation binaire des flottants
utilise ce Cray tout bête pour représenter 0.1 de manière exacte ?
|
désolé c'était un joke, tout le monde sait que certaines familles de
Cray (X-MP) se caractérisent par leur manque de précision.
| Quote: | tout ceci étant hors chartre, google IEEE.
Ce n'est pas plus hors charte que vos réponses dans le fil « pb
iwebbrowser2 ».
|
je ne saisis pas, à relire la FAQ §1.1.7, le post était convenable.
(l'organisation de la hiérarchie microsoft.public.fr autorisait
également à répondre ici plutôt que de 'faire suivre').
| Quote: | Mais si ça vous amuse de développer l'incohérence en
plus du mépris...
|
la spec. IEEE reste (un peu, tout de même, ...) hors chartre et l'exposé
de toutes ses finesses n'était pas indispensable; mais peut être est-ce
méprisant que de convier à googler sans un "pour toute information
patati merci de consulter patata ...".
| Quote: | Il dit que 0.0 est celle qu'on rencontre le plus souvent. [...]
|
j'ai bien lu qu' "il" dit que; toutefois de mon expérience on a aucune
raison de rencontrer plus souvent 0.0 que 1.0 ou 2.37 ... par contre les
débordements (infini ou NaN) sont toujours possibles et sont à traiter
(pour un code à vocation numérique s'entend).
| Quote: | savoir comment le dernier bit d'un flottant est arrondi
Ne pourrait-ce pas être indiqué par numeric_limits<float>::round_style
(tiens, ça c'est en charte) ?
|
il est facile de rencontrer un compilo ne connaisant pas ces limites là;
par ailleurs la précision d'un même code peut changer selon le proc.
arith. (sur la famille 680x0 par exemple la précision interne d'un
double fait des fois 10 octets, des fois 12 octets).
| Quote: | Comment peut-on coder un isEqual approximatif (différent du =, donc) et
transitif ?
|
en jouant sur l'erreur relative (intuitée, calculée, ...); si on
considère que des expressions (immédiates ou calculées) sont "justes" à
10^-n près alors on vérifiera:
si (fabs(a - b) < 10^-n) et (fabs(a - c) < 10^-n)
alors (fabs(b - c) < 10^-n)
cette façon de procéder n'est nullement unique et chacun dans un code
concret pourra réfléchir à un traitement plus pertinent; gardant
notamment à l'esprit que l'arithmétique flottante est généralement non
associative.
| Quote: | Je pense qu'ici, réels signifie réels, mathématiquement parlant.
|
je l'ai bien lu comme ça, mais un CPU ne traite pas de "réels
mathématiques" (Mapple ou Mathematica essaient, un code C++ rarement).
| Quote: | Selon vous, une suite qui converge avec des réels converge
obligatoirement avec des flottants ?
|
la question manque peut être de précision; dans nombre de cas la réponse
sera positive; 1/x converge vers 0 pour x "math. réel" ou "inform.
flottant" (1/b aussi, d'ailleurs).
imho, converger ne signifie pas atteindre exactement une valeur mais
tendre vers cette valeur.
dans le cas général, on définira, ici aussi, un critère d'arrêt qui
prend en compte la précision du calcul pour déterminer si le calcul a
atteint ou non le résultat voulu (exemple quel est x tel que 1/x == 0 à
10^-6 près).
il existera toujours des expressions à forte divergence qui auront du
mal à converger, elles seront codées de manière particulière ... mais je
ne pense pas que l'on parlait de cela.
| Quote: | Si tu sais que dans ton application, la précision des valeurs
est de l'ordre 1e-8.
?!?? non, si tu sais que tu utilises des float (32bits), on utilisera
1e-12 avec des doubles et 1e-14 avec des long doubles.
Et avec des floats ?
|
j'avais déjà donné la valeur 1e^-8 ... je peux répéter que dans un vrai
code une erreur relative fixée a priori peut ne pas convenir, la valeur
pertinente doit tenir compte de la précision de chaque opération (cumul
des erreurs relatives sur chaque opération) et de la "magnitude" des
nombres (si par exemple des nombres dénormaux interviennent durant les
étapes du calcul, la précision du résultat est grandement réduite).
| Quote: | Dans les rares cas où je me sers des flottants, je m'arrange pour que
les valeurs soient toujours
exactes.
Je suppose qu'il ne vous est pas venu à l'esprit qu'il pouvait
s'arranger pour n'avoir à utilier que des nombres représentables.
|
nuance, il ne m'est pas venu à l'esprit que cela puisse être appliqué!
s'il s'agit d'un programme réalisant des acquisitions, il reçoit des
nombres qui ont déjà été ramené au plus proche flottant représentable,
il ne peut d'aucune façon s'il doit refuser une entrée qui ne serait pas
représentable.
s'il reçoit des nombres par saisie, doit-on parser le nombre littéral
(son écriture texte) avant de daigner l'accepter ou non ?
s'il s'agit d'un résultat intermédiaire, doit-on évaluer les opérandes
(et si oui selon quelles règles) pour continuer ou non le calcul ?
si le point ne se limite qu'à une vigilance portée sur la factorisation
de constantes (dans une expression complexe) afin que celles-ci soient
représentables (ou représentables avec la plus faible erreur possible),
je crains que cela ne joue que dans d'infimes cas particuliers (même la
graduation d'un axe utilise généralement des bornes définies par
l'utilisateur ou contraintes par la fonction).
Sylvain. |
|
| Back to top |
|
|
Arnaud Meurgues
Guest
|
| Posted: Thu Mar 23, 2006 8:06 am Post subject: Re: problème de flottant |
|
|
Sylvain wrote:
| Quote: | « un Cray tout bête », c'est déjà une expression étrange.
Par curiosité, quelle genre de représentation binaire des flottants
utilise ce Cray tout bête pour représenter 0.1 de manière exacte ?
désolé c'était un joke, tout le monde sait que certaines familles de
Cray (X-MP) se caractérisent par leur manque de précision.
|
C'était une plaisanterie ?! En gros, dans la même phrase, vous traitez
James de crétin et plaisantez sur l'imprécision « connue » des Cray :
«
| Quote: | 0.1 est une des valeurs qu'ils ne peuvent pas représenter.
et t'as décréter ça tout seul sans même connaître la précision de son
type double !! ben tu vois un Cray tout bête se représente
parfaitement 0.1
» |
Mais bon, vous allez tout de même nous expliquer avec quelle précision
du type double 0.1 est représentable, non ? « Blague » à part...
| Quote: | tout ceci étant hors chartre, google IEEE.
Ce n'est pas plus hors charte que vos réponses dans le fil « pb
iwebbrowser2 ».
je ne saisis pas, à relire la FAQ §1.1.7, le post était convenable.
|
Sauf si vous avez lu 1.1.2 avant.
| Quote: | (l'organisation de la hiérarchie microsoft.public.fr autorisait
également à répondre ici plutôt que de 'faire suivre').
|
Je ne vois pas en quoi l'organisation de la hiérarchie microsoft
autorise quoi que ce soit sur la hiérarchie fr.
| Quote: | la spec. IEEE reste (un peu, tout de même, ...) hors chartre et
l'exposé de toutes ses finesses n'était pas indispensable;
|
Sauf que le code :
double a = 0.1;
double b = 1.0;
while (b != 0.0) b -= a;
est purement C++ et nécessite de comprendre comment fonctionnent les
flottants pour comprendre pourquoi il a très peu de chance de
fonctionner comme on s'y attend.
| Quote: | mais peut
être est-ce méprisant que de convier à googler sans un "pour toute
information patati merci de consulter patata ...".
|
Il est méprisant, lorsqu'on arrive sur un groupe, de rappeler la charte
a des personnes qui y interviennent depuis plusieurs années (voire qui
ont participé à l'élaboration de la charte), surtout lorsqu'on le fait à
tort.
Mais c'était le ton général du message qui était imprégné de mépris et
d'agressivité :
« puisque apparemment ce que tu aimes développer le plus est l'art de la
contradiction (ni systématiquement intéressante, ni spécialement en
charte), je me sens obligé d'indiquer que ce "bizutage" me laisse de
glace. »
« donc "strictement parlant", je te laisserais maintenant monologuer ce
type de platitude. »
« et t'as décréter ça tout seul sans même connaître la précision de son
type double !! ben tu vois un Cray tout bête se représente parfaitement
0.1 »
« tu expliques ça à qui ???????? 4 personnes l'ont déjà dit. »
etc.
| Quote: | Il dit que 0.0 est celle qu'on rencontre le plus souvent. [...]
j'ai bien lu qu' "il" dit que; toutefois de mon expérience on a
aucune raison de rencontrer plus souvent 0.0 que 1.0 ou 2.37 ...
|
Comme quoi vous semblez ne pas avoir la même expérience. À propos,
depuis combien de temps travaillez-vous dans l'informatique (ça va
permettre de mesurer la longueur des expériences de chacun) ?
| Quote: | Ne pourrait-ce pas être indiqué par
numeric_limits<float>::round_style (tiens, ça c'est en charte) ?
il est facile de rencontrer un compilo ne connaisant pas ces limites
là; par ailleurs la précision d'un même code peut changer selon le
proc. arith. (sur la famille 680x0 par exemple la précision interne
d'un double fait des fois 10 octets, des fois 12 octets).
|
Ce qui est connu au moment de la compilation. Mais bon, la précision et
la méthode d'arrondi, ça n'est pas la même chose.
| Quote: | Comment peut-on coder un isEqual approximatif (différent du =,
donc) et transitif ?
en jouant sur l'erreur relative (intuitée, calculée, ...); si on
considère que des expressions (immédiates ou calculées) sont "justes"
à 10^-n près alors on vérifiera:
si (fabs(a - b) < 10^-n) et (fabs(a - c) < 10^-n) alors (fabs(b - c)
10^-n)
|
Peut-être, mais ce n'est pas de ça dont on parlait. On parlait de
transitivité (f(a,b) ^ f(b,c) => f(a,c)).
Accessoirement, il me semble que si l'on prend n = 1, a = 0.0, b = 0.09
et c = -0.09, on a :
fabs(a - b) = fabs(0.0 - 0.09) = fabs(-0.01) = 0.09 < 10^-1
fabs(a - c) = fabs(0.0 + 0.09) = fabs(+0.09) = 0.09 < 10^-1
mais
fabs(b - c) = fabs(0.09 + 0.09) = fabs(0.1 = 0.18 > 10^-1
Donc, je réitère ma question. Comment faut-il coder le isEqual pour
qu'il soit approximatif et transitif ?
| Quote: | cette façon de procéder n'est nullement unique et chacun dans un code
concret pourra réfléchir à un traitement plus pertinent;
|
Heureusement que vous nous laissez cette possibilité.
| Quote: | Je pense qu'ici, réels signifie réels, mathématiquement parlant.
je l'ai bien lu comme ça, mais un CPU ne traite pas de "réels
mathématiques" (Mapple ou Mathematica essaient, un code C++
rarement).
|
Effectivement. Mais qui vous a parlé de CPU ?
Il disait qu'une suite convergente avec des réels (dans le monde
mathématique) peut ne pas converger avec des flottants (dans le monde
informatique).
| Quote: | Selon vous, une suite qui converge avec des réels converge
obligatoirement avec des flottants ?
la question manque peut être de précision;
|
Je ne crois pas.
| Quote: | dans nombre de cas la
réponse sera positive;
|
À cause du « obligatoirement », il suffit d'un cas contraire pour que la
réponse ne puisse pas être positive.
| Quote: | 1/x converge vers 0 pour x "math. réel" ou
"inform. flottant" (1/b aussi, d'ailleurs).
|
Super. Mais ce n'était pas la question.
| Quote: | imho, converger ne signifie pas atteindre exactement une valeur mais
tendre vers cette valeur.
|
Certes. Converger vers une valeur v, c'est assurer que quelque soit un
delta donné, il existe un rang n de la suite tel que n'importe quelle
valeur de la suite après ce rang n à une différence à la valeur v
inférieure à delta.
| Quote: | dans le cas général, on définira, ici aussi, un critère d'arrêt qui
prend en compte la précision du calcul pour déterminer si le calcul a
atteint ou non le résultat voulu (exemple quel est x tel que 1/x ==
0 à 10^-6 près).
|
Oui. Mais ce n'est pas ce dont James parlait.
| Quote: | il existera toujours des expressions à forte divergence qui auront du
mal à converger, elles seront codées de manière particulière ...
mais je ne pense pas que l'on parlait de cela.
|
C'est quoi, « avoir du mal à converger » ?
Je crois que ce dont parlait James, c'est de suites qui convergent dans
les réels, mais pas dans les flottants, avec les mêmes opérations.
| Quote: | Dans les rares cas où je me sers des flottants, je m'arrange
pour que les valeurs soient toujours exactes.
Je suppose qu'il ne vous est pas venu à l'esprit qu'il pouvait
s'arranger pour n'avoir à utilier que des nombres représentables.
nuance, il ne m'est pas venu à l'esprit que cela puisse être
appliqué!
|
Sans doute à cause du mépris pour vos interlocuteurs. Vous en déduisez
que ce qu'ils disent ne méritent pas qu'on le croit.
--
Arnaud |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Thu Mar 23, 2006 9:06 am Post subject: Re: problème de flottant |
|
|
Sylvain wrote:
| Quote: | Arnaud Meurgues wrote on 21/03/2006 09:21:
|
[...]
| Quote: | tout ceci étant hors chartre, google IEEE.
Ce n'est pas plus hors charte que vos réponses dans le fil « pb
iwebbrowser2 ».
|
Pour être honnête, ce n'est pas que ses réponses qui sont hors
chartre, c'est le fil entier.
Personnellement, ça ne me gène pas plus que ça, dans la mesure
où on n'est pas inondé par de tels fils. Actuellement, ce n'est
pas le cas (même si ça a menacé dans la passée).
Pour être même plus honnête, ce n'est pas plus hors chartre que
le fil sur les threads sous Posix, où je participe fortement
aussi. Alors, je ne jetterai pas de pierre.
| Quote: | je ne saisis pas, à relire la FAQ §1.1.7, le post était
convenable. (l'organisation de la hiérarchie
microsoft.public.fr autorisait également à répondre ici plutôt
que de 'faire suivre').
|
C'était du spécifique Microsoft, donc hors charte. IEEE se
trouve dans beaucoup d'implémentations différentes de C++ ; la
norme en parle. norme. Ce n'est donc pas hors charte (au moins,
pas complètement).
Comment fonctionne les virgules flottants en C++ n'est
certainement pas hors chartre ; se servir de IEEE à titre
d'exemple est un bon moyen pédégogique pour le faire.
| Quote: | Mais si ça vous amuse de développer l'incohérence en plus du
mépris...
la spec. IEEE reste (un peu, tout de même, ...) hors chartre
et l'exposé de toutes ses finesses n'était pas indispensable;
|
C'est toi qui a commencé. Et connaître les subtilités des
virgules flottants est indispensable si tu veux écrire du code
qui marche.
| Quote: | mais peut être est-ce méprisant que de convier à googler sans
un "pour toute information patati merci de consulter patata
...".
|
Pas du tout. Il y a beaucoup de choses où la réponse dépasse les
bornes de ce qu'on peut raisonablement mettre dans un posting.
"What Every Computer Scientist Should Know about Floating Point
Arithmetic" fait plus de cents pages, et il ne couvre qu'un
minimum.
| Quote: | Il dit que 0.0 est celle qu'on rencontre le plus souvent. [...]
j'ai bien lu qu' "il" dit que; toutefois de mon expérience on
a aucune raison de rencontrer plus souvent 0.0 que 1.0 ou 2.37
|
Il a dit que 0.0 est la valeur spéciale qu'on rencontre le plus
souvent. 1.0 ou 2.37 ne sont pas des valeurs spécales.
| Quote: | ... par contre les débordements (infini ou NaN) sont toujours
possibles et sont à traiter (pour un code à vocation numérique
s'entend).
|
Certainement.
| Quote: | savoir comment le dernier bit d'un flottant est arrondi
Ne pourrait-ce pas être indiqué par
numeric_limits<float>::round_style (tiens, ça c'est en
charte) ?
il est facile de rencontrer un compilo ne connaisant pas ces
limites là;
|
De moins en moins facile, quand même. Mais c'est vrai qu'on ne
peut pas toujours utiliser la dernière version du compilateur.
| Quote: | par ailleurs la précision d'un même code peut changer selon le
proc. arith. (sur la famille 680x0 par exemple la précision
interne d'un double fait des fois 10 octets, des fois 12
octets).
|
La précision peut même changer selon le niveau d'optimization --
sur Intel, les calculs dans le processeur flottant se font
toujours en long double. Les valeurs intermédiaires qui restent
dans un règistre flottant retient cette précision
supplémentaire, celle que le compilateur sauve en mémoire non.
C'est un phénomène très frustrant pour celui qui essaie
d'analyser la stabilité d'un algorithme.
| Quote: | Comment peut-on coder un isEqual approximatif (différent du
=, donc) et transitif ?
en jouant sur l'erreur relative (intuitée, calculée, ...); si
on considère que des expressions (immédiates ou calculées)
sont "justes" à 10^-n près alors on vérifiera:
si (fabs(a - b) < 10^-n) et (fabs(a - c) < 10^-n)
alors (fabs(b - c) < 10^-n)
cette façon de procéder n'est nullement unique et chacun dans
un code concret pourra réfléchir à un traitement plus
pertinent; gardant notamment à l'esprit que l'arithmétique
flottante est généralement non associative.
|
Et qu'une telle définition de l'« égalité » n'est pas
transative. Et qu'il n'a du sens que pour un sous-ensemble très
limité de valeurs, et que pour certaines applications seulement.
| Quote: | Dans les rares cas où je me sers des flottants, je
m'arrange pour que les valeurs soient toujours exactes.
Je suppose qu'il ne vous est pas venu à l'esprit qu'il
pouvait s'arranger pour n'avoir à utilier que des nombres
représentables.
nuance, il ne m'est pas venu à l'esprit que cela puisse être
appliqué!
|
Et cependant, c'est assez fréquent, au moins dans certains
domaines. On sait, par exemple, qu'un double (IEEE, en tout cas)
peut représenter tous les entiers de -2^53 à 2^53 de façon
exacte. Sur une machine 32 bits, c'est mieux qu'un long.
Évidemment, il faut appliquer des corrections à la suite d'une
division, à l'aide de modf, mais on s'en servait souvent dans
les implémentations des valeurs monétaires, par exemple ;
9007199254740992 centîmes étant une limite acceptable,
2147483648 non.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
