"Euh, que ca soit pour les algos de tri de tableau ou autre, ya jamais eu aucun probleme à implementer ca facilement en python" avec les ndarray de Numpy, soit. Mais sûrement pas comme tu le dis. Désolé pour toi, mais changer la valeur d'une case d'un tableau n'est pas algorithmiquement équivalent à modifier un chaînon dans une liste. Ce qui est atomique en Python n'est pas forcément atomique dans la vraie vie.

En python, il manque la boucle "for" (le for de python ne permet pas de faire des boucles, seulement des itérations sur des structures) et le "do while". Il manque aussi le "switch" même si ça s'émule bien à coup de "elif"s.

" le fait de ne pas avoir à se poser tout un tas de questions sur le bas niveau en python permet d'utiliser ce temps pour apprendre d'autre choses de plus haut niveau." ça te permet de confondre les listes et les tableaux... idéal quand on cherche à avoir du code qui rame sans raison.
L'algorithmique n'est pas qu'une histoire de correction. Il y a aussi les histoires de complexité, qui sont tout aussi importantes... et malheureusement grandement négligées. Et si tu n'es pas d'accord, demande toi à quoi ça sert de faire de l'algorithmique si on n'a pas de moyen propre pour déterminer si un algorithme est meilleur qu'un autre.

"Non c'etait pas de trouver des justification à leur échec, c'est juste leur ressenti sur les cours et les langages utilisés. " qu'ils expriment leur ressenti dans 5 ans quand ils auront pris du recul. Plus on apprend de langage, et plus c'est simple et rapide d'en apprendre un. C'est facile de dire que c'était plus facile d'apprendre python après le C : quand on part d'une base (même très chancelante), évidemment que c'est plus simple que de partir de rien. Seulement voilà, tes camarades ont ils vraiment le recul pour savoir comment ça se serait passé s'ils avaient commencer par Python ? J'en doute. (Et qu'on soit d'accord, je ne ferais pas mieux à leur place).

""Euh, que ca soit pour les algos de tri de tableau ou autre, ya jamais eu aucun probleme à implementer ca facilement en python" avec les ndarray de Numpy, soit. Mais sûrement pas comme tu le dis. Désolé pour toi, mais changer la valeur d'une case d'un tableau n'est pas algorithmiquement équivalent à modifier un chaînon dans une liste. Ce qui est atomique en Python n'est pas forcément atomique dans la vraie vie.

En python, il manque la boucle "for" (le for de python ne permet pas de faire des boucles, seulement des itérations sur des structures) et le "do while". Il manque aussi le "switch" même si ça s'émule bien à coup de "elif"s. "

Oui mais ce que je voulait dire, c'est que la liste peut être utilisé comme tableau (pour un débutant, ca fera aucune différence).
Pour le for, for in in range(valeur): agit de la même maniere qu'une boucle for classique.

"" le fait de ne pas avoir à se poser tout un tas de questions sur le bas niveau en python permet d'utiliser ce temps pour apprendre d'autre choses de plus haut niveau." ça te permet de confondre les listes et les tableaux... idéal quand on cherche à avoir du code qui rame sans raison.
L'algorithmique n'est pas qu'une histoire de correction. Il y a aussi les histoires de complexité, qui sont tout aussi importantes... et malheureusement grandement négligées. Et si tu n'es pas d'accord, demande toi à quoi ça sert de faire de l'algorithmique si on n'a pas de moyen propre pour déterminer si un algorithme est meilleur qu'un autre. "

Ceux qui on un programme à faire qui est suceptible de ramer parceque on choisit les listes à la place de tableau, je pense pas qu'ils vont s'amuser à choisir python à cause des perf du langage (ou du moins pour la portion de code qui a besoin d'être optimisé)

""Non c'etait pas de trouver des justification à leur échec, c'est juste leur ressenti sur les cours et les langages utilisés. " qu'ils expriment leur ressenti dans 5 ans quand ils auront pris du recul. Plus on apprend de langage, et plus c'est simple et rapide d'en apprendre un. C'est facile de dire que c'était plus facile d'apprendre python après le C : quand on part d'une base (même très chancelante), évidemment que c'est plus simple que de partir de rien. Seulement voilà, tes camarades ont ils vraiment le recul pour savoir comment ça se serait passé s'ils avaient commencer par Python ? J'en doute. (Et qu'on soit d'accord, je ne ferais pas mieux à leur place)."

Enfin, perso dans mon cas je pense que si j'avais fait directement du python ca se serait mieux passé et en tout cas, j'ai bien fait de changer de c vers python (d'ailleurs, c'est bête mais certains concepts de c, j'en ai saisi l'intérêt en faisant du python ).
Aprés, c'est peu être aussi une bonne idée de toucher au deux surtout qu'ils se mélangent assez bien pour des projets il me semble (jamais essayé).

Je vais peut être me faire huer, mais pour moi, le Python comme le Lua sont plus à utiliser en tant que complément à un code (Script en l’occurrence) non ? .

Il me semble que le C possède des méthodes pour lire du code en Lua, donc si on veut se faciliter la vie, pourquoi ne pas apprendre le C (Qui va quand même loin dans les explications sur sa machine), et en parallèle, pour tester des algos, le faire avec un petit langage de script, lua pour le coup ? .

" Oui mais ce que je voulait dire, c'est que la liste peut être utilisé comme tableau (pour un débutant, ca fera aucune différence)."
Aucune différence ? Tu te fous de moi là ?
Algorithmiquement, c'est différent. Les coûts des opérations ne sont pas les mêmes, et les opérations elles-même ne sont pas les mêmes (on n'a pas d'insertion au milieu d'un tableau par exemple).
En pratique, c'est différent aussi. L'API n'est pas la même entre les ndarray et les list python.
Donc non, c'est pas pareil... et il faut avoir un niveau vraiment médiocre pour ne pas le savoir.

