Discussion :

[Fractal LLG]

franchement, parmi ce qui préparaient les ENS dans notre lycée (situé à une station de métro de LLG ), personne n'a réellement fait quelque chose de nouveau, on faisait surtout une application de travaux existant, et une tentative d'explication du phénomène avec des connaissances théoriques ne dépassant pas le niveau prépa...
mais il est vrai qu'on est pas monté au-dessus de 15/20 pour le TIPE ENS

Dixit mon prof de maths (pour les TIPE de maths, mais c'est sans doute à peu près pareil pour ceux d'info) la valeur ajoutée attendue aux ENS est simplement que l'on comprenne de quoi on cause. Pas la peine d'inventer des trucs nouveaux, il faut juste choisir un sujet, de préférence un poil pointu, mais surtout le maîtriser à fond.

Tu n'auras pas le temps de faire quelque chose de substantiel pour les ENS.

Qu'est-ce que t'appelles quelque chose de substantiel?
Mon interpréteur de formules mathématiques est quasiment fini, il ne me reste plus qu'à bien vérifier rigoureusement que tous les cas possibles sont traités, je viens encore d'en trouver deux non couverts par mes match.
Du coup il devrait largement être fini ce week-end si je m'y met bien.
Après c'est sûr que j'aurai pas le temps de faire un compilateur C++ pour les concours, mais c'est pas ça qu'on demande non plus.

C'est mon humble avis, si tu n'as pas encore commencé et si tu n'as aucune base, ce qui, je crois, est le cas.

J'apprends vite

Fractal

[Fractal LLG]

J'ai posté le code de mon interpréteur ici http://www.developpez.net/forums/sho...70#post3051570 (dans le sujet original vu que c'est une réponse directe au défi, et n'a plus tout à fait directement à voir avec les TIPE)

Fractal

[alex_pi]

@IOWT : je crois qu'il est en sup, ce qui lui laisse un an avant les TIPE des ENS, donc ça devrait le faire !

@Fractal : je pense personnellement que c'est un peu léger comme sujet, surtout si tu as réussi à coder le truc en un week-end. Effectivement, il n'est pas demandé de faire quelque chose de nouveau (par rapport à l'état de l'art), mais quand même de s'approprier un sujet complexe. Ecrire un parseur ad-hoc pour expression rationnelle, en étant un peu guidé, c'est l'affaire de quelques heures de boulot, ce qui me semble loin d'être suffisant. Par exemple écrire un mini-yacc serait déjà plus ambitieux et nécessiterait réellement de comprendre certains mécanismes théoriquement intéressants.

