Conseils pour les programmes à l'écrit ?

Modérateur : Michel Quercia

MiKiDe
Messages : 35
Enregistré le : dim. oct. 16, 2016 8:01 pm
Classe : MP* 5/2

Conseils pour les programmes à l'écrit ?

Message par MiKiDe » dim. avr. 15, 2018 5:34 pm

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 !

Desert
Messages : 104
Enregistré le : mar. août 08, 2017 11:42 pm

Re: Conseils pour les programmes à l'écrit ?

Message par Desert » lun. avr. 16, 2018 10:56 pm

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

Avatar du membre
Syl20
Messages : 1689
Enregistré le : sam. janv. 16, 2016 4:51 pm
Classe : MPSI

Re: Conseils pour les programmes à l'écrit ?

Message par Syl20 » mar. avr. 17, 2018 9:49 am

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
2016-2018 : Louis-le-Grand MPSI-MP*
X2018

Zehir
Messages : 80
Enregistré le : mar. avr. 25, 2017 11:25 am
Classe : Mage
Localisation : 127.0.0.1
Contact :

Re: Conseils pour les programmes à l'écrit ?

Message par Zehir » mar. avr. 17, 2018 2:53 pm

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.

YS1
Messages : 47
Enregistré le : dim. févr. 06, 2005 12:50 pm
Classe : MPSI, PCSI, MP*, PC*

Re: Conseils pour les programmes à l'écrit ?

Message par YS1 » jeu. avr. 19, 2018 1:54 pm

MiKiDe a écrit :
dim. avr. 15, 2018 5:34 pm
- Comment sortir d'une boucle ? (l'équivalent du "break" python, il me semble qu'il faut faire un failwith, mais je suis pas certain...)
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.

Hazherty
Messages : 270
Enregistré le : lun. août 01, 2011 9:09 pm
Classe : Doctorat

Re: Conseils pour les programmes à l'écrit ?

Message par Hazherty » jeu. avr. 19, 2018 4:45 pm

Le "break" en général, c'est un peu sale. Il faut essayer de caser la condition d'arrêt dans le "while".

Avatar du membre
-L-C-
Messages : 203
Enregistré le : dim. mai 25, 2008 9:55 pm
Classe : Ingénieur (ENSIIE)

Re: Conseils pour les programmes à l'écrit ?

Message par -L-C- » ven. avr. 20, 2018 3:28 pm

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.
"L'enfant est le père de l'homme" (William Wordsworth)

Avatar du membre
siro
Messages : 3063
Enregistré le : dim. mai 01, 2016 8:09 pm
Classe : Cassandre

Re: Conseils pour les programmes à l'écrit ?

Message par siro » ven. avr. 20, 2018 3:51 pm

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).)
Chaque vénérable chêne a commencé par être un modeste gland. Si on a pensé à lui pisser dessus.

Avatar du membre
-L-C-
Messages : 203
Enregistré le : dim. mai 25, 2008 9:55 pm
Classe : Ingénieur (ENSIIE)

Re: Conseils pour les programmes à l'écrit ?

Message par -L-C- » ven. avr. 20, 2018 5:56 pm

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 :

Code : Tout sélectionner

for element in my_list:
	if element >= seuil:
		print("seuil atteint")
		break
else:
	print("seuil non atteint")
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.
"L'enfant est le père de l'homme" (William Wordsworth)

Desert
Messages : 104
Enregistré le : mar. août 08, 2017 11:42 pm

Re: Conseils pour les programmes à l'écrit ?

Message par Desert » ven. avr. 20, 2018 8:54 pm

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 :D

CendreWapiti
Messages : 156
Enregistré le : ven. déc. 19, 2014 6:35 pm
Classe : MP*

Re: Conseils pour les programmes à l'écrit ?

Message par CendreWapiti » dim. avr. 22, 2018 6:52 pm

Le bon bail, c'est d'écrire tous les programmes au crayon à papier.
J'ai fait ça à tous mes ds d'info et ça avait pas l'air de déplaire aux profs.
Aux concours aussi c'est bien passé

Comme ça, tu peux écrire direct tes programmes sur ta copie, et corriger simplement les programmes en gommant, c'est un énorme gain de temps
2014 - 2015 : MPSI2 Chaptal
2015 - 2016 : MP* Chaptal
X 2016

darklol
Messages : 787
Enregistré le : dim. avr. 19, 2015 12:08 am

Re: Conseils pour les programmes à l'écrit ?

Message par darklol » dim. avr. 22, 2018 7:04 pm

siro a écrit :
ven. avr. 20, 2018 3:51 pm
(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).)
C’est souvent 10x plus lisible d’avoir des break ou des continue plutôt que 50 ifs imbriqués, cf message de -L-C-. D’ailleurs même goto est indispensable dans les langages avec une gestion des erreurs un peu primaire, genre en C ou en Go.
ENS Lyon

Zehir
Messages : 80
Enregistré le : mar. avr. 25, 2017 11:25 am
Classe : Mage
Localisation : 127.0.0.1
Contact :

Re: Conseils pour les programmes à l'écrit ?

Message par Zehir » dim. avr. 22, 2018 11:15 pm

darklol a écrit :
dim. avr. 22, 2018 7:04 pm
siro a écrit :
ven. avr. 20, 2018 3:51 pm
(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).)
C’est souvent 10x plus lisible d’avoir des break ou des continue plutôt que 50 ifs imbriqués, cf message de -L-C-. D’ailleurs même goto est indispensable dans les langages avec une gestion des erreurs un peu primaire, genre en C ou en Go.
Je suis d'accord pour les breaks. Il y a aussi des cas où ils font quasiment partie de la syntaxe, par exemple dans les switchs. Pour les goto, le fait est qu'il a une réputation assez sale, et il y a souvent (mais pas toujours) moyen de s'en passer.

darklol
Messages : 787
Enregistré le : dim. avr. 19, 2015 12:08 am

Re: Conseils pour les programmes à l'écrit ?

Message par darklol » lun. avr. 23, 2018 8:11 am

On voit que t’as jamais eu à écrire de la gestion d’erreurs en C.

Blague à part, évidemment que 99.9% du temps on s’en passe et à raison (d’ailleurs beaucoup de langages n’ont pas cette instruction et s’en portent bien), mais c’est exactement ce que j’ai dit, parfois il est indispensable, j’ai pas dit qu’il était tout le temps indispensable. Quand on dit qu’il a une « réputation assez sale », encore faut-il savoir la justifier, ce que beaucoup de gens ne savent pas faire, plutôt que de colporter sans cesse un adage qu’on ne comprend pas...
ENS Lyon

Hazherty
Messages : 270
Enregistré le : lun. août 01, 2011 9:09 pm
Classe : Doctorat

Re: Conseils pour les programmes à l'écrit ?

Message par Hazherty » lun. avr. 23, 2018 10:03 am

Dans des cas bien particuliers, les breaks et goto peuvent se rendre utile (mais je ne vois pas quand ils sont indispensables, on peut toujours s'en sortir avec une autre condition d'arrêt ou un appel de fonction).

Le problème avec ces instructions, surtout le goto, c'est qu'elles peuvent rendre du code illisible autant qu'elles peuvent le simplifier. Elles sont donc généralement déconseillées aux débutants.
Les rares fois où j'ai vu une utilisation intelligente de goto, c'est pour la gestion d'erreurs style try-catch, ou de l'optimisation du flot de contrôle pour l'embarqué.

D'où ma phrase "c'est un peu sale", et non "cette instruction devrait disparaître puisqu'on peut faire sans".

Répondre

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 2 invités