Quelques précisions. . .

Citation:

---

Envoyé par Array

Whew! 264 pages. Je n'y manquerai pas, étant donné que j'aime particulièrement jouer avec des nombres à virgule. Cependant, je vais attendre de finier de lire mon autre bouquin sur le C.

---

Moi je vois 94 pages... C'est gérable si ton objectif est de faire du calcul numérique et/ou de travailler intensivement avec les nombres à virgule flottante.

Thierry

Tu as raison. Je m'excuse j'ai mal regardé le nombre de pages. 94 pages. J'en ai 5 de faites lol. C'est un anglais clair, donc assez facile à suivre.

Je ramène également ma question, même si c'est probablement inutile.
C'est que je veux vraiment le savoir, car j'ai fait plusieurs programmes qui utilisent volontairement la troncature eet qui ne foncctionneraient pas sans elle.

Donc, est-il bien de tirer profit de la troncature des nombres à virgules dans les variables de type integer(entier)?

Par exemple comme dans l'exemple que j'ai donné. Qu'en pensez-vous?

Bonjour,

J'aimerais savoir si l'on peut donner de nouvelles valeurs aux macros de float.h.

Par exemple, FLT_EPSILON ou DBL_MAX ?

Peut-on simplement utiliser #define!?

Code:

---

1 2 3 4 5 6

#include <stdlib.h> #include <float.h> #define DBL_EPSILON 1e-20   [...]

---

Je ne crois pas que ce code serait valide, mais peu importe... Je ne fais que me questionner.

Merci,

Array

Tu peux.
Et si ça gueule, tu peux faire quelques #undef avant...

Par contre, je ne vois pas trop l'intéret (SURTOUT pour FLT_MAX)...

Tu peux mais ça n'a aucun intérêt parce que ces valeurs sont là à titre indicatif et les changer ne changera en rien la précision ou les bornes des nombres...

Citation:

---

Envoyé par Array

J'aimerais savoir si l'on peut donner de nouvelles valeurs aux macros de float.h.

Par exemple, FLT_EPSILON ou DBL_MAX ?

Peut-on simplement utiliser #define!?

Code:

---

1 2 3 4

#include <stdlib.h> #include <float.h> #define DBL_EPSILON 1e-20

---

Je ne crois pas que ce code serait valide, mais peu importe... Je ne fais que me questionner.

---

C'est techniquement possible (avec un #undef) , mais le comportement devient indéterminé car une information appartenant à l'implémentation a été modifiée.

Si tu veux ton propre EPSILON, utilise ton #define :

Code:

---

#defne MY_ESPILON (1e-20)

---

Eh bien.
Alors comment changer les comprtements rattachés aux macros de la bibliothèque standard? Si changer ces macros ne sert à rien...

Merci,

Array != 0

Citation:

---

Envoyé par Array

Eh bien.
Alors comment changer les comprtements rattachés aux macros de la bibliothèque standard? Si changer ces macros ne sert à rien...

Merci,

Array != 0

---

Qu'entends-tu exactement par "changer les comportements rattachés aux macros"? Ce n'est pas en changeant la valeur de DBL_EPSILON que tu pourras augmenter la précision d'un flottant de type double.

Thierry

Citation:

---

Envoyé par Array

Alors comment changer les comportements rattachés aux macros de la bibliothèque standard? Si changer ces macros ne sert à rien...

---

Il n'y a pas à "changer le comportement de la bibliothèque standard". Pourquoi veux-tu faire ça ? Le comportent est en grande partie définie par la norme et le reste par l'implémentation.

En tant que programmeur, tu utilises cet outil, mais tu n'as absolument pas le droit de le modifier.

Que cherches-tu à faire exactement ?

Ah veuillez excuser le déficit de clarté que comportent mes propos.

Ce que je crois (plutôt ce que je croyais, car il semble que je me sois trompé), c'est qu'en changeant certains macros de la Bibliothèque Standard, on pouvais changer le comportement de la machine, et, par le fait même, le comportement des programmes.

Par exemple, en changeant FLT_EPSILON ou FLT_ROUNDS, si je fais (1.456 * 10), au lieu de donner 14.559999, la machine donnerait le vrai résultat, soit 14.56.

C'est ce que je veux dire.

Je croyais que si je changeais FLT_MAX, je pourrais par exemple, augmenter la valeur maximale que peut accepter un FLOAT.


Ce que je voudrais savoir, c'est si l'on peut changer ces comportements. . .
Je crois m'apercevoir, en voyant vos messages, que les macros de la StdBiblio ne sont qu'à titre indicatif, afin de donner au programmeur/ingénieur des informations sur la machine.

Si c'est bien cela, je découvre cependant que je pourrais arrondir 14.559999 en 14.56 en utilisant DBL_EPSILON.

Si cette question semble idiote - même si EmDel me prie de ne pas utiliser ce mot pour qualifier mes questions - pour plusieurs d'entre vous, je m'en excuse humblement. Veuillez excuser mon manque d'expérience, et si j'ai commis une bévue, vos réponses la corrigeront.


Cordialement,

Array

En effet, tu t'es fourré le doigt dans l'oeil jusqu'à l'épaule :D

