Probleme booléens qui plante

Fermé
lttl60 - 13 déc. 2014 à 12:21
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 - 14 déc. 2014 à 17:18
bonjour,
je viene de faire un programme qui calcule le nombre de jour que lon me doit mes des que je mes une structures conditionnelles dans un booléens sa plante merci de m'aidai.

import os
boucle = True


JourTravailer = input ("Nombre de jour travailée(ne pas metre les demis journées).\n")
JourTravailer = int (JourTravailer)

DemiTravailer = input ("Avez vous travailer une demi journer tous cumuler oui ou non.\n")

while boucle == True:
	if DemiTravailer == oui:
		CalDu = (((JourTravailer*36)/60)+4)/4
		boucle = False
	elif DemiTravailer == non:
		CalDu = ((JourTravailer*36)/60)/4
		boucle = False
	else:
		DemiTravailer = input ("Avez vous travailer une demi journer tous cumuler oui ou non.\n")
		
	
	



# CalDu = (((JourTravailer*36)/60)+4)/4

print (CalDu)

os.system ("pause")

5 réponses

Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
13 déc. 2014 à 12:41
Utilise plutôt l'opérateur break qui te permet de sortir d'une boucle à la place de la variable boucle.

De plus, il est normal que ton programme plante étant donné que cette condition:
if DemiTravailer == oui:

et une autre, comparent l'entrée utilisateur à deux variables, oui et non, au lieu de les comparer aux des chaînes de caractère "oui" et "non".

Remplace :
if DemiTravailer == oui:

par
if DemiTravailer == "oui":

0
je ne cest pas quoi metre apret while


while:
if DemiTravailer == "oui":
CalDu = (((JourTravailer*36)/60)+4)/4
break
elif DemiTravailer == "non":
CalDu = ((JourTravailer*36)/60)/4
break
else:
DemiTravailer = input ("Avez vous travailer une demi journer tous cumuler oui ou non.\n")

0
sambia39 Messages postés 610 Date d'inscription vendredi 31 juillet 2009 Statut Membre Dernière intervention 9 février 2023 49
14 déc. 2014 à 14:40
Bonjour,
Ce n'est pas bon et en plus mal écris car, d'un côté en sort brutalement à la sauvage d'une boucle avec la fonction break qui à pour justification la boucle infinie cela démontre aussi qu'il y'a aucune logique sans compter que le code lui-même est mal écrit donc algorithme mauvais.
Bref, le but est de savoir si oui ou non en a travailler, si oui on donne le nombre de jours de travail dans le cas contraire en saisie 0 comme nombre de jours de travail ( le cas de 0 donnera toujours 0) au final une opération ternaire en python dans une fonction suffit très largement et en utilise les fonctions correctement ce qui donne
__author__ = 'root'

def f_Trav( x = 0 , y = False ):
    return ( ((x*36)/60+4)/4 ) if y == True else ( ((x*36)/60)/4 )
#fin de la fonction Trav

def f_CalculeTravail():

    print("Entrer le nombre de jour de travail si vous avez travailler\t")
    x = eval( input("Travail ? :") )

    if x <= 0:
        return f_Trav( 0 )
    else:
        return f_Trav( x, True );
#fin de la fonction Calcule Travail


print( "Resultat\t=", f_CalculeTravail() )

à bientôt
0
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
14 déc. 2014 à 14:56
Salut !

L'intérêt de la boucle est de ne pas sortir du programme en cas de mauvaise saisie.
Mince justification, il est vrai.

Mais ça as du sens aux yeux d'un débutant ;-)

Si le helpé veut continuer à apprendre à programmer, il comprendra par lui-même l'intérêt des fonctions en terme de lisibilité et d'optimisation.

Il est toujours plus intéressant de guider le helpé pour l'aider à comprendre ses erreurs plutôt que de fournir une solution directement.

Je ne vois pas en quoi l'opérateur "break" est mauvais, il reste le meilleur moyen de sortir d'une boucle dont la fin est déterminée par une entrée utilisateur.

