Boucle while, pourquoi

[frequi1]

Bonjour, encore moi

Déja le code:

f = lambda x : x* x

encore = 1
while encore == 1:
    # resultat avec fonction lambda
    saisie_utilisateur = int(input("quel carré voulez vous calculer : "))
    carré = f(saisie_utilisateur)
    print(f"Le carré de {saisie_utilisateur} est {carré}")
    choix_utilisateur = int(input("Voulez-vous recommencer ? : (1.oui/2.non)\n")) #< ------------Pas de problème jusque la
    while (choix_utilisateur == 1 or choix_utilisateur == 2):
        if choix_utilisateur == 1:
            encore = 1
        elif choix_utilisateur == 2:
            encore = 0
        else:
            print("Choix impossible")

Alors voila la deuxième boucle while ne fonctionne pas, ça doit etre completement C.. mais je vois pas. si quelqu'un voit mieux, merci à lui
-----

[frequi1]

f = lambda x: x * x

encore = True
while encore:  # tant que encore est vrai
    saisie_utilisateur = int(input("quel carré voulez vous calculer : "))
    carré = f(saisie_utilisateur)
    print(f"Le carré de {saisie_utilisateur} est {carré}")
    choix_utilisateur = int(input("Voulez-vous recommencer ? : (1.oui/2.non)\n"))
    #while choix_utilisateur != 1 or choix_utilisateur != 2:  # tant que choix_utilisateur est different de 1 ou 2
    if choix_utilisateur == 1:
        encore = True
        print(f"recommencons ")

    elif choix_utilisateur == 2:
        encore = False
        print(f"Au revoir ")

    else:
        print("Choix impossible ")
        choix_utilisateur = int(input("1. Oui/2. Non"))
        if choix_utilisateur == 2:
            encore = False
            print(f"Au revoir")

Ca fonctionne mieux comme ça.

[Garion]

Je ne connais pas les subtilités de python mais dans d'autre langages :
while (choix_utilisateur == 1 or choix_utilisateur == 2)
Est ambigu au niveau du parenthésage.
Vaut mieux écrire
while (choix_utilisateur == 1) or (choix_utilisateur == 2)

[Garion]

Sinon, si on prend les opérateurs dans l'ordre, ça reviendrait à :
while (((choix_utilisateur == 1) or choix_utilisateur) == 2)
Mais bon, je ne sait pas si Python l'interpréte vraiment comme ça

[A voir en vidéo sur Futura]

[umfred]

