ENIB LANG-C 03_Types - Variété de types

{} La taille des types

Un critère très couramment considéré lors du choix d'un type de données concerne la taille qu'il occupe dans la mémoire.
Ceci est particulièrement important lorsqu'une très grande quantité de données de ce type doit être manipulée et mémorisée✍.

{} L'opérateur sizeof

Le langage C dispose à ce propos de l'opérateur sizeof qui donne la taille d'un type exprimée en bytes (c'est-à-dire en octets dans la pratique).
(https://en.cppreference.com/w/c/language/sizeof)
Il peut s'utiliser de deux façons :

...
{
  taille_du_type_choisi=sizeof(nom_d_un_type);
  taille_du_type_de_l_expression=sizeof(une_expression);
  ...
}

Si son usage est trivial dans le cas où il est appliqué à un type, il nécessite toutefois un éclaircissement dans le cas d'une expression.
Cette dernière est analysée comme à l'accoutumée par le compilateur ce qui conduit à la détermination de son type.
Le type déterminé est alors utilisé par l'opérateur sizeof ; cependant, l'expression en question n'est pas évaluée ni exécutée !
Si elle exprime des effets secondaires, ceux-ci n'auront pas lieu.
Dans la pratique cette notation est très souvent utilisée pour se référer au type d'une expression qui se réduit à une simple variable : le nombre d'octets qu'occupe cette variable.

Complétez tout d'abord la fonction displaySize() pour afficher de manière claire la taille du type int.
Puisqu'elle exprime un nombre d'octets, cette taille est une grandeur entière ; le format %d de l'appel à la fonction printf() est choisi en conséquence.

...
{
  printf("sizeof(int) = %d\n", sizeof(int));
  ...
}

Relancez la fabrication du programme ; celle-ci doit vous avertir du fait que cette taille n'a pas tout à fait le type d'un simple entier.
En effet, une relecture attentive de la documentation de sizeof doit vous apprendre que son type est size_t.
(https://en.cppreference.com/w/c/types/size_t)
Il s'agit d'un nom de type (typedef), proposé par les fichiers d'en-tête standards (notamment

<stddef.h>

), désignant un entier non-signé (unsigned) capable de représenter la taille d'une donnée quelconque tenant dans la mémoire de la machine✍.
Dans un environnement 64-bit (c'est le cas pour les machines des salles de labo de l'ENIB) cette taille est potentiellement gigantesque (même si la machine particulière utilisée en pratique dispose d'une quantité de mémoire moindre).

Puisqu'ici nous déterminons la taille d'un simple entier nous pouvons sans risque convertir (cast, voir cette section) le résultat de l'opérateur sizeof vers le type int afin de faire disparaître le message d'avertissement.
Profitez-en alors pour procéder de même en affichant également la taille du type size_t.

...
{
  printf("sizeof(size_t) = %d\n", (int)sizeof(size_t));
  printf("sizeof(int)    = %d\n", (int)sizeof(int)   );
  ...
}

Fabriquez à nouveau le programme (ce qui ne doit plus provoquer d'avertissement) et exécutez-le afin de constater les tailles respectives des types int et size_t.

{} Comparaison de la taille des types

{} Les entiers de taille déterminée

Au delà des types booléen et réels, l'expérience précédente montre en particulier qu'il existe des types entiers ayant des tailles variées.
Seulement, la norme du langage C ne spécifie pas de taille exacte pour ces types (à l'exception de char).
Dans ces conditions, il est difficile d'écrire du code portable qui réponde à des exigences précises sur la taille des entiers.
Heureusement, le fichier d'en-tête

<stdint.h>

fournit des types (par l'usage de typedef) dont le nom assure le respect de la taille annoncée sur la plateforme d'exécution visée.
(https://en.cppreference.com/w/c/types/integer)
Complétez alors la fonction displaySize() pour afficher de manière claire la taille des types :

int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.

Fabriquez à nouveau le programme et exécutez-le afin de vérifier que tous ces types tiennent bien leur promesse en terme de taille.

Il peut être tentant de se précipiter sur un usage exclusif de ces types à taille déterminée, mais les experts s'accordent à dire que le choix par défaut pour un entier doit se porter sur le type int si aucune contrainte spécifique n'est exprimée (un simple compteur par exemple)✍.
Le recours à des entiers non-signés (unsigned) ou de taille spécifique ne doit être envisagé que dans de très rares cas : opérations bit-à-bit (présentées ultérieurement), plages de valeurs strictement définies (interaction avec du matériel)...

{} Dépassement de capacité

Puisque tous les entiers ont une certaine taille (quelle qu'elle soit), ils ne peuvent décrire qu'un ensemble fini de valeurs.
Nous nous intéressons ici à ce qu'il se passe lorsque nous sortons de cette plage de valeurs.

{} Conversion vers un type insuffisamment large

Vous devez maintenant déclarer dans typeProperties.h et définir dans typeProperties.c cette nouvelle fonction :

void
intOverflow(int limit)
{
  printf("\n~~~~ intOverflow(%d) ~~~~\n", limit);
  for(int i=0; i<limit; ++i)
  {
    uint16_t other=(uint16_t)i;
    if(other!=i)
    {
      printf("%d has been turned into %d\n", i, other);
      break;
    }
  }
}

Au delà de l'affichage de son nom et de son paramètre limit, elle réalise une boucle avec un compteur qui effectue au maximum limit itérations.
La variable other n'est rien d'autre que la copie du compteur i mais dans un type entier plus petit (contrôlez les résultats de la fonction displaySize()), ce qui nécessite une conversion explicite.
L'alternative simple sert à détecter lorsque la copie ainsi obtenue est différente de la valeur originale✍.
Si tel est le cas, un message explicite retranscrit les valeurs en question et la boucle est arrêtée prématurément.

Il faudra ajouter au programme principal du fichier prog03.c un appel à cette fonction avec la valeur 10000 (dix mille) comme paramètre.
Fabriquez à nouveau le programme et exécutez-le afin d'observer l'effet de cette boucle.
En l'état, aucune différence de valeurs ne doit être signalée.
Complétez à nouveau le programme principal par un nouvel appel à cette fonction qui utilise 100000 (cent mille) comme paramètre.
Après une nouvelle fabrication, l'exécution de ce programme doit maintenant signaler une différence de valeurs dans la boucle de la fonction intOverflow().
Observez alors les valeurs indiquées et confrontez-les à la taille du type uint16_t utilisé : vous devez interpréter la valeur observée en terme de puissance de deux.
Pour confirmer votre intuition, ajoutez après cette boucle l'affichage de la constante entière UINT16_MAX et relancez l'expérience.

Vous venez, d'une part, de mettre en évidence la plage de valeurs pouvant être décrites par une variable de type uint16_t, et d'autre part, de constater le comportement d'un tel entier non-signé lorsqu'un dépassement de capacité survient : le compte repart à 0.
En effet, les bits de poids forts manquants sont ignorés et ne subsistent que les bits de poids faibles.
De la même façon, attribuer à un entier non-signé une valeur négative provoque un rebouclage vers les grandes valeurs positives.
Ce comportement est parfaitement décrit dans la norme du langage C mais uniquement pour les entiers non-signés.
Il est donc parfaitement correct d'écrire un algorithme qui compte sur le fait qu'un entier non-signé trop grand ou trop petit reboucle vers l'autre extrémité de la plage de valeurs.

Intervenez maintenant dans la fonction intOverflow() pour changer le type uint16_t en int16_t et pour ajouter l'affichage de la valeur des constantes entières INT16_MIN et INT16_MAX après la boucle.
Relancez l'expérience et observez les valeurs reportées lors du dépassement de capacité.
De manière assez similaire à l'expérience précédente, vous devez constater que lorsque le compteur dépasse INT16_MAX, la valeur obtenue dans la variable de type int16_t reboucle vers INT16_MIN.
Attention toutefois, même si dans la pratique nous constatons un tel rebouclage, la norme du langage C précise qu'un dépassement de capacité sur un entier signé (que ce soit par les valeurs positives ou négatives) produit un comportement indéfini.
Il est donc totalement incorrect d'écrire un algorithme qui compte sur le fait qu'un entier signé trop grand ou trop petit reboucle vers l'autre extrémité de la plage de valeurs.
Ce comportement indéterminé offre au compilateur de langage C une très bonne opportunité pour optimiser certains algorithmes.
En effet, comme nous le verrons dans cette section, l'utilisation de compteurs signés donne au compilateur l'opportunité de remanier beaucoup plus profondément les algorithmes (car aucun rebouclage n'est à envisager) que dans le cas des compteurs non-signés (pour lesquels l'éventualité d'un rebouclage doit absolument être considérée)✍.

Dans les deux cas traités ici, signé et non-signé, le compilateur sait qu'il y a un risque de perte d'information lors de l'affectation d'un entier vers un autre plus petit, c'est pourquoi il produit un avertissement pour attirer notre attention.
Pour lui indiquer que nous assumons ce choix, c'est le cas dans cet exercice, nous devons utiliser l'opération de conversion explicite de type (cast).
Bien entendu, ce que nous avons constaté ici autour d'entiers de seize bits se généralise à toutes les tailles d'entiers.
Pour terminer ce volet, prenons alors connaissance des ordres de grandeur de quelques types entiers usuels.
Affichez dans la fonction intOverflow() la valeur des constantes entières INT_MIN, INT_MAX, CHAR_MIN et CHAR_MAX du fichier d'en-tête standard

<limits.h>

.
(https://en.cppreference.com/w/c/types/limits)
Observez les valeurs limites affichées par l'exécution de cette nouvelle version du programme et confrontez-les aux tailles reportées par la fonction displaySize().

Complément : incrémentation excessive

Nous réutilisons ici le prétexte du dépassement de capacité pour mettre en œuvre quelques éléments du chapitre sur les éléments de base du langage à une fin d'entraînement.

Vous devez maintenant déclarer dans typeProperties.h et définir dans typeProperties.c cette nouvelle fonction :

void
tributeToChuck(void)
{
  printf("\n~~~~ tributeToChuck() ~~~~\n");
  typedef uint32_t TestInt;
  int loopCount=0;
  TestInt prev=0;
  for(TestInt i=0; ; ++i)
  {
    if(i<prev)
    {
      ++loopCount;
      printf("Chuck Norris counted to infinity - ");
      switch(loopCount)
      {
        case 1:
        {
          printf("once\n");
          break;
        }
        case 2:
        {
          printf("twice\n");
          break;
        }
        default:
        {
          printf("%d times\n", loopCount);
          break;
        }
      }
      if(loopCount>2)
      {
        printf("then the numbers broke down!\n");
        break;
      }
    }
    prev=i;
  }
}

Faites l'effort d'analyser attentivement le code source de cette fonction ; vous devriez constater notamment que :

un type TestInt est inventé grâce au mot-clef typedef afin de servir à la fois pour le compteur i de la boucle for et la variable prev,
la variable prev mémorise à chaque fin d'itération la valeur précédente du compteur i, juste avant qu'il ne soit incrémenté,
la boucle for ne comporte pas de condition, elle ne s'arrêtera donc pas spontanément ; il s'agit en apparence d'une boucle infinie qui incrémente infiniment son compteur i,
l'alternative simple est surprenante dans la mesure où elle tente de détecter le cas où la valeur de i serait inférieure à sa valeur précédente alors qu'elle est systématiquement incrémentée,
à chaque fois qu'une telle situation est néanmoins détectée, le compteur loopCount est incrémenté,
une alternative multiple portant sur loopCount module le message qui est affiché,
la troisième détection d'une telle situation, provoque la sortie explicite de la boucle for (elle n'est donc pas infinie).

Il faudra ajouter au programme principal du fichier prog03.c un appel à cette fonction.
Fabriquez à nouveau le programme et exécutez-le afin d'observer son comportement.
Il vous faudra un peu de patience pour voir les messages de la fonction tributeToChuck() apparaître.
En effet, il faut attendre que suffisamment d'incrémentations aient eu lieu sur i pour que la valeur maximale de son type soit dépassée et reboucle vers 0.
Si vous souhaitez accélérer ce phénomène, vous pouvez modifier le type TestInt afin qu'il corresponde à uint16_t.
À l'inverse, si vous le remplacez par uint64_t l'attente deviendra interminable puisqu'il vous faudrait environ quatre milliards de fois plus longtemps qu'avec le type uint32_t✍ ; vous pouvez alors terminer brutalement le programme en saisissant la combinaison de touches [Control]-[c] dans le terminal depuis lequel vous l'avez lancé.

{} Dépassement dans un calcul arithmétique

Jusqu'alors, les dépassements de capacité ont été provoqués de manière évidente.
Ce nouvel exemple montre qu'ils surviennent parfois de manière plus subtile et imprévue.

Vous devez maintenant déclarer dans typeProperties.h et définir dans typeProperties.c cette nouvelle fonction :

void
intComputation(int a,
               int b,
               int c)
{
  printf("\n~~~~ intComputation(%d, %d, %d) ~~~~\n", a, b, c);
  printf("a*b/c = %d\n", a*b/c);
}

Il faudra ajouter au programme principal du fichier prog03.c un appel à cette fonction avec les valeurs 2, 3 et 4 comme paramètres.
Fabriquez à nouveau le programme et exécutez-le afin d'observer son comportement.
Du point de vue arithmétique le résultat devrait être 1.5 mais, puisque ce calcul n'utilise que des entiers, aucune décimale n'est retenue : nous obtenons donc la valeur 1.

Intervenez maintenant dans le programme principal pour modifier l'appel à la fonction intComputation() de cette façon :

...
{
  ...
  for(int i=1; i<=1000000; i*=10)
  {
    intComputation(2*i, 3*i, 4*i);
  }
  ...
}

Fabriquez à nouveau le programme et exécutez-le afin d'observer la séquence de résultats obtenue.
Si les premiers résultats semblent progresser de manière cohérente (des multiples de 1.5), ils deviennent aberrants (négatifs notamment) lorsque les paramètres a, b et c deviennent multiples de 100000 (cent mille) et au-delà✍.
Pourtant, un simple calcul mental permet de prévoir que les résultats attendus tiennent aisément dans la plage de valeurs couverte par le type int utilisé pour ces calculs.

L'apparition de tels résultats aberrants est probablement due à un débordement de capacité intervenant avant que la division par c n'ait lieu.
Pour investiguer dans cette direction, complétons la fonction intComputation() en ajoutant un affichage clair du résultat du calcul a*(b/c) (qui doit être équivalent au précédent du point de vue arithmétique).
Un relance de l'expérience doit indiquer que cette nouvelle formulation du calcul donne systématiquement le résultat 0.
En effet, si vous ajoutez de la même façon un affichage clair du calcul b/c et relancez à nouveau l'expérience vous constaterez sans surprise que la division entière d'un entier par un autre qui lui est supérieur donne systématiquement 0 ; la multiplication de a par ce résultat partiel ne peut être que nulle.
De cette investigation infructueuse, nous retiendrons que la division entière doit intervenir le plus tardivement possible dans le calcul pour éviter de faire disparaître une partie substantielle (voire l'intégralité) des informations contenues dans les entiers.

Pour confirmer le fait que les résultats aberrants proviennent de la multiplication, complétons à nouveau la fonction intComputation() pour lui ajouter un affichage clair du résultat du calcul a*b.
Fabriquez à nouveau le programme et exécutez-le afin de vérifier que cette multiplication donne bien des résultats inattendus en phase avec ceux du calcul complet initial.
En effet, un simple calcul mental confirme le fait que les valeurs atteintes par le résultat de cette multiplication ne tiennent pas dans la plage de valeurs couverte par le type int utilisé pour ces calculs.

Pour mener à bien ce calcul, nous n'avons pas d'autre choix que de recourir à des entiers de plus grande capacité.
Complétez alors à nouveau la fonction intComputation() pour lui ajouter ceci :

...
{
  ...
  int64_t wideA=a;
  int64_t wideB=b;
  int64_t wideC=c;
  int64_t wideResult=wideA*wideB/wideC;
  int result=(int)wideResult;
  printf("(int)(wideA*wideB/wideC) = %d\n", result);
}

Toutes les variables a, b et c ont été converties vers le type int64_t ici ; il aurait été possible de simplifier l'écriture en ne convertissant explicitement que a par exemple, et les autres opérandes auraient été implicitement promus.
Remarquez également que nous avons pris soin de n'effectuer la conversion vers le type int qu'à la toute fin du calcul, une fois que la division a produit une valeur qui puisse être représentée par ce type.
Une nouvelle fabrication et relance de ce programme doit enfin donner les résultats escomptés même lorsque les paramètres ont des valeurs élevées.

Bien que les paramètres d'un calcul respectent la plage de valeurs du type choisi, et qu'il en est de même pour le résultat théoriquement attendu, nous retiendrons de cet exemple qu'il est néanmoins possible que le résultat d'une opération intermédiaire provoque un débordement de capacité.
Ceci est particulièrement fréquent concernant les multiplications.
Il convient donc, dans le cadre d'un problème donné, de toujours s'interroger sur les plages de valeurs effectivement atteintes par les paramètres d'un calcul afin d'évaluer les risques de débordement de capacité lors des opérations intermédiaires✍.

{} Promotion automatique des petits entiers

{} Les limites des réels

Le langage C propose trois types pour représenter des valeurs réelles✍ : float, double et long double.
(https://en.cppreference.com/w/c/language/arithmetic_types)
Même si la forme de leur représentation n'est pas strictement spécifiée dans la norme du langage C, dans la pratique ils respectent très souvent la norme IEEE754.
(https://en.wikipedia.org/wiki/IEEE_floating_point)
Cette représentation repose sur un bit indiquant le signe (positif ou négatif), une mantisse (une série de bits valant chacun 1/2^N) et un exposant (une puissance de deux positive ou négative) appliqué à cette mantisse.
Observez quelques valeurs réelles avec cet outil : (https://www.h-schmidt.net/FloatConverter/IEEE754.html)

{} L'arrondi de la représentation réelle

Puisque les types représentant une valeur réelle en langage C ne peuvent avoir une représentation de longueur infinie, cet exercice vise à mettre en évidence l'effet de l'arrondi qu'ils introduisent.

Vous devez maintenant déclarer dans typeProperties.h et définir dans typeProperties.c cette nouvelle fonction :

void
realRounding(double step)
{
  printf("\n~~~~ realRounding(%g) ~~~~\n", step);
  double three=3.0;
  for(double d=0.0; d<6.0; d+=step)
  {
    printf("d=%g\tdelta=%g\n", d, d-three);
    if(d==three)
    {
      printf("found three!\n");
      break;
    }
  }
}

Faites l'effort d'analyser attentivement le code source de cette fonction ; vous devriez constater notamment que :

la boucle for accumule de manière répétée sur d la valeur de step jusqu'à ce que d atteigne ou dépasse 6.0,
la valeur de d et son écart à 3.0 sont affichés à chaque itération,
l'alternative simple tente de détecter si une des valeurs successives de d vaut exactement 3.0,
dans ce cas, un message le signale explicitement et la boucle est interrompue brutalement.

Il faudra ajouter au programme principal du fichier prog03.c un appel à cette fonction avec la valeur 0.375 comme paramètre.
Fabriquez à nouveau le programme et exécutez-le afin d'observer la séquence des valeurs réelles affichée.
Les incréments successifs de 0.375 finissent par atteindre exactement la valeur 3.0 ce qui met fin à la boucle : c'est effectivement le résultat attendu puisque huit accumulations de 0.375 valent bien 3.0.

Intervenez maintenant dans le programme principal pour ajouter un nouvel appel à la fonction realRounding() en utilisant cette fois-ci la valeur 0.3 comme paramètre et relancez l'expérience.
La nouvelle séquence de valeurs obtenue semble bien passer par la valeur 3.0 mais se poursuit sans s'interrompre jusqu'à approcher de 6.0.
Pourtant, d'un point de vue arithmétique, dix accumulations de 0.3 donnent bien exactement la valeur 3.0 !

Dans le but d'investiguer autour de cette incohérence, intéressons nous à l'affichage de l'écart entre d et 3.0.
En particulier, aux abords de 3.0 cet écart n'est pas nul mais infinitésimal.
L'affichage de la valeur 3.0 exacte pour d n'est due qu'aux options de formatage par défaut de la fonction printf() qui, pour un meilleur confort visuel, choisit de n'écrire qu'un nombre raisonnable de décimales ; la vraie valeur de d n'est donc pas strictement égale à 3.0 mais en diffère très légèrement.

Pour comprendre la raison de cet écart, raisonnons en base dix.
La valeur 1/4 se représente exactement par 0.25 et quatre accumulations de cette valeur donnent bien le résultat 1.0.
En revanche, une valeur comme 1/3 nécessiterait une infinité de décimales valant 3 pour être représentée exactement.
Si nous n'en retenons arbitrairement que six, cette valeur est arrondie à 0.333333.
Accumuler trois fois cette valeur donne le résultat 0.999999 qui est certes très proche de 1.0 mais n'y est toutefois pas strictement égal.
Un raisonnement similaire peut être tenu en ne retenant qu'un nombre limité de chiffres après la virgule en base deux.

Pour revenir à notre programme, la valeur 0.375 est une somme de puissances négatives de deux (1/4 et 1/8) et se représente donc dans la mantisse d'un réel par un motif binaire fini.
Veuillez le vérifier avec cet outil :
(https://www.h-schmidt.net/FloatConverter/IEEE754.html)
Huit accumulations de ce motif fini donnent bien un autre motif fini valant exactement 3.0.
En revanche, la valeur 0.3 se représente par un motif binaire infini ; il sera donc tronqué dans la mantisse.
Veuillez le vérifier avec le même outil interactif.
Dix accumulations de cette valeur produisent une propagation de la troncature et finissent par donner une valeur légèrement différente de 3.0.

Bien que les types réels du langage C permettent d'exprimer une très grande variété de valeurs à virgule flottante, nous retiendrons de cet exemple qu'il existe des valeurs qui ne peuvent pas être représentées exactement.
L'accumulation des arrondis dans les calculs peut alors produire des résultats contre-intuitifs.
Par conséquent, il est généralement incorrect de tester une égalité stricte sur des nombres réels puisque les valeurs attendues d'un point de vue arithmétique risquent de ne pas être obtenues en pratique ; il vaut mieux s'appuyer sur les inégalités.

{} Les ordres de grandeur des valeurs réelles

Contrairement aux types entiers, les types réels du langage C offrent l'avantage de représenter des valeurs à la fois très grandes et très petites.
Nous nous proposons ici d'explorer ces limites.

Vous devez maintenant déclarer dans typeProperties.h et définir dans typeProperties.c cette nouvelle fonction :

void
realLimits(float step)
{
  printf("\n~~~~ realAccumulation(%g) ~~~~\n", step);
  printf("FLT_MIN = %g\n", FLT_MIN);
  printf("FLT_MAX = %g\n", FLT_MAX);
  printf("DBL_MIN = %g\n", DBL_MIN);
  printf("DBL_MAX = %g\n", DBL_MAX);
  float accum=0.0f;
  for(int i=0; ; ++i)
  {
    float prev=accum;
    accum+=step;
    if(prev==accum)
    {
      printf("stalled after %d steps (%g)\n", i, accum);
      break;
    }
  }
}

Faites l'effort d'analyser attentivement le code source de cette fonction ; vous devriez constater notamment que :

quatre constantes fournies par le fichier d'en-tête standard
```
<float.h>
```
nous indiquent les limites des types float et double,
(https://en.cppreference.com/w/c/types/limits)
une boucle for, en apparence infinie, compte ses itérations,
à chacune d'elles le paramètre step est accumulé sur la variable accum,
l'alternative simple tente de détecter le cas où, malgré l'accumulation, la variable accum reste égale à sa valeur précédente,
dans ce cas, un message le signale explicitement et la boucle est interrompue brutalement.

Il faudra ajouter au programme principal du fichier prog03.c un appel à cette fonction avec la valeur 0.125f✍ comme paramètre.
Fabriquez à nouveau le programme et exécutez-le afin de constater, dans un premier temps, les ordres de grandeur annoncés pour les types float et double : celles-ci sont assez impressionnantes, même dans le cas de réels en simple précision✍.

Ajoutons maintenant de nouveaux appels à realLimits() avec comme paramètre 0.1f, 0.5f, 100.0f et 512.0f.
Intéressons-nous alors à la boucle qui détecte le moment où les accumulations n'ont plus d'effet ; le nombre d'itérations est du même ordre de grandeur dans tous les cas et il est même égal pour les incréments qui sont des puissances positives ou négatives de deux.

L'anomalie d'accumulation détectée ici est d'autant plus surprenante que la valeur de l'incrément et celle de la valeur accumulée sont bien loin des limites connues pour le type float.
L'explication tient à nouveau dans la troncature de la mantisse des réels.
Si en base dix nous souhaitons ajouter l'incrément 0.1 à un réel valant déjà un million, tout en ne conservant que six décimales, le résultat sera représenté par 1.000000*10⁶ : l'incrément est perdu car il figure au-delà des décimales retenues.
Un raisonnement similaire peut être tenu avec la représentation binaire de la mantisse de notre variable accum.
Elle n'est constituée que de vingt-quatre bits✍, donc l'ajout d'un incrément à une valeur qui est plus de 2²⁴ fois plus grande ne peut en aucun cas modifier cette dernière.
Pour vous en convaincre, confrontez donc le nombre d'itérations constatées pour les incréments qui sont des puissances de deux à cette grandeur.
Remarquez que le même phénomène peut se produire sur une variable de type double ; toutefois, l'échéance sera bien plus tardive puisque la mantisse est constituée de cinquante-trois bits.

Bien que les types réels du langage C peuvent recouvrir des valeurs allant de l'infiniment grand à l'infiniment petit, nous retiendrons de cet exemple que le calcul sur des réels dont les valeurs relatives sont extrêmement éloignées donne très probablement un résultat aberrant.
Ceci est particulièrement flagrant avec le type float, c'est pourquoi nous lui préférons en général le type double✍.
Par extension, le calcul de la différence entre deux valeurs réelles très proches l'une de l'autre ne sera exprimé qu'avec une très mauvaise précision (seuls quelques bits à la fin de leurs mantisses respectives diffèrent).

Complément : application au développement en série

Nous réutilisons ici, à une fin d'entraînement, les propriétés constatées sur les réels vis-à-vis des très faibles incréments pour approximer la fonction mathématique de logarithme naturel par le développement en série suivant :

Il s'agit en effet d'accumuler des incréments de plus en plus faibles au fur et à mesure que l'ordre du développement augmente.
Le choix préalable et arbitraire d'un ordre maximal introduirait un arrondi du résultat alors que le réel serait en mesure de représenter plus précisément le résultat théorique attendu.
Nous procéderons donc comme dans l'exemple précédent en itérant jusqu'à détecter un incrément ne produisant plus d'effet sur la valeur accumulée : la valeur recherchée aura ainsi été atteinte avec la précision maximale.

Vous devez maintenant déclarer dans typeProperties.h et définir dans typeProperties.c cette nouvelle fonction :

double
computeLog(double x)
{
  double s=(x-1.0)/(x+1.0);
  double t=2.0*s;
  double y=t;
  double s2=s*s;
  for(int k=1; ; ++k)
  {
    t*=s2;
    double delta=t/(2*k+1);
    double prev=y;
    y+=delta;
    if(prev==y)
    {
      // printf("x=%g  k=%d  y=%g  delta=%g\n", x, k, y, delta);
      break;
    }
  }
  return y;
}

Faites l'effort d'analyser attentivement le code source de cette fonction en confrontant le principe retenu et la formule donnée.

Il faudra ajouter au programme principal du fichier prog03.c une boucle d'appel à cette fonction pour des valeurs réelles allante de 0.2 à 3.0 par pas de 0.2.
À chaque itération il faudra afficher clairement le paramètre et le résultat afin de contrôler a posteriori les valeurs obtenues.
Fabriquez à nouveau le programme et exécutez-le afin d'observer les valeurs produites par ces calculs.
Vérifiez que les valeurs obtenues sont correctes en vous aidant d'une calculette ou simplement de l'interpréteur Python (fonction math.log()).

Complément : étude de l'évolution des variables au débogueur

Nous profitons de l'exemple précédent précédent pour nous familiariser avec quelques fonctionnalités du débogueur : il s'agit d'observer l'évolution des variables.
Le fichier GNUmakefile qui vous a été fourni spécifie déjà l'usage de l'option -g lors de l'invocation du compilateur.
Au lancement de l'outil de débogage : $ tdb_prc prog03 ↵ notre programme est initialement en pause ; la toute première ligne de la fonction main() est mise en surbrillance pour indiquer qu'il s'agit de la prochaine ligne de code qui sera exécutée.

Nous procéderons à l'investigation selon les étapes suivantes :

un double-clic dans la zone d'affichage du code source, juste sur la ligne qui provoque l'appel à la fonction computeLog(), place un point-d'arrêt matérialisé par un changement de couleur,
le bouton Continue [F8] (triangle) permet de lancer l'exécution du programme,
- tout le début du programme s'exécute normalement puis la zone de messages indique que le programme est arrêté sur le point-d'arrêt,
un nouveau double-clic sur la même ligne annule ce point-d'arrêt,
le bouton Step [F5] (entrée dans les accolades) permet d'atteindre la prochaine ligne de code dans le programme,
- nous sommes désormais sur la première ligne de la fonction computeLog() et la zone de messages nous indique la valeur de son paramètre,
un double-clic sur la ligne qui déclare prev à l'intérieur de la boucle place un nouveau point-d'arrêt,
le bouton Continue [F8] relance l'exécution,
- la zone de messages nous indique que nous avons atteint ce nouveau point d'arrêt,
après avoir surligné le compteur de boucle k, le bouton Show selected variable (paire de lunettes) affiche dans la zone de message la valeur de cette variable,
- il est tout aussi simple de saisir print k ou encore p k sur la ligne de commande située au bas de l'outil de débogage,
procédez de la même façon pour afficher la valeur de x et de delta,
- remarquez également que le menu Show/Locals produit l'affichage de toutes les variables locales,
le bouton Continue [F8] relance l'exécution,
- la zone de messages nous indique que nous avons atteint une nouvelle fois le même point d'arrêt,
reprenez l'affichage des variables pour constater que nous avons effectué une nouvelle itération,
l'usage de la commande display (ou du bouton) en lieu et place de la commande print provoquera l'affichage des variables concernées à chaque arrêt,
- utilisez le bouton Continue [F8] plusieurs fois pour constater l'enchaînement des affichages automatiques dans la zone de messages,
  - les itérations sont nombreuses lorsque x vaut 0.2,
un nouveau double-clic sur la ligne du point-d'arrêt annule celui-ci,
saisissez break NUM if x>1.1 sur la ligne de commande située au bas de l'outil de débogage en remplaçant NUM par le numéro de ligne de l'ancien point-d'arrêt,
- ce point-d'arrêt ne sera bloquant que si la condition est respectée,
le bouton Continue [F8] relance l'exécution,
- plusieurs invocations de la fonction computeLog() ont lieu,
- la zone de messages nous indique que nous avons atteint le point d'arrêt et affiche les variables qui avaient été préalablement sélectionnées avec la commande display,
utilisez le bouton Continue [F8] plusieurs fois pour constater l'enchaînement des affichages automatiques dans la zone de messages,
- les itérations sont peu nombreuses lorsque x vaut 1.2,
nous quittons la session de débogage en fermant simplement la fenêtre de l'outil.

L'utilisation qui a été faite du débogueur ici visait à illustrer la démarche très classique qui consiste à inspecter l'état des variables au fil de l'exécution du programme.
Nous avons notamment fait usage d'un point-d'arrêt conditionnel afin de ne bloquer l'exécution que lorsque les variables sont dans un état propice à une observation que nous souhaitons mener.
Ceci peut aider à la mise au point d'un programme en recherchant la cause qui est à l'origine de la production d'un résultat inattendu.

Code source de l'expérimentation

Si chaque étape a été respectée scrupuleusement, vous devez obtenir des fichiers de code source et semblables à ceux-ci :

Fichier typeProperties.h✎

Fichier typeProperties.c✎

Contenu du fichier typeProperties.c

//----------------------------------------------------------------------------

#include "typeProperties.h"

#include <stdio.h>
#include <stdbool.h>
#include <stdint.h>
#include <limits.h>
#include <float.h>

void
displaySize(void)
{
  printf("\n~~~~ displaySize() ~~~~\n");
  printf("sizeof(size_t)      = %d\n", (int)sizeof(size_t)     );
  printf("sizeof(bool)        = %d\n", (int)sizeof(bool)       );
  printf("sizeof(char)        = %d\n", (int)sizeof(char)       );
  printf("sizeof(short)       = %d\n", (int)sizeof(short)      );
  printf("sizeof(int)         = %d\n", (int)sizeof(int)        );
  printf("sizeof(long)        = %d\n", (int)sizeof(long)       );
  printf("sizeof(long long)   = %d\n", (int)sizeof(long long)  );
  printf("sizeof(float)       = %d\n", (int)sizeof(float)      );
  printf("sizeof(double)      = %d\n", (int)sizeof(double)     );
  printf("sizeof(long double) = %d\n", (int)sizeof(long double));
  printf("sizeof(int8_t)      = %d\n", (int)sizeof(int8_t)     );
  printf("sizeof(int16_t)     = %d\n", (int)sizeof(int16_t)    );
  printf("sizeof(int32_t)     = %d\n", (int)sizeof(int32_t)    );
  printf("sizeof(int64_t)     = %d\n", (int)sizeof(int64_t)    );
  printf("sizeof(uint8_t)     = %d\n", (int)sizeof(uint8_t)    );
  printf("sizeof(uint16_t)    = %d\n", (int)sizeof(uint16_t)   );
  printf("sizeof(uint32_t)    = %d\n", (int)sizeof(uint32_t)   );
  printf("sizeof(uint64_t)    = %d\n", (int)sizeof(uint64_t)   );
}

void
intOverflow(int limit)
{
  printf("\n~~~~ intOverflow(%d) ~~~~\n", limit);
  for(int i=0; i<limit; ++i)
  {
    // uint16_t other=(uint16_t)i;
    int16_t other=(int16_t)i;
    if(other!=i)
    {
      printf("%d has been turned into %d\n", i, other);
      break;
    }
  }
  printf("UINT16_MAX = %d\n", UINT16_MAX);
  printf("INT16_MIN  = %d\n", INT16_MIN);
  printf("INT16_MAX  = %d\n", INT16_MAX);
  printf("INT_MIN    = %d\n", INT_MIN);
  printf("INT_MAX    = %d\n", INT_MAX);
  printf("CHAR_MIN   = %d\n", CHAR_MIN);
  printf("CHAR_MAX   = %d\n", CHAR_MAX);
}

void
tributeToChuck(void)
{
  printf("\n~~~~ tributeToChuck() ~~~~\n");
  // typedef uint32_t TestInt;
  typedef uint16_t TestInt;
  int loopCount=0;
  TestInt prev=0;
  for(TestInt i=0; ; ++i)
  {
    if(i<prev)
    {
      ++loopCount;
      printf("Chuck Norris counted to infinity - ");
      switch(loopCount)
      {
        case 1:
        {
          printf("once\n");
          break;
        }
        case 2:
        {
          printf("twice\n");
          break;
        }
        default:
        {
          printf("%d times\n", loopCount);
          break;
        }
      }
      if(loopCount>2)
      {
        printf("then the numbers broke down!\n");
        break;
      }
    }
    prev=i;
  }
}

void
intComputation(int a,
               int b,
               int c)
{
  printf("\n~~~~ intComputation(%d, %d, %d) ~~~~\n", a, b, c);
  printf("a*b/c = %d\n", a*b/c);
  printf("a*(b/c) = %d\n", a*(b/c));
  printf("b/c = %d\n", b/c);
  printf("a*b = %d\n", a*b);
  int64_t wideA=(int64_t)a;
  int64_t wideB=(int64_t)b;
  int64_t wideC=(int64_t)c;
  int64_t wideResult=wideA*wideB/wideC;
  int result=(int)wideResult;
  printf("(int)(wideA*wideB/wideC) = %d\n", result);
}

void
intPromotion(void)
{
  printf("\n~~~~ intPromotion() ~~~~\n");
  int8_t a8=3, b8=7, c8=(int8_t)(a8+b8);
  printf("sizeof(c8)=%d sizeof(a8+b8)=%d\n",
         (int)sizeof(c8), (int)sizeof(a8+b8));
  int16_t a16=3, b16=7, c16=(int16_t)(a16+b16);
  printf("sizeof(c16)=%d sizeof(a16+b16)=%d\n",
         (int)sizeof(c16), (int)sizeof(a16+b16));
  int32_t a32=3, b32=7, c32=a32+b32;
  printf("sizeof(c32)=%d sizeof(a32+b32)=%d\n",
         (int)sizeof(c32), (int)sizeof(a32+b32));
  int64_t a64=3, b64=7, c64=a64+b64;
  printf("sizeof(c64)=%d sizeof(a64+b64)=%d\n",
         (int)sizeof(c64), (int)sizeof(a64+b64));
}

void
realRounding(double step)
{
  printf("\n~~~~ realRounding(%g) ~~~~\n", step);
  double three=3.0;
  for(double d=0.0; d<6.0; d+=step)
  {
    printf("d=%g\tdelta=%g\n", d, d-three);
    if(d==three)
    {
      printf("found three!\n");
      break;
    }
  }
}

void
realLimits(float step)
{
  printf("\n~~~~ realAccumulation(%g) ~~~~\n", step);
  printf("FLT_MIN = %g\n", FLT_MIN);
  printf("FLT_MAX = %g\n", FLT_MAX);
  printf("DBL_MIN = %g\n", DBL_MIN);
  printf("DBL_MAX = %g\n", DBL_MAX);
  float accum=0.0f;
  for(int i=0; ; ++i)
  {
    float prev=accum;
    accum+=step;
    if(prev==accum)
    {
      printf("stalled after %d steps (%g)\n", i, accum);
      break;
    }
  }
}

double
computeLog(double x)
{
  double s=(x-1.0)/(x+1.0);
  double t=2.0*s;
  double y=t;
  double s2=s*s;
  for(int k=1; ; ++k)
  {
    t*=s2;
    double delta=t/(2*k+1);
    double prev=y;
    y+=delta;
    if(prev==y)
    {
      // printf("x=%g  k=%d  y=%g  delta=%g\n", x, k, y, delta);
      break;
    }
  }
  return y;
}

//----------------------------------------------------------------------------

Fichier prog03.c✎