Conseils pour les programmes à l'écrit ?
Conseils pour les programmes à l'écrit ?
Bonjour,
Je suis en option info, je parle donc ici exclusivement des épreuves en caml.
Les programmes, c'est pas mon fort à l'écrit. Je veux m'améliorer pour les écrits qui arrivent bientôt.
J'ai donc quelques petites questions :
- Quelle fonctions caml est-il utile de connaître ? (je connais : do_list, map, it_list, list_it, mem, exists et forall)
- Comment sortir d'une boucle ? (l'équivalent du "break" python, il me semble qu'il faut faire un failwith, mais je suis pas certain...)
- Comment présenter son programme ? Faut-il le commenter ?
- Des conseils généraux ? (par exemple, comment procéder pour trouver un algorithme efficace ?)
Et pour l'épreuve Info A X-ENS, avez vous des infos sur les coefficients ? (faut-il employer la stratégie "grappillage de points un peu partout" comme en maths dans certains concours ou plutôt "je fais les premières parties le plus proprement possibles, quitte à ne pas toucher la fin, comment aux épreuves spécifiques aux ENS)
Je vous remercie par avance !
Je suis en option info, je parle donc ici exclusivement des épreuves en caml.
Les programmes, c'est pas mon fort à l'écrit. Je veux m'améliorer pour les écrits qui arrivent bientôt.
J'ai donc quelques petites questions :
- Quelle fonctions caml est-il utile de connaître ? (je connais : do_list, map, it_list, list_it, mem, exists et forall)
- Comment sortir d'une boucle ? (l'équivalent du "break" python, il me semble qu'il faut faire un failwith, mais je suis pas certain...)
- Comment présenter son programme ? Faut-il le commenter ?
- Des conseils généraux ? (par exemple, comment procéder pour trouver un algorithme efficace ?)
Et pour l'épreuve Info A X-ENS, avez vous des infos sur les coefficients ? (faut-il employer la stratégie "grappillage de points un peu partout" comme en maths dans certains concours ou plutôt "je fais les premières parties le plus proprement possibles, quitte à ne pas toucher la fin, comment aux épreuves spécifiques aux ENS)
Je vous remercie par avance !
Re: Conseils pour les programmes à l'écrit ?
Pour sortir de la boucle, il me semble que failwith c'est plutôt pour un message d'erreur.
La syntaxe correcte serait plutôt (pour une levée d'exception) :
if condition then raise Exit
-
-
-
in Try (valeur) with Exit -> Resultat
La syntaxe correcte serait plutôt (pour une levée d'exception) :
if condition then raise Exit
-
-
-
in Try (valeur) with Exit -> Resultat
Re: Conseils pour les programmes à l'écrit ?
Il faut commenter les programmes compliqués, pas les simples (à part en IPT aux Mines où le rapport demande de ne pas commenter, c'est toujours bien vu)
Une autre initiative toute bête appréciée des correcteurs : écrire son code dans une autre couleur
Attention avec mem ou forall : il me semble qu'il y a une complexité cachée dans de tels programmes, donc c'est déconseille de les utiliser s'ils ne sont pas proposés dans le sujet
Une autre initiative toute bête appréciée des correcteurs : écrire son code dans une autre couleur
Attention avec mem ou forall : il me semble qu'il y a une complexité cachée dans de tels programmes, donc c'est déconseille de les utiliser s'ils ne sont pas proposés dans le sujet
2016-2018 : Louis-le-Grand MPSI-MP*
X2018
X2018
Re: Conseils pour les programmes à l'écrit ?
Je plussoie fortement l'utilisation d'une autre couleur pour le code.
Pour les fonctions de base, il peut être utilie de savoir ce qu'elles font, pour pouvoir les utilser si le sujet vous invite à le faire. Il me semble que l'on a pas le droit de les utilser dans le cas contraire.
C'est d'ailleurs une bonne habitude à prendre de s'informer sur les fonctions que l'on utilise parce qu'utilisées en boites noires, elles ont une complexité inconnue.
Pour les fonctions de base, il peut être utilie de savoir ce qu'elles font, pour pouvoir les utilser si le sujet vous invite à le faire. Il me semble que l'on a pas le droit de les utilser dans le cas contraire.
C'est d'ailleurs une bonne habitude à prendre de s'informer sur les fonctions que l'on utilise parce qu'utilisées en boites noires, elles ont une complexité inconnue.
Re: Conseils pour les programmes à l'écrit ?
On ne sort pas prématurément d'une boucle en Caml. Certes les exceptions permettent de le faire mais ça n'est pas au programme, ça n'est pas judicieux dans ce qu'il est demandé de faire au concours et si vous ne le savez pas déjà ce n'est plus le moment de vous y mettre.
Re: Conseils pour les programmes à l'écrit ?
Le "break" en général, c'est un peu sale. Il faut essayer de caser la condition d'arrêt dans le "while".
Re: Conseils pour les programmes à l'écrit ?
On recommande l'utilisation de boucle en caml aux concours ?
Il me semblait qu'il était demandé d'écrire du code purement fonctionnel, du moins à l'époque.
Il me semblait qu'il était demandé d'écrire du code purement fonctionnel, du moins à l'époque.
"L'enfant est le père de l'homme" (William Wordsworth)
Re: Conseils pour les programmes à l'écrit ?
La philosophie du fonctionnel c'est pas justement d'éviter de faire des sorties de boucle sales, et de juste prévoir une condition pour arrêter la récursion ?
(D'une manière générale, les break et les go to sont à proscrire en programmation itérative, du if et du while suffisent (et if autant que possible, while pas plus que nécessaire, tant que le but n'est pas d'optimiser).)
(D'une manière générale, les break et les go to sont à proscrire en programmation itérative, du if et du while suffisent (et if autant que possible, while pas plus que nécessaire, tant que le but n'est pas d'optimiser).)
Chaque vénérable chêne a commencé par être un modeste gland. Si on a pensé à lui pisser dessus.
Re: Conseils pour les programmes à l'écrit ?
En fonctionnel pur justement tu n'utilises pas de boucle du tout, donc pas de for et pas de while.
Pas d'accord du tout sur le fait que break soit sale en programmation itérative.
Un break permet parfois de faire du code très lisible, permet d'éviter de faire des if imbriqués qui rendent le code pourri en indentation.
En python, on peut même faire quelque chose comme :
Le code à l'intérieur du "else" n'est exécuté que si la boucle s'est déroulée sans passer par le break.
En fait, que ce soit pour goto, break, continue, il suffit de se demander :
"Est ce que mon code est plus lisible avec ou non"
Si la réponse est oui, il n'y a pas de problème à l'utiliser.
En informatique, la lisibilité du code prime avant tout.
Pas d'accord du tout sur le fait que break soit sale en programmation itérative.
Un break permet parfois de faire du code très lisible, permet d'éviter de faire des if imbriqués qui rendent le code pourri en indentation.
En python, on peut même faire quelque chose comme :
Code : Tout sélectionner
for element in my_list:
if element >= seuil:
print("seuil atteint")
break
else:
print("seuil non atteint")
En fait, que ce soit pour goto, break, continue, il suffit de se demander :
"Est ce que mon code est plus lisible avec ou non"
Si la réponse est oui, il n'y a pas de problème à l'utiliser.
En informatique, la lisibilité du code prime avant tout.
"L'enfant est le père de l'homme" (William Wordsworth)
Re: Conseils pour les programmes à l'écrit ?
Le truc avec Caml, c'est que contrairement à Python (dont tous les élèves de prépa ont l'habitude du coup), on ne peut pas faire de return à l'intérieur de la boucle while, du coup c'est assez dérangeant parfois.
Sinon, l'épreuve d'informatique d'hier était 100% impératif, -L-C, du coup je pense que t'as la réponse à ta question
Sinon, l'épreuve d'informatique d'hier était 100% impératif, -L-C, du coup je pense que t'as la réponse à ta question