Page 1 sur 2

Conseils pour les programmes à l'écrit ?

Posté : dim. avr. 15, 2018 5:34 pm
par MiKiDe
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 !

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

Posté : lun. avr. 16, 2018 10:56 pm
par Desert
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

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

Posté : mar. avr. 17, 2018 9:49 am
par Syl20
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

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

Posté : mar. avr. 17, 2018 2:53 pm
par Zehir
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.

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

Posté : jeu. avr. 19, 2018 1:54 pm
par YS1
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.

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

Posté : jeu. avr. 19, 2018 4:45 pm
par Hazherty
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 ?

Posté : ven. avr. 20, 2018 3:28 pm
par -L-C-
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.

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

Posté : ven. avr. 20, 2018 3:51 pm
par siro
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).)

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

Posté : ven. avr. 20, 2018 5:56 pm
par -L-C-
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.

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

Posté : ven. avr. 20, 2018 8:54 pm
par Desert
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

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

Posté : dim. avr. 22, 2018 6:52 pm
par CendreWapiti
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

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

Posté : dim. avr. 22, 2018 7:04 pm
par darklol
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.

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

Posté : dim. avr. 22, 2018 11:15 pm
par Zehir
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.

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

Posté : lun. avr. 23, 2018 8:11 am
par darklol
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...

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

Posté : lun. avr. 23, 2018 10:03 am
par Hazherty
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".