" Pour le for, for in in range(valeur): agit de la même maniere qu'une boucle for classique. "
"Le for i in range()" va d'abord construire une liste avant d'itérer dessus. Bilan, consommation mémoire énorme, et plantage si on veut itérer très longtemps. On n'a pas ces problèmes avec le while permet de faire une vraie boucle.

Et quand tu essaies de te défendre, fais-le sérieusement merde . Ici, c'est de xrange (qui va construire la liste de façon paresseuse) qu'il fallait parler pour donner du sens à ton discours.

"Ceux qui on un programme à faire qui est suceptible de ramer parceque on choisit les listes à la place de tableau, je pense pas qu'ils vont s'amuser à choisir python à cause des perf du langage (ou du moins pour la portion de code qui a besoin d'être optimisé) "
Pas besoin de chercher aussi loin. Comparer la vitesse de deux algorithmes qui calculent la même chose, c'est quelque chose de naturel et qu'un débutant est amené à faire très tôt.

À ce sujet, le SDZ offrait à une époque (ça a été corrigé il me semble) un magnifique algo pour trier des tableaux en O(n*log(n)) (pour les béotiens, lire "en temps raisonnable"). Sauf que l'implantation en Python avec des listes était si foireuse que n'importe quel algo naïf (en O(n²) ou en "temps peu raisonnable") était meilleur.
J'imagine la tête des rares débutants qui ont eu la bonne idée de comparer les algos de tris pour s'apercevoir que tous les efforts algorithmiques conduisaient à un code plus lent. Ils devaient êtres ravis tiens...
Bilan, quand on code en faisant abstraction du coût des opérations, on se plante comme une merde.

"" Oui mais ce que je voulait dire, c'est que la liste peut être utilisé comme tableau (pour un débutant, ca fera aucune différence)."
Aucune différence ? Tu te fous de moi là ?
Algorithmiquement, c'est différent. Les coûts des opérations ne sont pas les mêmes, et les opérations elles-même ne sont pas les mêmes (on n'a pas d'insertion au milieu d'un tableau par exemple).
En pratique, c'est différent aussi. L'API n'est pas la même entre les ndarray et les list python.
Donc non, c'est pas pareil... et il faut avoir un niveau vraiment médiocre pour ne pas le savoir."

Je ne parlait pas du cout mémoire que je sais est different mais au niveau de l'implementation d'un algorithme.

"" Pour le for, for in in range(valeur): agit de la même maniere qu'une boucle for classique. "
"Le for i in range()" va d'abord construire une liste avant d'itérer dessus. Bilan, consommation mémoire énorme, et plantage si on veut itérer très longtemps. On n'a pas ces problèmes avec le while permet de faire une vraie boucle.

Et quand tu essaies de te défendre, fais-le sérieusement merde . Ici, c'est de xrange (qui va construire la liste de façon paresseuse) qu'il fallait parler pour donner du sens à ton discours. "

xrange pour les versions 2.X et range pour les versions 3.X

"Ceux qui on un programme à faire qui est suceptible de ramer parceque on choisit les listes à la place de tableau, je pense pas qu'ils vont s'amuser à choisir python à cause des perf du langage (ou du moins pour la portion de code qui a besoin d'être optimisé) "
Pas besoin de chercher aussi loin. Comparer la vitesse de deux algorithmes qui calculent la même chose, c'est quelque chose de naturel et qu'un débutant est amené à faire très tôt.

À ce sujet, le SDZ offrait à une époque (ça a été corrigé il me semble) un magnifique algo pour trier des tableaux en O(n*log(n)) (pour les béotiens, lire "en temps raisonnable"). Sauf que l'implantation en Python avec des listes était si foireuse que n'importe quel algo naïf (en O(n²) ou en "temps peu raisonnable") était meilleur.
J'imagine la tête des rares débutants qui ont eu la bonne idée de comparer les algos de tris pour s'apercevoir que tous les efforts algorithmiques conduisaient à un code plus lent. Ils devaient êtres ravis tiens...
Bilan, quand on code en faisant abstraction du coût des opérations, on se plante comme une merde.