Enfin après, quand j'ai passé les ENS option info, j'ai présenté un TIPE de mécanique quantique (sur le modèle du noyau atomique, pas d'info quantique), donc je ne connais pas les exigences spécifique en info :-)

[Fractal LLG]

@IOWT : je crois qu'il est en sup, ce qui lui laisse un an avant les TIPE des ENS, donc ça devrait le faire !

En effet

@Fractal : je pense personnellement que c'est un peu léger comme sujet, surtout si tu as réussi à coder le truc en un week-end. Effectivement, il n'est pas demandé de faire quelque chose de nouveau (par rapport à l'état de l'art), mais quand même de s'approprier un sujet complexe. Ecrire un parseur ad-hoc pour expression rationnelle, en étant un peu guidé, c'est l'affaire de quelques heures de boulot, ce qui me semble loin d'être suffisant. Par exemple écrire un mini-yacc serait déjà plus ambitieux et nécessiterait réellement de comprendre certains mécanismes théoriquement intéressants.

Voui, au début je pensais que ce serait très difficile, mais finalement j'ai assez vite progressé et ce n'est finalement pas si compliqué que ça étant donnée la simplicité de la grammaire en jeu.
Donc si jamais je prends un sujet de ce genre en TIPE, je m'intéresserai très probablement à un truc plus évolué, comme un mini compilateur comme me le proposait Millie, ou bien effectivement un analyseur syntaxique du genre yacc qui pourrait aussi être très intéressant
Après, ce qu'on dit c'est qu'aux ENS ce n'est pas le TIPE qui est mis à l'épreuve, mais le candidat, donc si on fait un truc léger mais qu'on maîtrise super bien toute la théorie sous-jacente, ça devrait aussi pouvoir le faire.

Fractal

[gorgonite]

Donc si jamais je prends un sujet de ce genre en TIPE, je m'intéresserai très probablement à un truc plus évolué, comme un mini compilateur comme me le proposait Millie, ou bien effectivement un analyseur syntaxique du genre yacc qui pourrait aussi être très intéressant

franchement, tu peux jouer avec un mini-compilateur avec passage sous forme SSA et quelques petites optimisations... si tu choisis un langage itératif simple, ça devrait être assez facile à faire, et de permettre de pouvoir extrapoler durant l'oral sur des points non évoqués dans le rapport, et pourtant forcemment étudiés

Après, ce qu'on dit c'est qu'aux ENS ce n'est pas le TIPE qui est mis à l'épreuve, mais le candidat, donc si on fait un truc léger mais qu'on maîtrise super bien

pas trop léger non plus

[InOCamlWeTrust]

franchement, tu peux jouer avec un mini-compilateur avec passage sous forme SSA et quelques petites optimisations... si tu choisis un langage itératif simple, ça devrait être assez facile à faire, et de permettre de pouvoir extrapoler durant l'oral sur des points non évoqués dans le rapport, et pourtant forcemment étudiés

Je suis d'accord, mais souviens-toi : pas tout le monde est prêt à passer sa vie sur son TIPE comme toi et moi on l'a fait jadis...

pas trop léger non plus

Moi je dirais plutôt : pas trop banal non plus... surtout pour les ENS.

Ce sont des sujets si banals que tu auras toutes les chances de te retrouver en face de spécialistes qui n'hésiteront pas à te poser des questions très pointues sur le sujet. Ils n'attendent pas que tu saches tout, mais au moins que tu aies acquis une culture générale de très très grande ampleur (pour un sujet aussi vaste et général), et en matière de compilation/interprétation, il y a énormément de choses à connaître. Une première TRES BONNE LECTURE est ceci...

http://gcc.gnu.org/onlinedocs/gccint/

... puis les sources quelque part par ici...

http://gcc.gnu.org/

Commence déjà par l'installer A LA MAIN et jouer avec.

Au tétra-concours, tu peux toujours proposer ton petit truc et ça ira, surtout si tu tombes avec des physiciens ou des chimistes, mais aux ENS, je ferais plutôt attention.

Personne ne doute que tu apprennes vite, mais le plus important, c'est que tu apprennes vite tes théorèmes de MP*, car ça, c'est ce qui fait clairement la différence à l'écrit comme à l'oral.

[InOCamlWeTrust]

Qu'est-ce que j'écrivais?

Désolé, mais je ne lis pas toujours tous les posts... avant de poster ! Mais c'est sûr, on est d'accord sur ce point, ainsi que sur les académiciens français.

[alex_pi]

Une première TRES BONNE LECTURE est ceci...

http://gcc.gnu.org/onlinedocs/gccint/

... puis les sources quelque part par ici...

http://gcc.gnu.org/

T'as pas trouvé plus compliqué, pour commencer, qu'un compilo réel d'un langage à la sémantique non définie, et en plus écrit en C ? Le bouquin d'Appel, Modern compiler, implementation in ML est peut être un peu plus accessible au commun des mortels quand même..

[LLB]

- Dans les cas "simples" (qui ne le sont pas toujours pour les générateurs), ils sont plus compliqués à utiliser que d'écrire un parseur à la main.

C'est peut-être une question d'habitude, mais j'ai passé beaucoup moins de temps à écrire mon code lex/yacc pour le défi que je ne l'aurais fait à la main. Pour les cas simples et moyens, j'ai l'impression de gagner du temps en les utilisant. Je suis d'accord avec toi, la gestion des erreurs n'est vraiment pas pratique.


Que pensez-vous des parseurs de type Parsec (la question est posée aussi à Jedai) ?

J'ai fait quelques essais, et ça m'a bien plu. J'aime le principe de ne pas séparer le lexeur et le parser (je trouve la séparation assez peu naturelle et cela m'a gêné plus d'une fois avec yacc). Mais, je n'ai jamais testé sur un vrai langage et je manque vraiment de recul. La prochaine fois que j'aurais à écrire un compilateur (ou quelque chose de semblable), il est probable que je me penche sur ces parseurs. Notamment, j'ai été très agréablement surpris par les messages d'erreur.

[Jean-Marc.Bourguet]

C'est peut-être une question d'habitude,

C'est certain que ça joue aussi. Mettre en oeuvre une technique qu'on ne maîtrise pas est toujours plus compliqué que mettre en oeuvre une technique qu'on maîtrise parce qu'on complique en ajoutant un problème d'apprentissage.

[Jedai]

C'est peut-être une question d'habitude, mais j'ai passé beaucoup moins de temps à écrire mon code lex/yacc pour le défi que je ne l'aurais fait à la main. Pour les cas simples et moyens, j'ai l'impression de gagner du temps en les utilisant. Je suis d'accord avec toi, la gestion des erreurs n'est vraiment pas pratique.

Tu as passé beaucoup de temps pour écrire ton code FParsec (après la phase d'apprentissage) ? Parce que Parsec c'est pratiquement un générateur écrit à la main, sauf que l'interface est beaucoup plus agréable que de tout faire à la main grâce à l'approche combinatoire (rendue facile par les langages fonctionnels).

Que pensez-vous des parseurs de type Parsec (la question est posée aussi à Jedai) ?

C'est très sympa, tu peux faire des choses complexes assez vite et tu ne passes pas ton temps à réimplémenter les idiomes courant pour structurer une grammaire. D'un autre côté, c'est un peu plus verbeux que Yacc (sauf quand tu as l'occasion de prendre avantage de certains des combinateurs de haut niveau).
Ce n'est pas la solution ultime par contre ! Par exemple ça pèche pas mal sur les très gros fichiers (mais Yacc aussi, les parseurs incrémentaux c'est pas trop son truc) et des try incontrôlés cassent les performances.

