OVH Cloud OVH Cloud

std::numeric_limits::min()

38 réponses
Avatar
Alexis Guillaume
Bonjour à tous.

J'aimerais comprendre pourquoi sur mon système (gcc 3.3)
std::numeric_limits<double>::min() vaut 2.22507e-308. Cela me dérange
parce qu'intuitivement je pensais que le minimum serait l'opposé
de std::numeric_limits<double>::max() et que la valeur remarquable
2.22507e-308 aurait un nom spécifique.

Quelles sont les raisons de ce choix ? Je le te trouve étrange dans la
mesure ou la simple fonction suivante ne marche pas avec les double :

template <typename T>
T max( T const * begin, T const * end ) {
T max = std::numeric_limits<T>::min();
while (begin != end) {
if (*begin >= max) max = *begin;
++begin;
}
return max;
}

int main() {
unsigned int t1[] = { 1, 2, 4, 3 };
int t2[] = { -1000, -200, -1, -10 };
double t3[] = { -1, -2, -3, -4 };

std::cout << max(t1, t1 + 4) << "\n" << max(t2, t2 + 4)
<< "\n" << max(t3, t3 + 4) << std::endl;
}

Résultat :
4
-1
2.22507e-308

--
Alexis Guillaume
<http://cowsoft.free.fr> : ressources universitaires en vrac

"Il est minuit. La pluie fouette les vitres."

10 réponses

1 2 3 4
Avatar
Gabriel Dos Reis
writes:

| Tout à fait. C'est comme ça que je l'écris en général moi-même. Ce qui
| m'intéressait dans mon exemple, ce n'était pas l'algorithme à choisir
| pour trouver la maximum, c'était plutôt comment il faut s'attaquer pour
| trouver la valeur la plus petite avec std::numeric_limits.

C'est une question complètement indépendante de trouver un maximum
dans une séquence. D'ailleurs, j'avais répondu en ce sens :-/

-- Gaby
Avatar
Gabriel Dos Reis
"Vincent Lascaux" writes:

| > | > | Donc l'idée de prendre -std::numeric_limits<double>::max() pour
| > | représenter
| > | > | une valeur infinie plus petite que toute autre valeur n'est pas une
| idée
| > | > | applicable à tous les types.
| > | >
| > | > Cela me paraît évident puisque « double » n'est pas « tous les
| types ».
| > |
| > | Je vois pas en quoi c'est évident...
| >
| > Est-ce que « double » est « tous les types ? La réponse est non.
| > C'est pas évident ?
|
| Est ce que j'ai dit que double était tous les types ?

Relis ce que tu as cité comme message.

-- Gaby
Avatar
James Kanze
"Vincent Lascaux" writes:

|> > | > -std::numeric_limits<double>::max()

|> > | Est-on assuré de pouvoir stoquer
|> > | -std::numeric_limits<double>::max() dans un double ?

|> > Oui.