aucun soucis sur ça (il n'y a aucune ambiguïté possible), la problématique initiale c'était surtout que la variable n'était jamais mise à jour dans la boucle

[frequi1]

aucun soucis sur ça (il n'y a aucune ambiguïté possible), la problématique initiale c'était surtout que la variable n'était jamais mise à jour dans la boucle

Oui c'est exactement ça ..... comment fallait il faire pour la mise a jour de la variable à travers la boucle

[CM63]

Les initialisations se font toujours avant les boucles et pas dans les boucles.

[Garion]

aucun soucis sur ça (il n'y a aucune ambiguïté possible), la problématique initiale c'était surtout que la variable n'était jamais mise à jour dans la boucle

Ca dépend du langage.
En Delphi par exemple, l'opérateur "or" est prioritaire en théorie à "=" ("==" en python).
Mais en pratique le compilateur force dans ce cas là à mettre des parenthèses.
Je me posais donc la question, ne connaissant Python.
Mais oui, j'ai juste vu ça et pas le reste qui expliquait le problème.

[Garion]

D'ailleurs, j'ai toujours trouvé le "=" maladroit dans certains langages.
En C ou en Pyhon on peut écrire "A = A + 1".
Ce qui mathématiquement est absurde.
Je trouve que le pascal est plus logique ":=" est une affectation et "=" est un test d'égalité.

[polo974]

Il ne faut pas confondre informatique et mathématiques, les symboles n'y ont pas toujours le même sens.

Et l'affectation ( genre A=A+1 ) arrive plus souvent que le test ( genre A == B ) et comme l'informaticien est un animal paraisseux (sinon pourquoi voudrait-il automatiser ses calculs ), il fait au plus court...

Au point qu'en C il y a A+=1 et même A++ ou ++A (qui n'ont pas tout à fait le même comportement) (on atteind là le sublime (re )...)

[pm42]

D'ailleurs, j'ai toujours trouvé le "=" maladroit dans certains langages.
En C ou en Pyhon on peut écrire "A = A + 1".
Ce qui mathématiquement est absurde.

Comme le dit polo974, on ne fait pas des maths mais de l'informatique et on a donc du adapter pas mal de choses. Par exemple, la multiplication est faite avec le signe * et pas x, la puissance avec **, ^ ou pow et pas en exposant, les indices avec des [] qui ne représentent pas une notation matricielle ou autre, etc.

Je trouve que le pascal est plus logique ":=" est une affectation et "=" est un test d'égalité.

Dans d'autres langages, l'affectation est le <-.
Le débat est ancien et à l'époque du C, les concepteurs ont considéré qu'on écrivait beaucoup plus souvent une affectation qu'un test d'égalité. Ils ont donc choisi = pour l'affectation et == pour l'égalité.
L'idée était de garder le code concis.

Cette logique s'est imposée même dans les langages verbeux. On peut aussi remarquer que cela ne pose pas de problème, quiconque a dépassé le niveau débutant qui lit ses 1ères pages de programmation s'y est fait très vite et cela ne pose non plus pas spécialement de problème de maintenance ou de lisibilité (sujets qu'on a étudié en suivant avec des capteurs IR les mouvements des yeux des programmeurs qui lisent du code, ce qui a permis de constater que ce sont les abréviations qui ralentissent).

[Brinicle]

Bonjour,

Au point qu'en C il y a A+=1

Ça existe aussi en python. Personnellement, j'aime bien ces +=, -=, *=, /= et **= .
Mais il n'y a pas de ++ et -- (sic).

Je ne connais pas les subtilités de python mais dans d'autre langages :
while (choix_utilisateur == 1 or choix_utilisateur == 2)
Est ambigu au niveau du parenthésage.
Vaut mieux écrire
while (choix_utilisateur == 1) or (choix_utilisateur == 2)

Ça peut étre le cas en python : lorsque l'on fait des test d'égalités sur les arrays de numpy, il FAUT mettre les parenthèses.

[pm42]

Ça peut étre le cas en python : lorsque l'on fait des test d'égalités sur les arrays de numpy, il FAUT mettre les parenthèses.

C'est une question de priorité des opérateurs. En python, on peut très bien écrire :

while choix_utilisateur == 1 or choix_utilisateur == 2

Il n'y a pas besoin de parenthèses autour de l'expression et elle est interprétée sans ambiguité avec les == qui sont évalués avant le or.

En numpy/pandas dans les array ou dataframe, on calcule des masques binaires et on utilise donc les opérateurs & et | plutôt que "and" et "or". Là, les priorités des opérateurs sont différentes (ce qui est logique) et il faut mettre des parenthèses.

[polo974]

perso, je préfère mettre "trop" de parenthèses, au point que j'encadre parfois toute l'expression pour pouvoir passer à la ligne et ainsi rendre la chose plus lisible

while (    (choix_utilisateur == 1) 
        or (choix_utilisateur == 2) ):
    pass # ou autre chose...

(je n'aime pas le backslash en fin de ligne...)

[pm42]

Dans le cas de Python il y a une norme de formattage qu’on n’est pas obligé de respecter bien sûr sauf si on participe à des projets open-source par exemple.
Et elle n’autorise pas les parenthèses inutiles.
Certains IDE le signalent d’ailleurs.

[polo974]

Ah zut, il faut que je révise les PEP...

Mais quand on est coincé avec le 80 ou 100 car par ligne et qu'on est au 5ème niveau d'indentation, on se retrouve vite à devoir passer à la ligne, surtout quand on évite les noms de variable sibyllins et en plus quand on se coltine le self, ça fini par être verbeux (pour un code 100% perso, je remplace self par s, mais c'est aussi une entorse à la PEP)...

[pm42]

Oui, c’est les joies de Python.
J’aime bien aussi quand à cause d’une erreur vite fixée mon main se retrouve à 1 niveau d’indentation parce que l’IDE a reformatté ce qui fait que quand je le lance, il ne fait rien avec aucun message.

Je n’apprécie pas spécialement la structure par indentation, encore moins le self partout, le côté non typé me fait perdre un temps fou et l’absence de miltithreading digne de ce nom est ridicule.
Bref je n’aime pas ce langage qui est pourtant très pratique.

[Garion]

Cette logique s'est imposée même dans les langages verbeux. On peut aussi remarquer que cela ne pose pas de problème, quiconque a dépassé le niveau débutant qui lit ses 1ères pages de programmation s'y est fait très vite et cela ne pose non plus pas spécialement de problème de maintenance ou de lisibilité (sujets qu'on a étudié en suivant avec des capteurs IR les mouvements des yeux des programmeurs qui lisent du code, ce qui a permis de constater que ce sont les abréviations qui ralentissent).

Ca ne me pose pas de problème non plus, je sais lire pas mal de langages, j'ai juste dit que c'était maladroit comme choix.

[Garion]

Dans le cas de Python il y a une norme de formattage qu’on n’est pas obligé de respecter bien sûr sauf si on participe à des projets open-source par exemple.
Et elle n’autorise pas les parenthèses inutiles.
Certains IDE le signalent d’ailleurs.

Ça, en revanche, ça limite la lisibilité quand on n'est pas expert du langage.
Sans parenthèse, cela nécessite de connaitre les priorités des opérateurs, avec les parenthèses, pas besoin de connaitre spécialement le langage.

[umfred]

ça me fait un peu penser aux "défis mathématiques" qu'on trouve parfois sur les réseaux sociaux du type "calculez 2-5x6+3= ?" où l'on retrouve 2 logiques: la logique mathématique avec la priorité des opérations (2-(5x6)+3=-25) ou la logique séquentielle ((2-5)x6)+3=-15)

[pm42]

ça me fait un peu penser aux "défis mathématiques" qu'on trouve parfois sur les réseaux sociaux du type "calculez 2-5x6+3= ?" où l'on retrouve 2 logiques: la logique mathématique avec la priorité des opérations (2-(5x6)+3=-25) ou la logique séquentielle ((2-5)x6)+3=-15)

Ceci dit que ce soit en maths ou en informatique, on définit assez rigoureusement la priorité des opérateurs. Et dans les langages actuels, elle est pratiquement toujours la même ce qui simplifie la vie.
Dans le cas que tu cites, la logique séquentielle n'est pas la bonne et je pense qu'on apprend ça assez tôt à l'école.