Que cela soit en terme de logique ou d'optimisation, il n'y a rien de mal à ça, on économise une variable. (un octet, youpi)
0
sambia39 Messages postés 610 Date d'inscription vendredi 31 juillet 2009 Statut Membre Dernière intervention 9 février 2023 49
14 déc. 2014 à 16:12
Bonjour

Certes j'ai fourni une réponse mais, la réponse dans t'il a besoin et surtout qu'il comprenne que dans l'exemple j'use de la logique et pas d'optimisation de plus utiliser une boucle loop infinie sans une condition correcte de sortie sont pour moi des pratique barbares,

@Sugel:Si le helpé veut continuer à apprendre à programmer, il comprendra par lui-même l'intérêt des fonctions en terme de lisibilité et d'optimisation.

Oui mais, si, pas de notion de logique ou algorithme dés le départ = pas de code propre , ni logique claire et pas d'intérêt majeur à exploitation des fonctions ni notion de paradigme afin d'évité la complexification d'un programme simple , et c'est pédagiquement pas correcte

@Sugel:Je ne vois pas en quoi l'opérateur "break" est mauvais, il reste le meilleur moyen de sortir d'une boucle dont la fin est déterminée par une entrée utilisateur.


Oui, dans une boucle infinie sans condition ou dans un cas bien particulier
alors quel est l'intérêt de recommencer une saisie dans une boucle infinie ?
Serait-il par mieux de faire je recommence la saisie tant que je n'ai pas de chiffre ?

@Sugel:Que cela soit en terme de logique ou d'optimisation, il n'y a rien de mal à ça, on économise une variable. (un octet, youpi)

En ne fait pas de l'optimisation ou l'économie d'octet dans le cas actuel un algorithme ,une logique claire, ou programme bien pensé" demandera ou ne sollicitera pas de variable supplémentaire ou de la bidouille en plus vous n'avez rien compris.

à bientôt
0
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
14 déc. 2014 à 16:27
Je comprends votre position et la respecte, mais ce n'est toutefois pas la mienne.
Mais je m'incline, je suis probablement moins compétant que vous, et surtout frappé d'une maladie de l'optimisation...

Je conviens que il est très mauvais de penser à la fois algorithmie et optimisation, et surtout que la conscience de la nécessité de cette dernière ne doit venir qu'après.

Je ne suis ni professeur, ni bon pédagogue, apparemment !
0
sambia39 Messages postés 610 Date d'inscription vendredi 31 juillet 2009 Statut Membre Dernière intervention 9 février 2023 49
14 déc. 2014 à 16:52
@Sugel: je suis probablement moins compétant que vous, et surtout frappé d'une maladie de l'optimisation...

ne me faite par dire ce que je n'ai pas dit, si vous avez mal compris je m'en excuse, pour ma part j'ai argumenté la mauvaise pratique avec l'utilisation systématique de la boucle infinie non justifier

@Sugel: Je conviens que il est très mauvais de penser à la fois algorithmie et optimisation, et surtout que la conscience de la nécessité de cette dernière ne doit venir qu'après.

Les deux ne viennent pas après, algorithme vient avant et la seconde vient bien après et l'optimisation est la pratique qui consiste généralement à réduire le temps d'exécution d'une fonction, l'espace occupé par les données et le programme, ou la consommation d'énergie. et régie par certaines règles
au niveau algorithmique, en choisissant un algorithme de complexité inférieure (au sens mathématique) et des structures de données adaptées ;
==> au niveau du langage de développement, en ordonnant au mieux les instructions et en utilisant les bibliothèques disponibles ;
en utilisant localement un langage de bas niveau, qui peut être le langage C ou, pour les besoins les plus critiques, le langage assembleur.
==>On ne passe au niveau supérieur d'optimisation qu'une fois qu'on a épuisé les possibilités d'un niveau.
L'utilisation d'un langage de bas niveau sur l'ensemble d'un projet pour des raisons de rapidité est l'une des erreurs les plus communes et les plus coûteuses que puisse faire un projet industriel.

