[Debutant] Regles surcharge fonctions

Merci pour les reponses je comprends mieux maintenant.
J'ai une autre question sur un autre sujet, j'aimerais savoir est ce qu'on peut envoyer une structure sur le flux standard de sortie (avec cout), par exemple si je declare une structure str comprenant un entier, un float et un char et que j'ecris l'instruction "str a;" puis "cout<<a; ", est ce que cela fonctionne, j'ai testé sur visual studio ca ne marche pas, est ce que je dois donc généraliser ou estce que c'est seulement dans des cas particuliers que ca ne marche pas?
Merci

Bonjour
l'opérateur << est définie pour les types de base du language non pas pour les types définie par l'utilisateur dans ce cas vous pouvez surcharger cet opérateur
exemple:

Code:

---

1 2 3 4 5

ostream& operator << (ostream& os, const str& s) { return os<<s.nom<<'\t'<<s.note<<endl; }

---

Citation:

---

Envoyé par poukill

Attention, convertir 5 de int en float fait aussi perdre des données, car le résultat va certainement donner quelquechose comme ça :
5.000000007 Ceci est dû au codage interne des nombres flottants !

---

Citation:

---

Envoyé par JolyLoic

Sauf erreur de ma part (ce n'es pas mon domaine, donc risque d'erreurs), une telle erreur ne peut pas arrive, un nombre entier petit étant représentable de manière exacte.

---

Je ne connais pas de formats de flottants ou les entiers suffisamment petits ne soient pas représentables et même si ça ne garanti pas que la conversion de l'entier 5 en flottant donne le flottant 5.0, il y a bien peu de risques d'avoir une implémentation d'aussi faible qualité.

A noter, dans la plupart des formats de flottants, la plupart des fractions decimales ne sont pas representables. Donc 1.1 n'est pas representable et on a donc bien une valeur legerement plus petite ou plus grande. De meme pour 0.1. Et il y a peu de chances que ces arrondis se compensent pour que la soustraction du resultat des deux conversions fasse exactement 1.0.

Salut,

De fait, quand un int est converti en double (ou en float) on peut effectivement se trouver face à une différence, mais, tout bien mesuré, la différence ne pourra jamais excéder le delta du type réel pour la conversion ;)

On peut donc parfaitement envisager un 1 (int) qui, converti en float, vaille 0.000000009 ou, au contraire, qui vaille 1.000000001, mais ce sera le plus souvent parce que c'est le delta pour les float, et le raisonnement peut etre suivi à l'identique pour les double ;)

Et c'est d'ailleurs exactement le raisonnement qui fait que les (bons) compilateurs (bien réglés) nous signalent qu'une égalité entre deux réels est toujours fausse, du fait de ce fameux delta (que l'on peut utiliser en incluant <limits> ;))

Sur mon message plus haut, j'avais donné le lien vers la FAQ qui en parlait ! ;)

Citation:

---

Envoyé par koala01

On peut donc parfaitement envisager un 1 (int) qui, converti en float, vaille 0.000000009 ou, au contraire, qui vaille 1.000000001

---

Je n'envisage pas. C'est formellement conforme mais je n'envisage pas qu'une implementation aussi bizarre puisse se retrouver sur le marche.

Citation:

---

Et c'est d'ailleurs exactement le raisonnement qui fait que les (bons) compilateurs (bien réglés) nous signalent qu'une égalité entre deux réels est toujours fausse,

---

L'egalite entre reel a toujours un sens. L'egalite entre flottants est plus delicate a maitriser -- en particulier si on veut savoir quand on peut tester l'egalite entre deux resultats de calcul -- mais il y a des cas ou elle a un sens.

Les flottants sont perturbants parce que
1/ des nombres apparemment simples ne sont pas representables
2/ des nombres apparemment simples ne sont pas representables
3/ ce ne sont pas des reels

Apparemment la plupart des gens ne vont pas plus loin que de remarquer que les resultats leur semble etranges pour ces deux raisons et en concluent que l'utilisation de flottants introduits des imprecisions de maniere impredictibles. La constation est correcte -- l'utilisation de flottants donne des resultats etranges quand on n'a pas compris les consequences de ces deux points -- mais la conclusion est fausse -- les flottants sont maitrisables et quand on le fait on peut avoir des resultats d'une precision predictible.

Ne voulais-tu pas dire 0.999999999 ?

Citation:

---

Envoyé par Médinoc

Ne voulais-tu pas dire 0.999999999 ?

---

Si bien sur... Mais bon, on avait compris ! ;)
C'est comme Jean-Marc qui a mis 3 points au lieux de deux... :mrgreen:

En tout cas, je suis d'accord. Il existe une discipline entière pour ça qui s'intitule "calcul scientifique" et il est bon de connaitre comment sont représentés les flottants en mémoire (mantisse, exposant) et les dangers de divergence d'un algorithme avec un problème mal posé / matrice mal conditionnée...

Citation:

---

Envoyé par poukill

C'est comme Jean-Marc qui a mis 3 points au lieux de deux... :mrgreen:

---

Comme ce genre de techniques pas mal dans ce média, je précise que c'était volontaire.

Citation:

---

Envoyé par poukill

Il existe une discipline entière pour ça qui s'intitule "calcul scientifique" et il est bon de connaitre comment sont représentés les flottants en mémoire (mantisse, exposant) et les dangers de divergence d'un algorithme avec un problème mal posé / matrice mal conditionnée...

---

Tout à fait. En fait, le calcul scientifique en général s'accommode souvent des imprécisions raisonnables, s'il le faut en utilisant des astuces de type GMP (par exemple souvent bien suffisant pour résoudre des problèmes différentiels dits "stiff"). Par contre, certains domaines sont hyper sensibles, comme la géométrie algorithmique, qui prend des décisions logiques Vrai/Faux sur des résultats de calculs compliqués (cette intersection de 3 plans est-elle bien dans le cylindre que ce triangle génère une fois extrudé selon la normale à ce NURBS coupé par la droite z=x=8?). Et là, GMP est trop grossier car n'alloue pas la précision en fonction du besoin, mais de l'historique de calcul, ce qui est catastrophique pour les algorithmes qui doivent retourner une géométrie dans la même représentation que la géométrie d'entrée (perte des propriétés logiques durant la "cristallisation").
Baignant dans ces problèmes depuis 1993, c'est avec reconnaissance que je vous présente un lien vers notre sauveur à tous (en tout cas nous dans notre pti coin de la géométrie algorithmique): j'ai nommé la fameuse Cigale! En 1993, on n'avait rien de comparable ou même d'approchant, eh bien on était tous très dans la m...
Cigale est non seulement très puissante, mais surtout vivace, en pleine force de l'age en ce qui concerne le soutien international de qualité, l'évolution, et même le support aux projets commerciaux au travers de la structure Geometry Factory.
Comme quoi une discussion qui dérape peut être très intéressante!

Merci pour le lien, :D
dans certains cas les algorithme peuvent être très sensible même pour une petite approximation par exemple en CSG (constructive solid geometry)

Effectivement j'utilise beaucoup cette bibliothèque, elle est excellente... ;)

personnellement j'utilise CLN
http://www.ginac.de/CLN/