Liste dans l'ordre croissant

[invite85dfa38b]

Bonjour à tous,

Je dois écrire un algorithme récursif qui permet de trier les éléments d'une liste dans l'ordre croissant.
Je reste perplexe devant ce que j'ai écrit et je n'ai pas moyen de le faire fonctionner pour le moment.

list<int> trie(list<int> li)
{
return (queue(li)==liVide<int>()? li: (tete(li)<tete(queue(li))? (queue(queue(li))=liVide<int>( )? cons(tete(li),trie(queue(li)): cons(trie(cons(tete(li),queue( queue(li))),queue(li)): trie(cons(queue(li),cons(queue (queue(li)),tete(li))))))).
}

C'est le langage "spécifique" à ma fac, un mélange de C et C++ parait-il.
Quelqu'un serait-il capable de m'aider ?

Merci beaucoup.
-----

[Paraboloide_Hyperbolique]

Bonsoir,

Tel qu'écrit, votre code a peu de chance de fonctionner. En fait, je ne vois même pas ce qu'il est censé faire parce que plusieurs fonctions ne sont pas définies: queue, tete et cons.

Je recommande en premier lieu d'écrire en pseudo-code (en français) les différentes étapes de l'algorithme, puis de le coder dans le langage voulu.

Si vous souhaitez tester votre code (qui ressemble à du C++) sur votre pc, vous pouvez télécharger Code::Blocks. https://sourceforge.net/projects/cod...p.exe/download

[invite85dfa38b]

Bonsoir,

Merci pour le lien.
Cons revient à concaténer.
Tête prend le premier élément de la liste et renvoie un nombre.
Queue renvoie la liste sans la tête.

[Jack]

Essaie de remplacer l'opérateur ternaire ?: par if else, ça devrait éclaircir la lecture de l'algo

[A voir en vidéo sur Futura]

[invite936c567e]

Bonsoir

Tout me porte à croire qu'il est devenu habituel à la fac d'écrire les algos de la sorte, mais je pense utile de préciser qu'en pratique c'est totalement irréaliste et contreproductif.

L'écriture condensée du C est vraiment pénible à lire. D'une part elle rend difficile les échanges d'informations entre intervenants humains alors qu'elle devrait au contraire les faciliter. D'autre part elle n'apporte rien au code généré. Alors, sauf à vouloir faire de l’offuscation de code, on ne doit y recourir que de façon raisonnée et, quoi qu'il en soit, limitée.

Les appels récursifs de fonction font une consommation conséquente de mémoire (enregistrement des paramètres, variables locales et adresses de retour) et de temps machine (accès mémoire/caches/swap pour empilage/dépilage). Sauf à pouvoir prouver que les ressources disponibles seront suffisantes pour réaliser l'opération voulue avec des performances acceptables, il est fortement déconseillé de recourir à ce procédé pour coder des traitements récurrents. Le recours à des boucles constitue en principe une solution beaucoup plus maîtrisable et plus efficace.

En tout cas, ces pratiques sont la raison principale pour laquelle, dans mon entreprise, on ne fait plus appel à des stagiaires issus du cursus universitaire. Du fait des défauts rédhibitoires qui en découlent (code difficilement maintenable, exécution excessivement lente, dépassements de capacité mémoire, ...), tous les logiciels produits lors des nombreux stages effectués ont dû être jetés puis refaits depuis le début dans l'urgence.

[invite6486d7bd]

En tout cas, ces pratiques sont la raison principale pour laquelle, dans mon entreprise, on ne fait plus appel à des stagiaires issus du cursus universitaire. Du fait des défauts rédhibitoires qui en découlent (code difficilement maintenable, exécution excessivement lente, dépassements de capacité mémoire, ...), tous les logiciels produits lors des nombreux stages effectués ont dû être jetés puis refaits depuis le début dans l'urgence.

+100

C'est à mon avis lié à une erreur de base qui consiste à faire croire que l'algorithme est la clef de voute de la programmation alors qu'il s'agit d'une première approche, un moyen d'étudier les solutions.

Lorsqu'on voit d'autre part qu'il est systématiquement demandé de calculer la complexité algorithmique et d'y faire appel comme si elle permettait de prouver l’efficacité d'un programme (ca peut donner une idée dans un certain nombre de cas, certes, et encore...), il ne faut pas s'étonner que ceux qui pratiquent cette méthode sont inaptes lorsqu'il s'agit de produire une réalisation concrète.
un conseil donc, apprendre à scinder les algorithmes pour augmenter l'efficacité, faire appel à des tables intermédiaires pré-calculées par exemple, et surtout penser l'algorithme comme une aide, relativement au langage cible, à la machine cible et aux exigences de performance (souvent évidentes lorsqu'on doit avoir du temps réel) situées à un niveau plus élevé dans le cahier des charges.

Un bon programme, c'est celui qui satisfait le client (peut-être préfère-t-il que la maintenance soit facilitée au détriment d'une petite baisse de performance etc), pas celui qui satisfait "la théorie".
.

[albanxiii]

Un bon programme, c'est celui qui satisfait le client (peut-être préfère-t-il que la maintenance soit facilitée au détriment d'une petite baisse de performance etc), pas celui qui satisfait "la théorie".
.

Malheureusement, cela s'apprend surtout sur le tas.
Si le entreprises ne prennent plus d'étudiants ou jeunes diplômés, on entre dans un cercle vicieux.

Quand on prend un stagiaire, on l'encadre, on lui apprend la pratique et on le fait progresser, on ne le laisse pas se débrouiller seul dans son coin.

[invite936c567e]

Malheureusement, cela s'apprend surtout sur le tas.
Si le entreprises ne prennent plus d'étudiants ou jeunes diplômés, on entre dans un cercle vicieux.

Quand on prend un stagiaire, on l'encadre, on lui apprend la pratique et on le fait progresser, on ne le laisse pas se débrouiller seul dans son coin.

Ce n'est pas non plus le rôle de l'entreprise de se substituer à l'école.

Il y a effectivement des choses qu'on apprend sur le tas, mais qui nécessitent des bases normalement acquises durant le cycle scolaire. Or, on constate trop souvent que celles-ci ne le sont pas, ou qu'elles le sont d'une façon dévoyée qui entraîne des raisonnements et des pratiques toxiques dans les processus d'évaluation, de création et de production. (Le problème ne se limite pas aux seuls stagiaires.)

Le stage doit rester le moyen de découvrir des connaissances et des savoir-faire qui complètent ce qui a déjà été appris. Ce ne peut pas être le lieu où l'on vient désapprendre en quelque semaines des dogmes et des automatismes inadaptés inculqués des années durant, pour ensuite découvrir le métier et réaliser un travail qui en soit représentatif s'il en reste le temps.


De plus, les entreprises ne peuvent généralement pas se permettre de placer à plein temps un spécialiste emprunt de bonne pédagogie derrière chaque stagiaire pour tenter de rattraper le tir. S'agissant de stages proposés à des étudiants de l'enseignement supérieur, ceux-ci sont censés être relativement autonomes et ne requérir un encadrement que pour les diriger et les corriger à la marge.

Par ailleurs, les stages sont souvent proposés à des personnes disposant déjà d'un certain bagage au travers d'entreprises étudiantes, lesquelles offrent une prestation de service censément professionnelle qu'on rémunère en l'échange du travail effectué et de la prise en charge de tout ou partie de cet encadrement.


Il s'avère que les stagiaires employés par ce dernier moyen n'ont jamais pu rendre un travail totalement correct malgré les multiples recadrages effectués. Sans même parler des quelques têtes de mules qui n'ont absolument rien voulu entendre de nos critiques et desiderata, tous sans exception se sont laissés aller à un moment ou à un autre, ce qu'on n'a généralement pu découvrir que trop tardivement. Le travail a entièrement été refait, car les corrections qu'il aurait fallu faire sur les produits livrés auraient été encore plus longues et coûteuses.


Il me paraît donc important de tenter de corriger le tir en évoquant au plus tôt ces problèmes. L'enseignement de la théorie ne devrait pas être dissocié des aspects pratiques notamment lorsqu'il s'accompagne d'exercices, et un soin particulier doit également être apporté à communication dès lors qu'on échange sur ces sujets, sur les forums ou ailleurs.

Dans le cas présent, le seul rappel des objectifs devrait être suffisant pour montrer la voie : on n'écrit pas un programme pour embêter le monde, se donner en spectacle ou se faire plaisir dans son coin, mais pour faire comprendre une démarche et la faire réaliser par une machine. Il devrait donc devenir évident :
- que la perte de temps et le risque d'erreurs imposés par le déchiffrage d'un code abscons ne vont pas dans le sens d'une bonne communication ni d'une incitation pour les contributeurs à passer du temps à tenter de comprendre la problématique, à réfléchir et à formuler une réponse,
- que le manque de sens pratique, et notamment le recours régulier à des solutions théoriques peu réalistes, risque d'induire de mauvaises habitudes qui auront des conséquences fâcheuses.