je bloque sur un calcul c++

[Olympe02]

Bonjour,

J'aimerai avoir une indice sur le calcul que je veux faire c'est celui là 10*0,10+ 8*0,09 // j'ai essayé ceci nb(0,10+0,09) mais je sais que c faux;

Voici l'énoncé:
un magasin de reprographie facture 0,10 euro les dix premieres photocopies, 0,09 euros les vingt suivantes et 0,08 euro au dela. Ainsi, 18 photocopies coutent 1,90 euros (10*0,10+8*0,09)
Ecrivez un algorithme qui demande à l'utilisateur le nombre de photocopies effectuées et qui affiche la facture correspondante. Vous veillerez à faire le moins possible de tests.

Voici mon code:

#include <iostream>

using namespace std;

int main()
{
float nb = 0;
float prix = 0;
cout << "Veuillez saisir le nombre de photocopies:" << endl;
cin >> nb;

if(nb <= 10) prix = nb * 0.1;
if(nb>10 && nb <= 30 )
cout << "Les photocopies coutent" << prix << endl;
return 0;
}

-----

[Jack]

if(nb <= 10) prix = nb * 0.1;
if(nb>10 && nb <= 30 ) 

le 2ème if n'est pas idéal. Il vaudrait mieux utiliser un else, ce qui éviterait le test "nb > 10"

Quant à la formule de calcul pour 18 photocopies, c'est une simple question de bon sens: comment ferais-tu le calcul avec un papier et un crayon?

A+

[Olympe02]

if(nb <= 10) prix = nb * 0.1;
if(nb>10 && nb <= 30 ) 

le 2ème if n'est pas idéal. Il vaudrait mieux utiliser un else, ce qui éviterait le test "nb > 10"

Quant à la formule de calcul pour 18 photocopies, c'est une simple question de bon sens: comment ferais-tu le calcul avec un papier et un crayon?

A+

ah oui c vrai pour le else Pour les 18 photocopies je ferai sur un papier: 10*0.10= 1 euros si je prend au dessus de 10 photocopie comme 18 ce qui fait que je rajoute 1 euros + les 8 photocopies par l'opération 8*0.09
donc ca fait prix = 1 + (nb-10)*0.09 // j'ai mis un pck 10*0.10= 1 euros et nb-10 pour les faire les 8 photocopies

pour le dernier c'est prix = 2,8+(nb-30)*0.08 // 2.8 vient du fait que (10*0.10)+(20*0.09)=2.8 euros pour 30 photocopies ensuite pour calculer au dela de 30 et multiplier par 0.08 on fait la différence ex: 34-30 avec les 4 photocopies on multiplie par 0.08

[Jack]

ah oui c vrai pour le else Pour les 18 photocopies je ferai sur un papier: 10*0.10= 1 euros si je prend au dessus de 10 photocopie comme 18 ce qui fait que je rajoute 1 euros + les 8 photocopies par l'opération 8*0.09
donc ca fait prix = 1 + (nb-10)*0.09 // j'ai mis un pck 10*0.10= 1 euros et nb-10 pour les faire les 8 photocopies

pour le dernier c'est prix = 2,8+(nb-30)*0.08 // 2.8 vient du fait que (10*0.10)+(20*0.09)=2.8 euros pour 30 photocopies ensuite pour calculer au dela de 30 et multiplier par 0.08 on fait la différence ex: 34-30 avec les 4 photocopies on multiplie par 0.08

Bin voilà. Comme quoi, il faut D'ABORD se demander comment on ferait sans ordi, PUIS SEULEMENT transcrire cette méthode en instructions.

A+

[A voir en vidéo sur Futura]

[Olympe02]

Bin voilà. Comme quoi, il faut D'ABORD se demander comment on ferait sans ordi, PUIS SEULEMENT transcrire cette méthode en instructions.

A+

Merci pour ton aide précieux et très utile

[bokan]

!!! ON N'UTILISE PAS DES FLOAT POUR DES PRIX !!!

Désolé pour les majuscules mais c'est super important. C'est une grossière erreur, on ne le répétera jamais assez et on voit trop de programmeurs se casser les dents avec ça parce qu’ils ont fait des exercices comme celui-ci.

Utilise des entiers et raisonne en centimes.

Tu peux ensuite diviser par 100 pour l'affichage si tu veux.