Comme je l'ai dit plus haut, les macros ne sont là qu'à titre indicatif, elle t'indique comment, dans le processeur, les variables sont conçues, mais le processeur c'est du matériel gravé et immuable, tu peux en changeant du texte changer son comportement.

Citation:

---

Envoyé par Array

Ce que je crois (plutôt ce que je croyais, car il semble que je me sois trompé), c'est qu'en changeant certains macros de la Bibliothèque Standard, on pouvais changer le comportement de la machine, et, par le fait même, le comportement des programmes.

---

Absolument pas. Il est absolument interdit de bricoler quoique ce soit dans les headers fournis par l'implémentation.

Je ne vois pas ce qui a pu te faire croire ça. Si tu trouves un livre ou un tutoriel qui dit que c'est possible, cite-le qu'on le brule en place publique immédiatement.

O_o lol :bug: :arf:

:resolu: pour ce qui est de cela. xD

Cependant, voilà que je fais malencontrueusement face à un autre problème.

Lorsque j'exécute ce code :

Code:

---

1 2 3 4 5 6 7 8

#include <stdio.h> #include <limits.h>   int main(void) { printf("\n%d\n", LLONG_MAX); return 0; }

---

J'obtiens une erreur!?

Le programme écrit :

Citation:

---

-1

---

Pourquoi!?

Compilé avec GCC. . .

Serais-ce ma machine qui n'est pas conforme aux standards?!

Merci. Cordialement,

Array

Une erreur de compilation ou un warning ?
Si tu obtiens un erreur, tu ne peux pas exécuter ton programme.

Ensuite, c'est normal que tu n'obtiennes pas la valeur attendue car le formateur %d c'est pour les int, et toi tu lui passes un long long int, il faut mettre %lld (lettre "elle").

Citation:

---

Envoyé par Array

Code:

---

1 2 3 4

#include <limits.h> printf("\n%d\n", LLONG_MAX); }

---

---

Pour afficher un long long, il faut plus puissant qu'un simple %d... En principe, il faut un %lld. (et c'est le cas sur unixoide avec un gcc récent, c'est à dire > 3.0)

Mais sous Windows, même MinGW utilise la bibliothèque standard du C de Windows (msvcrt.dll) qui refuse toute évolution vers le C99 (Politique affichée de Microsoft).

Il faut donc utiliser le format "%I64" à la place de "%lld", ce qui donne,

Code:

---

1 2 3 4 5 6 7 8 9

#include <stdio.h> #include <limits.h>   int main(void) { printf("%I64d\n", LLONG_MAX); return 0; }

---

ou, si on veut être portable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <stdio.h> #include <limits.h>   #ifdef WIN32 #define LL "I64" #else #define LL "ll" #endif   int main(void) { printf("%"LL"d (%"LL"X)\n", LLONG_MAX, LLONG_MAX); return 0; }

---

Code:

---

1 2 3 4

9223372036854775807 (7FFFFFFFFFFFFFFF)   Press ENTER to continue.

---

o_O Merci Emmannuel. Je t'aime à la folie. :roll: ;)

P.S. Si je compile ton code avec GCC. Cela fonctionne parfaitement. Cependant, avec ICC [I = Intel, je suis sûr que tu le sais mais bon...], on me dit :

Citation:

---

Envoyé par ICC v10.0.026

cplc.c

Intel(R) C++ Compiler for applications running on IA-32, Version 10.0 Build 20070613 Package ID: W_CC_C_10.0.026
Copyright (C) 1985-2007 Intel Corporation. All rights reserved.

cplc.c(8): error: identifier "LLONG_MAX" is undefined
printf("%I64d\n", LLONG_MAX);
_______________^

compilation aborted for cplc.c (code 2)

---

Soit tu n'as pas inclus l'en-tête standard limits.h, soit le compilateur d'Intel n'implante pas C99 et type long long int (cela m'étonne...).

Thierry

Citation:

---

Envoyé par Thierry Chappuis

Soit tu n'as pas inclus l'en-tête standard limits.h, soit le compilateur d'Intel n'implante pas C99 et type long long int (cela m'étonne...).

---

Il faut peut être activer une option sur la ligne de commande...

Ha! En cherchant un peux j'ai trouvé.
ICC supporte le C99, et je l'éxécute toujourss avec /Qstd=c99.

En fait, c'est parce que le compilateur d'Intel utilise les en-têtes (fichiers .h) de Microsoft Visual Studio, et non ses propres fichiers d'en-tête comme GCC.

Ainsi, en cherchamt un peux j'ai trouvé que dans le fichier LIMITS.H de M$ Viual Studio, il n'y a pas de LLONG_MAX/ULLONG_MAX... LLONG_MAX correspont à _I64_MAX & ULLONG_MAX à _UI64_MAX.

Donc, pour résoudre ce problème :

Code:

---

1 2 3 4 5

#if defined(_WIN32) || defined (WIN32) #define LLONG_MAX _i64_MAX #define ULLONG_MAX _UI64_MAX #endif

---

Citation:

---

Envoyé par Array

En fait, c'est parce que le compilateur d'Intel utilise les en-têtes (fichiers .h) de Microsoft Visual Studio, et non ses propres fichiers d'en-tête comme GCC.

---

What ? Tu es sûr de ça ? Parce que ça me parait totalement absurde...