std::numeric_limits::min()

James Kanze <kanze@gabi-soft.fr> writes:

| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| |> Alexis Guillaume <alek@volfoni-brothers.org> 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.

Et alors ?

| C'est plutôt LIA-1 qui est conforme à l'existant.

Lequel existant ?

Le lecteur sérieux de la spécification de LIA-1 aura noté que LIA-1
est au courant de ce qu'il appelle « the most negative floating point
number ». Le lecteur sérieux pourra se rapporter à A.5.2.0.* a
délibéremment choisi de ne pas se conformer à l'existant -- ah oui,
l'existant ne veut pas forcément dit en C K+R ou C90 ; il paraît qu'il
existe autre chose dans la vie, en particulier pour les numériciens.

-- Gaby

Alexis Guillaume wrote:

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.

Ton système est conforme en tout cas :
static T min() throw();
Minimum finite value.181)
For floating types with denormalization, returns the minimum positive
normalized value.

Maintenant, pourqui, je pourrais te dire que c'est pour que ce soit égal
à DBL_MIN, mais je ne suis pas certain que ça te satisfasse...

À 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. :-)

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).

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

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

"Vincent Lascaux" <nospam@nospam.org> writes:

| > | 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.

Cela me paraît évident puisque « double » n'est pas « 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 judicieux pour ce qu'il représente.

| 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.

| 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.

| valeur strictement positive la plus petite représentable...

-- Gaby

"Vincent Lascaux" <nospam@nospam.org> writes:

| > | 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

Et accessoirement, -std::numeric_limits<double>::max() n'est pas une
valeur infinie. Alors l'utiliser comme si elle en était une n'est
définitivement pas une bonne idée.

-- Gaby

On 18 Jun 2004 00:04:33 -0700, kanze@gabi-soft.fr:

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 :-(


--
schtroumpf schtroumpf

le Thursday 17 June 2004 20:20, loic.actarus.joly@wanadoo.fr écrivit :

Le code suivant doit marcher, non ?

template <typename T>
T max( T const * begin, T const * end ) {
assert (begin != end);
T max = *begin;

Ben en fait ça ne permet pas tjrs de se passer d'une valeur qui agisse comme
-infini.
(parfois on n'a pas accès par avance aux éléments dont on veut le minimum.
genre parcours compliqué de certains noeuds d'un arbre, etc..)

soit on a une valeur qui puisse être utilisée en lieu de -infini, soit il
faut ajouter un marqueur booleen pour éviter d'avoir à initialiser.
c'est qd même comfortable de pouvoir prendre la valeur minimale d'un type,
parceque c'est pas très joli la version avec booléen supplémentaire..

--
Sam

"Vincent Lascaux" <nospam@nospam.org> 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 ?

(secundo, est-ce que std::numeric_limits<double>::max() est infinie,
la réponse est aussi non.)

| 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).

C'est pas parce que tu le répètes que cela va avoir une légitimité ou
un sens.

| Franchement Gaby, ca avance à quoi d'essayer de jouer sur les mots comme ca
| ?

Si tu n'arrives pas à poser le problème correctement, ça sert à quoi
de vouloir chercher une solution ?

| > | 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

c'est vrai, l'exception, c'est les autres -- tout dépend finalement
d'où on place le point de référence.

| : 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 ;)

:-)

Je crois qu'il faut d'abord comprendre les systèmes numériques et
leurs représentations dans les langages de programmation, ainsi
que les concepts derrière numeric_limits<> avant de porter quelque
jugements que ce soit.

-- Gaby

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote in message
| news:<m3isdpc5n9.fsf@merlin.cs.tamu.edu>...
| > "Vincent Lascaux" <nospam@nospam.org> writes:
|
| > | > | 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
|
| > Et accessoirement, -std::numeric_limits<double>::max() n'est pas une
| > valeur infinie. Alors l'utiliser comme si elle en était une n'est
| > définitivement pas une bonne idée.
|
| Alors, pour une fonction pour trouver le maximum, est-ce que tu penses
| que quelque chose du genre :
|
| template< typename FwdIter >
| std::iterator_traits< FwdIter >::value_type
| findMax( FwdIter begin, FwdIter end )
| {
| typedef std::iterator_traits< FwdIter >::value_type
| T ;
| T result
| = ( std::numeric_limits< T >::is_integer
| ? std::numeric_limits< T >::min()
| : std::numeric_limits< T >::has_infinity
| ? - std::numeric_limits< T >::infinity()
| : - std::numeric_limits< T >::max() ) ;
| while ( begin != end ) {
| if ( *begin > result ) {
| result = *begin ;
| }
| ++ begin ;
| }
| return result ;
| }
|
| ferait l'affaire ? Est-ce qu'il y a des solutions plus simple ? Ou
| est-ce qu'il y a encore des points auxquels je n'ai pas pensé.

J'ai déjà posté un code dans un autre message.

#include <iterator>
#include <stdexcept>
#include <numeric>

template<typename FwdIter>
typename std::iterator_traits<FwdIter>::value_type
findMax(FwdIter begin, FwdIter end)
{
if (begin == end)
throw std::domain_error("empty sequence");
return *std::max_element(begin, end);
}

| (Et en passant -- j'ai bricolé un peu dans ma configuration. Est-ce que
| les accents passent correctement de nouveau ?)

Oui.

-- Gaby

kanze@gabi-soft.fr writes:


[...]

| > | |> Tu connais une implémentation dans le monde réel où c'est le cas ?
|
| > | Où quoi c'est le cas ?
|
| > std::numeric_limits<double>::min() est négatif. C'est le point crucial.
| > Le reste, c'est de la distraction.
|
| Du point de vue pratique, d'accord. En fait, toute les implémentations
| font ce qu'on attend, sans tenir compte de la norme.
|
| Enfin, je crois. Parce que je n'ai pas eu l'occasion d'utiliser le C++
| sur des machines autres que IEEE.

Comme je l'ai répété plusieurs fois, numeric_limits<> est calqué sur
LIA-1 et LIA-1 ne présuppose pas IEEE-754.

OK, comme je n'ai pas envie de faire ce même débat l'année prochaine,
je vais écrire un papier pour régler cette affaire.

-- Gabby

| > -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) ?

--
Vincent