Les float sont utilisés pour stocker des valeurs approximatives. Des mesures scientifiques poids, distance, temps.....
De la même façon qu'il est impossible d'écrire 10/3 en décimal (ça fait 1,3333333....) il y a une foule de nombres que l'on ne peut pas stocker dans un float. On a l'impression que le nombre est correctement mémorisé puisque les fonction qui affichent ces chiffres corrigent l'apparence, mais ce n'est qu'une illusion.

Et si ton prof te dis qu'il faut stocker des prix dans des float, tu lui dira que c'est un tocard, qu'il a oublié les rudiments les plus élémentaires de ce que sont l'informatique et la programmation, et qu'il fait bien d'être prof parce qu'en prod il vaudrait pas tripette.

[Jack]

Tu peux développer ton raisonnement parce qu'en l'état il me semble incomplet:

admettons qu'on divise 1€ par 3. En prenant des entiers et en raisonnant en centimes, on va trouver 100/3, c'est à dire 33 centimes.

Prenons maintenant un float: 1/3 = 0.3333333, c'est à dire 33.333333 centimes

Quel résultat est le plus précis?

[bokan]

Jack : Le plus précis est 0.3333... et il est utile pour des unités scientifiques. Mais pour de la monnaie cette précision ne sers à rien et est source d'erreurs parce que tu ne peux pas payer 0.333333... centimes.

Le prix affiché est 33 ou 34 centimes pas 0.333333333€ ni 10/3 €.
Donc si tu doit payer 3 photocopies le prix doit être 99 ou 102 centimes et pas 0.9999999€.

Si tu essaie de stocker la valeur 0.1 dans un float, l'ordi stockera 0.0999999999999 et les fonctions d'affichage des float corrigent ça, ce qui donne l'impression qu'il a bien enregistré 0.1... mais non. Si on manipule, qu'on additionne en boucle l'erreur apparaît et pose problème parfois. On voit des factures ou le total TTC n'est pas égal au total HT + TVA. Des insertions en base de donnée qui foirent parce qu'une différence qui devrait être égale à 0 ne l'est pas et que le chiffre est converti string sous la forme en 0.1x10E-20 dans la requête SQL, etc...

Malheureusement vu que les fonctions d'affichage corrigent ces erreurs c'est pas facile des les mettre en évidence.
Tu as des tonnes d'articles sur le sujet : http://stackoverflow.com/questions/3...90782#15790782

[Jack]

je sais bien que les float ne sont qu'une discrétisation des réels (les vrais), mais que va-t-il arriver pour un calcul en chaine avec des entiers? Les erreurs vont s'accumuler.
Je ne comprends donc pas trop pourquoi on ne pourrait pas travailler avec un maximum de précision tout au long du calcul pour ne tronquer ou arrondir que lors des sorties.

[bokan]

Jack, tu n'as pas un maximum de précision avec les float, au contraire, tu insère plein d'approximations dans ton code.

Par exemple quand tu fais
float a=0.1;
Ton float contient en réalité 0.099999999999.... c'est pareil pour toutes les puissances de 10 (et beaucoup d'autres nombres)

Si tu fais
int b=10; (en centimes)
b contient exactement 10

[lou_ibmix_xi]

Je suis d'accord sur le fond avec bokan, mais pas sur la forme: le posteur initial débute vraissemblablement, la problématique du quand-comment-pourquoi utiliser de la virgule fixe ou de la virgule flottante le dépasse totalement et risque de l'embrouiller plus qu'autre chose.
Néanmoins, c'est effectivement un sujet essentiel pour "certains" domaines de l'informatique, mais pas tous, par exemple en traitement audio-numérique on s'en fiche totalement... Donc pour ceux que ça intéresse, il faut lire ce grand classique

[Jack]

bokan, tu n'as pas vraiment répondu à ma question concernant l'accumulation des erreurs.

Prenons un produit valant 1€. prix = 100 // en centimes
On décide de le vendre au tiers de son prix: en entier prix = 33.
On vend 1000 produits => prixTotal = prix * 1000 = 33000

en float maintenant: prix = 33.3333333
prix total = prix * 1000 = 33333.3333
si on arrondit au centime, on va afficher 33333.33

Le résultat juste est obtenu grâce aux float.

[bokan]