==>L'optimisation de code est considéré par beaucoup de développeurs amateurs comme un art un peu magique et, pour cette raison, comme l'une des parties les plus excitantes de la programmation. Ceci les conduit à croire qu'un bon programmeur est une personne qui optimise d'emblée le programme. Cependant l'expérience montre qu'elle ne peut pallier une mauvaise conception initiale. C'est dans la conception que l'expérience du développeur joue le plus. Par ailleurs, dans un nombre majoritaire et grandissant de cas, le « bon programmeur » est moins celui qui écrit du code astucieux (l'optimiseur s'en chargera le plus souvent mieux que lui) que celui qui écrit du code lisible et aisé à maintenir.
source https://fr.wikipedia.org/wiki/Optimisation_de_code

à bientôt
0
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
14 déc. 2014 à 17:18
On est d'accord;
Les deux ne viennent pas après, algorithme vient avant et la seconde vient bien après
Je parle de l'apprentissage de la programmation; l'algo d'abord, et puis après viens le temps où il faut prendre conscience de la nécessité d'inclure le coût en performance d'une opération dans sa réflexion algorithmique, dans la limite du raisonnable bien entendu.

Ne me faites pas dire ce que je n'ai pas dit non plus:
L'optimisation n'est pas une science magique, mais une tâche nécessaire.

La plus grosse partie de l'optimisation d'un programme se fait au début, lorsque l'on décide de sa structure, de son organisation, des différentes taches à effectuer et des moyens de les effectuer.

Je n'ai pas fais dans ce sujet référence à ce concept par adoration, mais plus par rapport à ce qui était d'actualité à ce moment là, en l'occurrence l'usage de break.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
j'ai fai sa dit moi ci tu voi mieus stp
merci our ton aides


while 1:
if DemiTravailer == "oui":
CalDu = (((JourTravailer*36)/60)+4)/4
break
elif DemiTravailer == "non":
CalDu = ((JourTravailer*36)/60)/4
break
else:
DemiTravailer = input ("Avez vous travailer une demi journer tous cumuler oui ou non.\n")
-1
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
14 déc. 2014 à 13:30
voilà, là ça sent bon :)
0
fiddy Messages postés 11069 Date d'inscription samedi 5 mai 2007 Statut Contributeur Dernière intervention 23 avril 2022 1 835
14 déc. 2014 à 15:07
Là, ça sent surtout la boucle infinie... Tu fais while 1; et rien pour sortir de la boucle.
Il faut revoir ta condition.
0
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
14 déc. 2014 à 15:37
Si, le break est là pour ça.
0
Sugel Messages postés 4070 Date d'inscription jeudi 18 août 2011 Statut Membre Dernière intervention 19 juin 2017 724
14 déc. 2014 à 15:41
De manière purement technique, un break vaut mieux qu'une variable pour sortir d'une boucle, car il corresponds à une instruction jump.
Après, selon les plus philosophes d'entre nous, il vaut mieux utiliser une variable pour éviter les confusions.
0
fiddy Messages postés 11069 Date d'inscription samedi 5 mai 2007 Statut Contributeur Dernière intervention 23 avril 2022 1 835
Modifié par fiddy le 14/12/2014 à 16:03
J'avais pas vu le break. Mais ce n'est pas terrible.
Son programme de début était mieux.
Il vaut mieux privilégier l'algorithmique que la technique dans un programme. La technique est à prendre en compte en dernier recours pour les dernières optimisations.
Ceci a donc ma préférence.
while boucle == True:

Mais, on peut faire encore mieux :
DemiTravailler=""
while DemiTravailler not in ["oui", "non"] :
     DemiTravailler=raw_input("Avez vous travailer une demi journer tous cumuler oui ou non"

if DemiTravailer == "oui":
     CalDu = (((JourTravailer*36)/60)+4)/4
else :
     CalDu = ((JourTravailer*36)/60)/4

Note : raw_input() est plus sécurisé que input().

Cdlt,
0