|> Et est ce que -std::numeric_limits<T>::max() = |> std::numeric_limits<T>::min() pour T char, short, int, long (et les
|> autres si j'en oublie) ?

Pas en général.

--
James Kanze
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
Avatar
James Kanze
Fabien LE LEZ writes:

|> On 18 Jun 2004 00:04:33 -0700, :

|> >le texte normatif. Tout ce qu'il dit, c'est &#65533; minimum finite
|> >value &#65533;,
|> >avec une exception seulement pour des types flottants avec
|> >d&#65533;normalisation ! Or, si son flottant n'a pas de
|> >d&#65533;normalisation, &#65533;a
|> >m'&#65533;tonnerait que la valeur minimum finie ne soit pas

|> Houlà ! Ton lecteur de news délire :-(

En effet. J'ai l'impression qu'il s'est mis à faire des folies. En fait :

J'ai essayé un upgrade de Mozilla, pour pouvoir traiter des svg. Il n'a
pas marché. Alors, j'ai fait marche en arrière, pour revenir au point du
départ. Autant que je sache, j'ai la même configuration qu'avant. Mais
le copier/coller fait des siens -- je lis avec Google, qui s'obstine à
m'envoyer du UTF-8. Ce qu'emacs (que j'utilise pour l'édition des
messages) ne sait pas traiter.

En fait, je ne sais pas pourquoi ça a marché avant. Il y a sûrement
quelque chose dans mon environement qui a changé. À moins que ce soit
une coïncidence, et que Google m'envoie du UTF-8 soit aussi du nouveau.
(Tant que ça marchait, je n'avait pas l'occasion de régarder ce qu'il
faisait.)

Je régarderai lundi (c'est la machine au travail qui pose des problèmes)
pour voir ce que je peux trouver.

--
James Kanze
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
Avatar
James Kanze
Gabriel Dos Reis writes:

|> writes:

|> | Gabriel Dos Reis wrote in message
|> | news:...
|> | > Alexis Guillaume writes:

|> | > | J'aimerais comprendre pourquoi sur mon systeme (gcc 3.3)
|> | > | std::numeric_limits<double>::min() vaut 2.22507e-308.

|> | > Parce que la norme demande que ce soit la plus petite valeur
|> | > positive.

|> | C'est sans doute ce qu'on a voule, mais ce n'est pas ce que dit en
|> | fait le texte normatif. Tout ce qu'il dit, c'est « minimum finite
|> | value », avec une exception seulement pour des types flottants
|> | avec dénormalisation ! Or, si son flottant n'a pas de
|> | dénormalisation, ça m'étonnerait que la valeur minimum finie ne
|> | soit pas négative.

|> Tu connais une implémentation dans le monde réel où c'est le cas ?

Où quoi c'est le cas ? Que l'implémentation n'a pas de dénormalisation :
c'est le cas même de la plupart des formats flottants que je connais --
sur les gros IBM, les PDP-11 et les Vax d'avant IEEE...

|> | En fait, d'après les valeurs qu'il a, je suppose qu'il a IEEE.
|> | Donc, des flottants avec dénormalisation. Et l'exception
|> | s'applique. Mais je n'arrive pas à est ce qu'ils ont écrit.

|> Si ton interprétation ne colle pas avec la réalité, change
|> d'interprétation :-)

Je n'interprète rien. Je répète simplement ce que la norme dit.

--
James Kanze
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
Avatar
James Kanze
Alexis Guillaume writes:

|> À moitié. Je cherche à comprendre ce qui a motivé ce choix qui
|> conduit à ce qui m'apparaît être une incohérence.

L'histoire.

En fait, dans les deux cas (entier et flottant), la valeur pour min,
c'est ce qui est la plus utile. C'est un peu dommage qu'on a choisi le
même nom pour deux choses bien différentes, mais ça prédate même DBL_MIN
de beaucoup.

|> Ta réponse ne fait que reporter le problème à DBL_MIN. :-)

Qui s'est basé sur ce qui faisait avant. Et dans d'autres langages. (Je
me démande si ce n'était pas déjà le cas en Fortran IV.)

|> Au fait merci pour le code de la fonction max(), mais mon exemple
|> n'était là que pour exhiber un cas gênant (qui m'est arrivé et m'a
|> bien fait perdre du temps car je ne m'y attendais pas du tout).

--
James Kanze
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
Avatar
James Kanze
Gabriel Dos Reis writes:

|> Alexis Guillaume writes:

|> | À moitié. Je cherche à comprendre ce qui a motivé ce choix qui
|> | conduit à ce qui m'apparaît être une incohérence. Ta réponse ne
|> | fait que reporter le problème à DBL_MIN. :-)

|> Conformité à LIA-1 et l'existant.

DBL_MIN était présente avant LIA-1. C'est plutôt LIA-1 qui est conforme
à l'existant.

--
James Kanze
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
Avatar
Vincent Lascaux
| Et est ce que -std::numeric_limits<T>::max() = > | std::numeric_limits<T>::min() pour T char, short, int, long (et les
autres

| si j'en oublie) ?

Non. Sur des machines à complément à 2, ce n'est certainement pas le cas.


Donc l'idée de prendre -std::numeric_limits<double>::max() pour représenter
une valeur infinie plus petite que toute autre valeur n'est pas une idée
applicable à tous les types. Je suis d'accord avec Alexis pour dire que ce
choix de std::numeric_limits<double>::min() n'est pas très judicieux puisque
c'est une exception qu'on ne peut pas contourner simplement. Je pense qu'il
aurait été préférable de rajouter un nouveau champ (epsilon ?) pour la
valeur strictement positive la plus petite représentable...

--
Vincent

Avatar
Gabriel Dos Reis
"Vincent Lascaux" writes:

| >> Relis ce que tu as cité comme message.
| >>
| >
| >l'idée de prendre -std::numeric_limits<double>::max() pour représenter
| >une valeur infinie plus petite que toute autre valeur n'est pas une idée
| >applicable à tous les types
|
| Je maintiens que j'ai parlé d'appliquer une *idée* à un autre type. Je
| maintiens aussi qu'appliquer une idée implique quelque part adapter l'idée

mais quelle idée ? Toutes celles que tu as exposées sont foireuses.
Alors, bien sûr, tu peux maintenir, c'est ton droit. Mais quoi
exactment ?

| (mais apparemment l'adaptation c'est pas trop ton truc).

C'est évident non ?

-- Gaby
Avatar
Vincent Lascaux
| Donc l'idée de prendre -std::numeric_limits<double>::max() pour
représenter

| une valeur infinie plus petite que toute autre valeur n'est pas une idée
| applicable à tous les types.

Cela me paraît évident puisque « double » n'est pas « tous les types ».


Je vois pas en quoi c'est évident...
L'idée de prendre std::numeric_limits<double>::max() pour représenter une
valeur infinie plus grande que toute autre valeur est une idée applicable à
tous les types (même si double n'est pas tous les types).
Franchement Gaby, ca avance à quoi d'essayer de jouer sur les mots comme ca
?

| c'est une exception qu'on ne peut pas contourner simplement. Je pense
qu'il


Ce n'est pas une exception : c'est le cas pour tous les floating-points.


Ca n'empeche pas que ce soit une exception : pour tous les autres types
(sauf les floating points) T, je suis assuré que pour tout t dans T,
t>=std::numeric_limits<T>::min().

| aurait été préférable de rajouter un nouveau champ (epsilon ?) pour la

« epsilon » existe et a une sémantique bien définie et différente de
la valeur strictement positive la plus petite représentable.


J'ai bien fait de mettre un point d'interrogation moi ;)

--
Vincent

1 2 3 4