lou_ibmix_xi : Je dis juste qu'un prof qui fait faire un exercice où l'on traite de monnaie en utilisant de float est un naze. Il ne faut jamais faire ça, même si on n'en comprends pas les raisons, c'est une habitude à ne pas prendre.
Ils n'a qu'a transformer son exercice en coupant des planches de bois de longueurs différentes et je ne trouverai rien à redire. Je précise quand même que je n'ai vu que le code d'Olympe et je ne sais rien de son prof qui lui expliquera sans doute pourquoi il ne faut pas utiliser de float (mais j'en doute).

Il est important de savoir qu'on n'utilise pas des float pour la monnaie, ni pour les clé primaires. Si si j'ai déjà vu un chef de projet me soutenir qu'un float 32 bits permet d'avoir plus de lignes dans la table qu'un int32 puisqu'il va jusqu'à 3.4 × 10^38 !

L'utilisation de float pour des valeur monétaires est un problème récurrent dans les applis codés par des bricoleurs ou des élèves à qui on n'a pas appris les bases. Les conséquences sont parfois très importantes.

Ensuite je pense qu'il est important de commencer par les bases, de comprendre les type de données et comment ils sont stockés en mémoire. Ne pas utiliser de float tant qu'on sais pas ce que c'est. On voit souvent des applications très très lourdes pour rien. Il y a trop de lignes de code pas optimisées mais compensées par du hardware surdimensionné. Ok, ca coute moins cher d'acheter un quad Xeon octo coeur, hyperthreadés à 4Ghz avec 100Go de ram plutôt que payer un bon développeur qui pourrait faire tourner l'appli sur un 486DX2 66, ok on est en 2013 et c'est plus la peine de faire de l'assembleur, oui les langages managés font gagner en productivité. Mais faut pas faire abstraction de ce qui se passe sous le capot car tout cela consomme des et pollue, souvent pour rien... mais c'est un autre débat.

Sinon ton lien est très bien.

[bokan]

Jack : on ne vend jamais un produit à 100/3€. Si on décide de le vendre à un tiers de son prix on arrondi le prix unitaire à 33 centimes et on multiplie ensuite.
Regarde une facture, elle indique le prix unitaire (exact), la quantité et le prix total.
Sinon on vend un lot de 1000 machin à 33€.
Mais des prix avec des irrationnels ça n'existe pas dans la vie. Imagine : Super promo !Le kilo de courgettes à "racine de 2 €"/kilo !

Ma remarque ne concernait que les valeurs monétaires, si tu mesure autre chose, la découpe des bout de ficelles par exemple, là tu peut utiliser des float.

Même dans l'industrie financière où l'on gère les coefficients sur 6 chiffres après la virgule on n'utilise pas les float pour ces raisons.

[Jack]

ok, c'est noté

[Arzhur]

lou_ibmix_xi : Je dis juste qu'un prof qui fait faire un exercice où l'on traite de monnaie en utilisant de float est un naze. Il ne faut jamais faire ça, même si on n'en comprends pas les raisons, c'est une habitude à ne pas prendre.
Ils n'a qu'a transformer son exercice en coupant des planches de bois de longueurs différentes et je ne trouverai rien à redire

Non pas d'accord...s'il doit couper des planches de bois avec une forte contrainte de précision : c'est toujours un naze d'utiliser un float.

Ici, quand même, le calcul est tellement simple que la précision d'un float suffit largement.

[JPL]

Et comment on fait pour les prix au litre affichés sur les pompes à essence ?

[bokan]

Tu veux dire les prix avec trois chiffres après la virgule ? et bien tu raisonne en millimes. T'as vu je suis trop fort hein ?

[polo974]

Non pas d'accord...s'il doit couper des planches de bois avec une forte contrainte de précision : c'est toujours un naze d'utiliser un float.

Sauf qu'avec 24 bits de mantisse (23 stockés, le 24ème est gratuit (toujours à 1)), il faut y aller pour avoir des pb de dynamique...
Donc ce n'est pas "naze"...

Ici, quand même, le calcul est tellement simple que la précision d'un float suffit largement.

C'est très simple d'écrire 0.2, mais l'exprimer en float, c'est tout simplement impossible.
Donc le float est insuffisant quand on ne tolère pas d'erreur.

Alors la solution est de passer par une sorte de format rationnel dont le diviseur est souvent implicite (100 ou 1000 ou autre multiple de 10).

Bon, maintenant, imaginez le bazar qu'ajoute les taux de tva ou autres quand on calcule dans un sens ou dans l'autre (selon que le prix de vente affiché est ttc (public) ou ht (pro)...). Et pas seulement pour le ticket, mais aussi pur la déclaration de tva au fisc...

[polo974]

Tu veux dire les prix avec trois chiffres après la virgule ? et bien tu raisonne en millimes. T'as vu je suis trop fort hein ?

si le volume est donné en centilitre
en cent millième, vu que le prix est en 1/1000 et le volume en 1/100.

(presque) idem pour le calcul des prix au kg et la balance répond en gramme, etc...

Bref, calcul en format fixe en faisant gaffe de ne pas exploser l'entier par l'autre bout (ce qui ferait beaucoup plus désordre )...

[bokan]

polo974 : Merci d'avoir répondu à Arzhur, je pensais aussi qu'il n'avait pas compris le sujet mais ne voulais pas relever pour éviter une polémique interminable.

[Arzhur]

Bonjour,


Dans ce cas explique moi le sujet parce que je vois pas trop en quoi ta remarque est pertinente :

le float est insuffisant quand tu as besoin de précision : on est tous d'accord....que se soit pour couper des planches ou pour ce que tu veux.

Je vois pas trop dans l'exercice ce qui justifie ce besoin de précision.

[bokan]

Arzhur : un float ne peut pas contenir le nombre 0.1 par exemple, ce n'est pas un problème de précision. Lis les liens proposés. Et effectivement on ne rencontrera pas de problèmes pour calculer le prix de quelques photocopies, c'est juste qu'utiliser un float pour des valeurs monétaires n'est pas une bonne habitude à prendre.

[Arzhur]

Qu'on soit clair: je suis complètement d'accord avec toi : Utiliser un float est de manière général une mauvaise habitude à prendre ( je suis même un peu plus extrémiste que toi)

un float ne peut pas contenir le nombre 0.1 par exemple, ce n'est pas un problème de précision

J'ai du mal avec ça, voilà comment je le vois : le float n'aura pas 0.1 (on est d'accord). Il aura une autre valeur ( une valeur approchée quoi), si bien que à la fin de ton calcul la valeur retournée sera une valeur approchée du résultat (liée à la mauvaise représentation des chiffres + qql fautes sur d'éventuelles division).

Et effectivement on ne rencontrera pas de problèmes pour calculer le prix de quelques photocopies

-> Mon message portait plus (+) là dessus que sur les habitudes à prendre...On est dans le cadre d'un petit exo qui amha porte sur l'utilisation de conditions...pas dans une appli pro ( et critique)

[bisou10]

D'autant plus que généralement, c'est double qu'il faut utiliser (float et long double sont plus ou moins marginaux), ahahah !

Plus sérieusement, je peux comprendre que raisonner en nombres décimaux puisse être formelle acceptable pour des calculs de moyenne. Il faut se souvenir de ces possibilités d'erreur cumulée, c'est tout. Dans le cadre d'un TP, un raisonnement algorithmique correct et une implémentation avec des floats ne me choque pas.

[polo974]

Bonjour,

Dans ce cas explique moi le sujet parce que je vois pas trop en quoi ta remarque est pertinente :

le float est insuffisant quand tu as besoin de précision : on est tous d'accord....que se soit pour couper des planches ou pour ce que tu veux.

Non, justement, pour les planches, on a une tolérance, comme en physique d'ailleurs. Et il y a plusieurs magnitudes entre cette tolérance et la dynamique d'un float.

Je vois pas trop dans l'exercice ce qui justifie ce besoin de précision.

L'exercice demande de calculer un prix qui n'a aucune raison d'être approximatif. Si on fait le calcul en centime, on peut le faire en entier sans jamais avoir l'ombre d'une erreur.

vous en connaissez beaucoup des comptables tolérants, vous? pas moi.
j'en ai même parfois qui me font chier (et je suis poli) pour des écarts de quelques centimes, je leur fais remarquer que le coût horaire de 2 personnes ne permet pas de parler du sujet plus de quelques secondes...

D'autant plus que généralement, c'est double qu'il faut utiliser (float et long double sont plus ou moins marginaux), ahahah !

Mais si un float suffit, pourquoi prendre un double? Le jour où vous ne disposez pas d'unité flottante, vous comprendrez la différence...
Il m'est arrivé de tailler le format du flottant au strict minimum nécessaire (eh oui, un mini-float sur 3octets et demi...).

... Dans le cadre d'un TP, un raisonnement algorithmique correct et une implémentation avec des floats ne me choque pas.

Pas d'accord ! ! !
transposons ça en élec: on bosse sur l'automatisme, un peu de logique donc pour piloter une pompe de 10kW, et parce qu'on bosse sur la logique, on oublie les règles de sécurité et on laisse le tri se balader sur des barres non protégées avec si possible un peu d'eau étalée au sol (ben oui, au début, la pompe à fait déborder le bassin)...

Ici, c'est la même chose. ce n'est pas parce qu'on bosse sur les structures de contrôle qu'on fait n'importe quoi avec les données, alors que l'exo pouvait simplement demander de faire le calcul en centimes avec un int.

(très bonne, la blague de la clé sur float... preuve que la nature des flottants est très mal expliquée et comprise par trop d’informaticiens)

[bokan]

(très bonne, la blague de la clé sur float... preuve que la nature des flottants est très mal expliquée et comprise par trop d’informaticiens)

J'ai bossé 3 mois dans cette boite. Quand j'ai vu le chef de projet faire un raisonnement pareil, j'ai compris qu'on arriverai à rien de bon. Le pire c'est que je m'étais mis tout le monde à dos en expliquant qu'il ne pouvait pas y avoir plus de 2^32 combinaisons dans une donnée sur 4 octets. Qu'ils sortaient tous d'écoles d'ingé et que je suis autodidacte, donc j'avais tort...

[Arzhur]

Non, justement, pour les planches, on a une tolérance, comme en physique d'ailleurs. Et il y a plusieurs magnitudes entre cette tolérance et la dynamique d'un float.

Oui et de ce que je lis du thread en compta il faut être bon au centime près...ça fait une tolérance à 10^-3. L'exo, je l'ai fait pour voir avec de l'entier, du float et du double...bhé ils vont tous suffit de savoir arrondir.

vous en connaissez beaucoup des comptables tolérants, vous? pas moi.

Je les trouve super tolérant moi : ils se limitent aux centimes...(ok je sors)

Mais si un float suffit, pourquoi prendre un double? Le jour où vous ne disposez pas d'unité flottante, vous comprendrez la différence...
Il m'est arrivé de tailler le format du flottant au strict minimum nécessaire (eh oui, un mini-float sur 3octets et demi...).

T'es pas toujours obligé de tailler ton appli au minimum syndical. Perso par défaut je prend un double, si ça pose un problème dans l'appli, bha je change de type.

Ici, c'est la même chose. ce n'est pas parce qu'on bosse sur les structures de contrôle qu'on fait n'importe quoi avec les données, alors que l'exo pouvait simplement demander de faire le calcul en centimes avec un int.

Non ça n'a rien à voir dans ton exemple y'a des règles de sécurités/norme à respecter....pas ici, où on parle de calcul du prix des photocops (et même pas sur un vraie photocopieuse).

[polo974]

Oui et de ce que je lis du thread en compta il faut être bon au centime près...ça fait une tolérance à 10^-3. L'exo, je l'ai fait pour voir avec de l'entier, du float et du double...bhé ils vont tous suffit de savoir arrondir.

Mais pourquoi utiliser un truc qui nécessite de réflechir aux arrondis quand il y a plus simple et exact ? ? ?

...
Je les trouve super tolérant moi : ils se limitent aux centimes...(ok je sors)
...
T'es pas toujours obligé de tailler ton appli au minimum syndical. Perso par défaut je prend un double, si ça pose un problème dans l'appli, bha je change de type.

c'est ce que je disais, mais en embarqué, parfois le budget est serré et la demande de perf oblige à touiller les octets...

...
Non ça n'a rien à voir dans ton exemple y'a des règles de sécurités/norme à respecter....pas ici, où on parle de calcul du prix des photocops (et même pas sur un vraie photocopieuse).

Si, ça a tout à voir (même si c'était (volontairement) brutal), car c'est dans le cadre d'un enseignement, donc on ne laisse pas s'installer de mauvaises habitudes de travail sur une partie "accessoire" de la séquence...

(en plus int, c'est plus court à écrire que float ou double... (ok, je sors))

[bisou10]

Pas d'accord ! en embarqué tu as de vrais contraintes, qui font que 4 bytes peuvent être interessant. D'ailleurs, selon ton hardware, tu peux avoir float = double.

Remarque d'ailleurs qu'en embarqué, on utilisera un byte pour modéliser 0 à 255, alors qu'en desktop, ce sera un unsigned int. Ce dernier type a complètement remplacé unsigned char.

y'avait une trés bonne discussion sur Stack Overflow pour ce point: on peut bien sûr être d'accord ou pas, mais je me range tout à fait sur l'avis d'utiliser systématiquement des doubles (je rechercherais ce thread).

Quand au TP, c'est ce que tu cherches à mettre en évidence qui va à mon sens en déterminer la pertinence. Sur ces histoires de float, on est limite en guerre de religion, alors je peux comprendre que cet aspect là du TP soit volontairement approximé.