On a eu un tp ou on devait implementer les algos de tri en python et comparer leurs vitesse sans probleme au niveau des résultats pourtant

Les biologistes... J'ai deux très grands souvenirs de biologistes qui font du python.

Le premier, c'était un type qui faisait du calcul numérique et qui était fier de son code python pour limiter les erreurs numériques... sauf que ça ne faisait que les empirer, alors que l'algorithme naïf offraient des performances proches de ce qu'on sait faire de mieux.

La seconde, une (pauvre) fille qui voulait optimiser je ne sais plus quoi. Elle présente son algorithme clairement mauvais, son implantation python et les perfs chaotiques qui allait avec (mais bon, elle avait quand même des résultats). La suite, je n'ai pas écouté... mais j'en ai profité pour :
1. montrer que l'algo glouton naturel était bien plus efficace, mais n'optimisait pas à fond
2. élaborer un algo basé sur la prog dynamique, aussi efficace que le précédent, et qui optimisait à fond
3. rédiger le tout.
Moralité, le travail de la fille ne servait à rien... elle aurait du aller causer 10 minutes avec un informaticien.

Donc oui, les biologistes sont contents de pouvoir faire du Python... sauf que ça reste des biologistes et qu'ils ne connaissent pratiquement rien à l'algorithmique et à la programmation.

[notch] : Oui, parce que tu avais des algorithmes efficaces pour trier des listes doublement chaînées. Mais un algorithme quelconque pour trier un tableau en n*log(n) n'a pas de raison de trier aussi des listes doublement chaînées en n*log(n). Dis autrement, les idées classiques pour trier efficacement des tableaux doivent être adaptées un minimum pour obtenir des perfs similaires quand on manipule des listes.

Bah à part mergesort, les 3 autres algos qui ont été présentés sont présent sur la page wikipedia de tri de tableau.

Bon enfaite, ya un probleme c'est que je peux pas utiliser quicksort pour les grandes listes à cause de la récursion pour pouvoir mieux comparer

• ah si mergesort est bien aussi sur la page wikipedia du tri de tableau, j'ai mal lu

zaver dja remarquer qu'avec python les objet etait partager ?

par exemple

    A = [1,2,3]
    B = [3,2,1]

A et B sont 2 liste différente mais contient les memes objets (ya qu'une fois les objets 1,2,3 en mémoire)

http://ideone.com/TMh4mz

jme dmemande si ca se fait quand le script est compiler en bytecode ou lors du runtime

elite_2009
Posté le 9 août 2013 à 19:26:04
zaver dja remarquer qu'avec python les objet etait partager ?

par exemple

A = [1,2,3]
B = [3,2,1]

A et B sont 2 liste différente mais contient les memes objets (ya qu'une fois les objets 1,2,3 en mémoire)

http://ideone.com/TMh4mz

jme dmemande si ca se fait quand le script est compiler en bytecode ou lors du runtime

Tiens oui j'avais jamais remarqué, aprés une petite recherche (et test pour confirmer), ca arrive uniquement au entier entre -5 et 256 (qui serait mit en cache par python)

Au vu de la première page, tout le monde choisit Python pour commencer. Alors Chris, ça rage sec ?

Le noob n'en démord pas en plus.
Les seuls mecs qui ont répondu python c'est des mecs qui ont été mauvais et n'ont pas réussi à apprendre la programmation avec le C, et qui ont enfin compris quand on leur a appris une deuxieme fois (avec python).
Forcément c'est plus facile d'apprendre un truc que tu es déjà censé connaitre (2eme apprentissage, avec python) qu'un truc inconnu sans aucune base connue (1er apprentissage, avec C)

tarabiscotte : Oui, je rage sec. C'est inadmissible qu'un fouteur de merde tel que toi n'ait pas encore été banni./

C est un langage qui paraitra très très très compliqué pour un débutant totalement nouveau à la programmation si il n'a pas les bonnes ressources. CEPENDANT, après le C, on comprend BEAUCOUP mieux comment les autres langages fonctionnent ainsi que tout ce qui est bas niveau (par exemple après avoir fait du Java je me suis rendu compte de tout ce que Java nous faisait ignorer et j'avais donc appris plein de mauvaises habitudes car je ne comprenais pas comment ca fonctionnait (gestion de la mémoire etc)) Je conseille d'abord d'apprendre le C, parce qu'après tu auras tous les outils nécéssaires pour apprendre un autre langage facilement, tandis que si tu commences par un autre langage, tu vas devoir apprendre beaucoup de choses en compte qui sont essentielles au moment même(surtout ce qui est allocation de données, pointeurs, structures, etc etc), et là, ca va s'avérer difficile et il te faudra de la motivation en plus des bonnes ressources.

Pour appuyer mes propos voici les MEILLEURES ressources selon moi pour apprendre à cerner les pointeurs et ce qu'il s'y rapporte : http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/CUJ/1993/9302/skelly/skelly.htm
http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/CUJ/1993/9303/skelly/skelly.htm