J'ai fait quelques essais, et ça m'a bien plu. J'aime le principe de ne pas séparer le lexeur et le parser (je trouve la séparation assez peu naturelle et cela m'a gêné plus d'une fois avec yacc). Mais, je n'ai jamais testé sur un vrai langage et je manque vraiment de recul. La prochaine fois que j'aurais à écrire un compilateur (ou quelque chose de semblable), il est probable que je me penche sur ces parseurs.

J'ai déjà fait un parseur pour un langage fonctionnel à la complexité raisonnable, quand on a l'habitude c'est assez facile et gratifiant (surtout si on peut faire usage de Parsec.Langage).
Par ailleurs, tu peux séparer le Lexeur et le Parseur, c'est moins souvent nécessaire qu'avec Lex et Yacc, mais c'est parfaitement possible, Parsec peut agir sur des flux de symboles quelconque (dans sa dernière version, sinon il ne peut agir que sur des listes (éventuellement paresseuses) de symboles quelconques).

--
Jedaï

[LLB]

Tu as passé beaucoup de temps pour écrire ton code FParsec (après la phase d'apprentissage) ?

Je l'ai écrit pendant ma phase d'apprentissage. Du coup, j'ai passé un peu de temps à comprendre les opérateurs et les types, mais après, ça a été relativement simple.

Parce que Parsec c'est pratiquement un générateur écrit à la main, sauf que l'interface est beaucoup plus agréable que de tout faire à la main grâce à l'approche combinatoire (rendue facile par les langages fonctionnels).

Oui, cet aspect me plait beaucoup. J'ai l'impression d'avoir beaucoup plus de contrôle qu'avec Yacc, mais de rester dans du code assez expressif (plus concis qu'un parseur à la main). J'ai déjà rencontré des difficultés à parser certaines grammaires avec yacc, Parsec me semble plus adapté pour ces cas (à voir).

D'un autre côté, c'est un peu plus verbeux que Yacc

Ah, d'accord. Je testerai pour comparer.

Par exemple ça pèche pas mal sur les très gros fichiers

L'auteur de FParsec a indiqué :

It can parse context-sensitive, infinite look-ahead grammars, has complete support for unicode input and large files (> 4 GB) and produces excellent error messages. Design and implementation have been optimized for speed and should provide sufficient performance even for demanding applications.

Je suis sûr que cela suffira largement pour mes besoins. fsyacc ne m'a jamais gêné en terme de vitesse et fparsec serait 2 fois plus rapide.

Merci pour le retour.

[omarjock]

bonjour,
essaya l'API JEP dans java, elle permet de parser une expression mathématique et de l'évaluer. c'est vraiment efficace.