Bonjour, je dois faire un programme qui permet de classer un tableau rempli de nombres entiers dans l’ordre croissant.
Et je vous avouerais que je suis perdu.. Je penses partir sur une base comme ça
Ton code est difficilement lisible car est mal formaté (il faut utiliser la balise ```python pour insérer du code Python), même si on peut le voir en meilleure forme dans la source de la page, ça ne reste pas très pratique.
Mais les noms de variables sont aussi peu explicites (tamp ?)
Ensuite j’ai du mal à comprendre la première condition, qui compare val[0] à… val[0], ni d’où sortent certaines valeurs comme 3.
Tu peux utiliser simplement sort(), ou bien manuellement, un truc vite fais, qui peut être amélioré je crois :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
val=[5,2,4,3]# Itérer 4 foisfor_inval:# Pour chaque élément du tableauforvinval:# Vérifier si la case actuel est supérieur à la suivanteif(val.index(v)<len(val)-1andv>val[val.index(v)+1]):# Si tel est le cas retirer la case inférieurpoped=val.pop(val.index(v)+1)# Positionner au débutval.insert(0,poped)
EDIT : ça a pour effet de déplacer les plus grand vers la fin à chaque itération, de sorte à ce que en fin de compte le tableau soit trié du plus petit au plus grand.
Juste comme ça, essaye de mettre un titre plus explicite à ton sujet (comme « tri d’un tableau d’entier dans l’ordre croissant en Python ») ça permet aux membres de plus facilement comprendre ce que tu cherche avant même de lire tout ton sujet.
Lignes 6 a 11 de ton programme : tu traites de façon particulière la valeur 0, et tu vas la traiter une 2ème fois dans la boucle suivante. Donc inutile. D’ailleurs, comme dit entwanne, le test de la ligne 6 ne sera jamais vérifié.
La boucle suivante. Essaie de dérouler ton programme, ligne à ligne, et tu vas voir qu’il manque une instruction entre la ligne 12 et la ligne 13. Tu vas voir aussi que le 3 de la ligne 13 n’est pas bon.
Dérouler le programme, c’est exécuter ligne à ligne chaque instruction, en notant sur un papier les valeurs des différentes variables. Ici, la première fois que le programme passe par la ligne 13, i vaut 0 et u vaut 1, et le tableau val a son contenu d’origine, puis le test de la ligne 14 dit qu’il faut permuter val(0) et val(1) … etc etc etc.
>>>liste=[3,12347,59,47]>>>sorted(liste)# la liste est triée...[3,47,59,12347]>>>liste# ... ou pas[3,12347,59,47]>>>liste.sort()>>>liste# maintenant elle l'est[3,47,59,12347]
D’autre part il y a fort à parier que le but du PO soit d’implémenter un algorithme de tri pour s’entraîner à écrire des algorithmes.
Nohar a raison sur le principe, mais rien n’empêche d’écrire val = sorted(val) si le but est d’obtenir le tableau trié. Certes, je comprends la valeur de l’exercice, mais python ne nous incite-t-il pas à ne pas à réinventer la roue si elle existe ?
"Simple is better than complex" et "Readability counts" (extraits du Zen of Python) m’inciteraient à utiliser sorted()
Si j’ai le choix entre savoir programmer et connaitre par coeur la doc de python, je choisis clairement la première.
Je pense qu’apprendre à programmer sans se servir d’un langage de programmation comme support, c’est pas une super bonne idée, ça limite trop l’expérimentation.
Ici, je présume que le but c’est d’apprendre à programmer et que le support c’est Python, pas que le but c’est d’apprendre la lib standard de Python sans devenir capable d’implémenter un truc simple comme un tri.
Autant il y a des moments où je peste contre les profs qui imposent à leurs élèves de recoder complètement telle ou telle fonctionnalité de la bibliothèque standard dont la valeur didactique est pauvre (OrderedDict, Count, shlex…), autant les algos de tri ou les structures dichotomiques, ou les modules système comme psutils portent en eux une vraie connaissance nécessaire à l’apprentissage de l’algorithmique ou de la programmation.
Savoir que la builtin sorted existe, c’est bien. Avoir le réflexe de la mettre de côté quand on sent qu’on peut résoudre un problème de façon linéaire, c’est encore mieux. Acquérir cette connaissance passe par l’étude (et l’implémentation) d’algos de tris.
C’est pareil pour les profs de prog système qui imposent aux élèves d’aller lire les pseudo-fichiers dans /proc : oui, psutils le fait vachement mieux, de manière portable et bien plus efficace que n’importe quel code en pur Python, mais le but de ces cours est justement de comprendre ce qu’il fait pour mieux manipuler ces notions (processus, threads, mémoire résidente/virtuelle, PID, appels système…) d’instinct. En programmation système comme en algorthmique c’est particulièrement vrai : il faut se salir les mains pour piger les choses.
Le zen de Python (auquel j’adhère) peut nous dire ce qu’il veut, son domaine d’application est le développement, pas son apprentissage. Parfois ça se recoupe (KISS, flat is better than nested, readability counts), mais ici, non : il faut savoir comment est foutue la roue pour l’utiliser correctement, même si à l’avenir on n’aura pas besoin de la réinventer.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte