Poste de Professeur en informatique (27e section) à l’ENS de Lyon

Enseignement

La ou le professeur intégrera le département informatique de l’ENS de Lyon. Elle/il dispensera des enseignements faisant une place importante aux aspects programmation et/ou expérimentation de l’informatique, comme par exemple : les projets de programmation, la compilation, le système, les réseaux, l’architecture, etc.Conformément aux missions des ENS, elle ou il accompagnera des étudiants vers des carrières académiques dans ces thématiques. Il est attendu que la ou le professeur s’implique fortement dans la réflexion sur l’offre de formation. Les candidatures internationales sont bienvenues, l’enseignement pouvant se faire en anglais.

Recherche

La candidate/le candidat devra développer un projet de recherche s’intégrant dans l’une des thématiques du LIP, ou apporter une nouvelle thématique en harmonie avec le spectre actuel. Ce projet de recherche devra être en cohérence avec l’activité d’enseignement proposée. Elle/il aura fait preuve d’une activité de recherche dans le domaine, ayant fait l’objet de publications ou de productions logicielles au meilleur niveau international.Elle/il pourra être amené à assurer des fonctions de type « encadrement de la recherche ». Ce recrutement est très largement ouvert : les candidatures externes françaises et étrangères sont fortement encouragées.

Le laboratoire LIP

Le LIP est une unité mixte de recherche commune au CNRS, à l’ENS de Lyon, à INRIA et à l’Université Claude Bernard Lyon 1. Il se compose actuellement de 145 membres (dont 60 enseignants-chercheurs et chercheurs, 11 ITA, 48 doctorants et 26 postdoctorants) et comprend 7 équipes de recherche. Il est localisé sur le site de l’ENS de Lyon à Gerland. L’orientation scientifique du LIP s’inscrit dans le thème général de l’informatique du calcul, allant des fondements (modèles du calcul, langages) à l’exécution (ordonnancement, intergiciels) en passant par les outils du calcul (algorithmes, compilation). Une de ses spécificités consiste en l’existence d’un continuum entre l’informatique fondamentale et la mise en œuvre pratique, permettant d’aller du théorème au transfert de technologie, via l’algorithme et le logiciel.

Comment trouver le bureau du DI ?

Comment trouver S. Zeitounian qui vous accompagne pour vos nombreuses démarches vis à vis du DI ?

Vous pouvez rejoindre facilement le bureau du DI (LE 237) en 6 étapes.

  • Étape 1: Se rendre à l’ENS bâtiment Monod.
  • Étape 2: Entrer par l’entrée opposée à l’accueil principale (vers les amphis de physique)
  • Étape 3: Avancer jusqu’aux Amphis
  • Étape 4: Prendre à gauche et passer devant les Amphis G, F et E
  • Étape 5: Tourner à droite après l’amphi E dans l’allée 2
  • Étape 6: C’est la quatrième porte sur votre droite (juste avant l’allée B)

Ouverture du lundi au vendredi

9h-12h15 / 13h15-17h00

Admistrative Office of the DI
Admistrative Office of the DI

Informations M2 (archives 2018-2019)

General Outline

The Master 2 in Computer Science is composed of classes and winter schools from September 10, 2018 to January 25, 2019, followed by an internship from January 28 to June 15, 2019. See details below.

Latest Information

Updated schedule and latest info available on the read-only password-protected pad :

https://pad.inria.fr/p/r.7e3a9396c0b060bfc755a346325a79f2

passwd: m2info18

List of Courses (for full description follow the link CRxx):

  • CR01: Optimal Decision Making and Online Optimization, Panayotis Mertikopoulos and Bruno Gaujal (Grenoble).
  • CR02: Computational Geometry, Monique Teillaud and Olivier Devillers (Nancy).
  • CR03: Hard lattice problems, Damien Stehlé. (Lyon)
  • CR04: Scheduling at scale, Yves Robert. (Lyon)
  • CR05: Advanced Topics in Scalable Data ManagementEddy Caron
  • CR06: Software Engineering & Compilation, Sebastien Mosser and Laure Gonnord (Lyon, Nice).
  • CR07: Complex NetworksMarton Karsai. (Lyon)
  • CR08: Lower bound methods, Pascal Koiran, Omar Fawzi, and Stéphan Thomassé (Lyon)
  • CR09: Approximation Theory and Proof Assistants: Certified Computations, Nicolas Brisebarre and Damien Pous (Lyon)
  • CR10: Cryptanalysis, Elena Kirshanova, Damien Stehlé, and Guillaume Hanrot (Lyon)
  • CR11: Hardware Compilation and Simulation, Christophe Alias and Matthieu Moy (Lyon)
  • CR12: Combinatorial scientific optimization, Bora Ucar, Fanny Dufossé (Lyon, Grenoble)
  • CR13: Topological combinatorics, Frédéric Meunier and Matěj Stehlík (Paris, Grenoble)
  • CR14: Advanced topics in semantics of programming language, Pierre Clairambault and Colin Riba (Lyon)
  • CR15: Logic, Automata and Games for Advanced Verification, Matteo Mio and Denis Kuperberg (Lyon)
  • CR16: Automated Deduction, and opening to Distributed Algorithms, Xavier Urbain and Sébastien Tixeuil (Lyon, Paris)
  • CR17: Machine learning, Aurélien Garivier (Lyon)

Winter Schools:  There are two winter schools taking place during weeks 48 (starting on Monday, Nov. 26) and 49 (starting on Monday, Dec.  3) . During these weeks, the courses stop and are replaced by the schools, which last the whole week. Topics will be announced later on.

Pre-course Meeting: A pre-course meeting will take place on Monday, September 10, 2018 at 9.30am, Amphi B. Attendance to this meeting is mandatory for all students. The general organization of the year and a description of the courses will be provided. Courses start on Monday, September 10, at 1:30pm.

Training Period: A mandatory training period takes place from Monday, January 21 up to mid June. An information session about topics and locations for the training period will be organized in September. Basically, the goal is to research in a laboratory (anywhere on earth), write a report and make an oral presentation in the end.

Schedule: Courses start September 10 at 1:30pm. Autumn holidays are October 27-November 4. Winter holidays are December 22-January 6. Exams will be held on week 3 (starting Monday Jan. 14), for a subset of courses. Again, the detailed weekly schedule will be available on the Inria pad mentioned above. This page will be read-only and updated on a regular basis, check it often.

Rules of the Game: To obtain their degree, CS Master students must complete 60 credits including the internship (30 credits), two winter schools (3 credits each) and four courses (4 credits each) in the above list of CR1 to CR17. To summarize, there are 52 mandatory credits out of 60 and 8 credits that can be picked elsewhere. While a typical choice by many students is 6 CR courses, 2 schools and the internship, the extra courses for the 8 credits can be chosen elsewhere,  e.g. CS courses in the M2 offered by Univ. Lyon 1, or courses from other ENS departments.

Complex Systems: There is an exception for the orientation ‘Complex Systems’. See details at

http://www.ixxi.fr/enseignement/master_systemes_complexes

for course offering. For the validation, the two winter schools are not mandatory for complex systems students, only 4 CR courses and the training period are mandatory, so after mandatory stuff there remains 14 credits instead of 8  to validate, using a selection of courses from the orientation.

Note that ‘Complex Systems’ is an orientation, not a separate M2. The only diploma delivered by ENS Lyon is M2 Informatique Fondamentale, and computer science must remain at the heart of the curriculum. In particular, the training period must be oriented towards research in core computer science (possibly applied to other disciplines).

Formal Validation: To meet the quality requirements of our program, all course choices must be approved by the academic tutor and the head of the Master 2 program. Administrative registration to chosen courses is mandatory and takes place in late September, after a trial period.

Please refer to the rules of the Master here

Contact: Yves Robert

L3 2018-2019

Toutes les informations concernant le L3 IF pour l’année 2018-2019 sont/seront disponibles sur le pad du L3, accessible ici (le mot de passe est l3info18):

https://pad.inria.fr/p/r.d202fb7f4eefd48267b01716b7a89d06

La réunion de rentrée du DI aura lieu le lundi 10 septembre à 14h en Amphi B.

Liens vers des documents utiles:

Projet L3IF — spécification de fouine

fouine — Syntaxe du langage

Cœur du langage fouine.
• expressions arithmétiques : constantes entières (y compris négatives), somme, soustraction, multiplication ;

• parenthèses ouvrantes et fermantes, construction begin.. end. Les sauts à la ligne sont possibles.

• construction let .. in
Deux exemples : let a = 3 in 2*a + a*a   et     let f x = x*x in f (f 3).

• identificateurs de variables : ils commencent par une lettre minuscule ; après, n’importe quoi en termes de chiffres et de lettres (majuscules ou minuscules) ; let oO0Oo = 0 marche, par exemple ;

• fonctions : on peut déclarer une fonction avec let f x z = .. ou avec let f = fun x -> fun z -> .. (ou un mélange des deux approches) ; on autorisera aussi fun a b c -> ...
On peut appliquer les fonctions comme dans f s t.
On peut utiliser une fonction directement sans la nommer (« fonctions anonymes ») let x = (fun x -> x) a in ...

la fonction fonction prInt. On ajoute une construction spéciale au langage, pour pouvoir faire de l’affichage et ainsi voir ce que font les programmes. Cette construction s’appelle prInt, c’est une fonction qui affiche son argument entier, va à la ligne, et renvoie pour valeur ce même argument.
Voici un petit exemple :

# 2 + prInt (1+2);;
3
- : int = 5

En Caml (mais pas en fouine), on peut définir prInt comme suit :

# let prInt x = print_int x;print_newline(); x;;
val prInt : int -> int =

On se restreindra à des usages simples de prInt ; en particulier, on ne passera pas la fonction prInt à une fonction.

NB : fouine n’est pas IMP, le petit langage vu en théorie de la programmation (pour ceux qui ont suivi ce cours) : il ne fait pas sens de séparer les expressions arithmétiques et les commandes, car « tout est expression » en fouine.

Analyse syntaxique, priorités etc. Le comportement de Caml sert de référence. La principale difficulté est le traitement des applications lorsqu’une fonction est appliquée successivement à plusieurs arguments.

Vous n’avez en particulier pas le droit d’imposer à l’utilisateur d’ajouter davantage de parenthèses que ce qui est demandé en Caml.

Voici quelques exemples illustratifs :

# let add x y = x+y;;
val add : int -> int -> int =
# 3 + add 2 3;;
- : int = 8
# let k = 3 + (fun x -> x + 1) 5;;
val k : int = 9
# let k = 3 + fun x -> x + 1 5;;
Characters 12-28:
let k = 3 + fun x -> x + 1 5;;
^^^^^^^^^^^^^^^^
Error: This expression should not be a function, the expected type is int

Syntaxe, au-delà du cœur.

if then else, uniquement avec des tests entre entiers ;
opérateurs à prendre en compte : > >= < <= = <> pour comparer des entiers,  not && || entre booléens
NB2 : en fouine, tout est expression, et 27 est une expression au même titre que (fun x -> 1+2*x) 9.
NB3 : if then else, mais pas de if then tout court.

• La construction let.. in : formes dérivées

–  ne pas nommer : vous devez autoriser l’utilisation du caractère « souligné » tout seul, dans des expressions de la forme let _ = ... in

Cette utilisation sert à ne pas nommer une expression que l’on évalue (on l’utilise généralement lorsqu’on fait des effets de bord — affichage à l’écran, écriture dans un fichier, mise à jour de référence ..).

NB : dans le type des expressions de votre interprète, il faut avoir une seule construction pour let.. in.

  – let.. in « en surface » : un programme est de la forme let x1 = e1 in let x2 = e2 in … let xn = en in e. Les déclarations des xi sont dites « en surface ». Un let.. in qui se trouve dans l’un des ei n’est pas en surface.

L’écriture ci-dessus suppose que e n’est pas à son tour un let.. in (sinon on aurait pu « développer » davantage). Dans ce cas, tout let.. in que contient e n’est pas non plus en surface.

On a droit à une écriture alternative pour les let.. in en surface, définie ainsi : si l’utilisateur saisit une expression de la forme
let x = e1 in e2
il a le droit de l’écrire
let x = e1;;
e2
et **dans ce cas**, le remplacement peut également être fait, récursivement, dans e2.

• construction let rec (en deux mots), pour définir des fonctions récursives (pas de message d’erreur si la fonction n’est pas récursive). On ne s’intéressera qu’à des définitions récursives de fonctions. Les diverses écritures pour les fonctions seront acceptées (let rec f = fun x ->, et aussi let rec f x y z = .., ou encore let rec f = fun x y z -> ..)

Aspects impératifs.

Création de références (ref), affectation (:=), lecture (!), séquence (;), unit ( () ).

Interdit d’implémenter une référence à l’aide d’une référence de Caml.

Exceptions.

Il y a une seule exception, qui est notée E, et prend un entier en argument (c’est “acquis”, au sens où les programmes fouine ne contiendront pas de déclaration exception E of int).
Constructions raise et  try .. with.
Exemples :
if t >= 12 then raise (E 17) else [5;3]
let n = try f z with E x -> x+1

On autorisera aussi l’écriture with | E x ->   (avec le « | » facultatif).
Les exceptions ne seront pas traitées comme des valeurs (pas de fonction renvoyant une exception, par exemple).

Interdit d’implémenter les exceptions à l’aide des exceptions de Caml.

 

Exécution des programmes fouine.

• Dans la version « de base », un programme fouine peut renvoyer un entier, une fonction ou un booléen.

En l’absence d’utilisation de prInt, un programme ne fait rien de visible (tout comme en Caml, à partir du moment où l’on n’utilise pas l’interprète mais le compilateur).

• Plutôt que de décrire formellement la sémantique opérationnelle de fouine, on adopte l’approche “lancez le programme avec Caml, cela vous donnera le comportement attendu”. Vous pouvez interagir avec les encadrants si vous avez des doutes sur un point précis.

Pour lancer le programme avec Caml, vous devrez insérer la définition let prInt x = print_int x; print_newline(); x au début.

Typiquement, de petits programmes comme let a = prInt 5 in a + prInt 7 ou let f x y = x*y in f (prInt 3) (2+prInt 2) vous permettront de vérifier que vous implémentez les choses comme il faut.

Affichage d’un programme fouine

Vous devez programmer une fonction qui affiche un programme fouine. Afficher le programme saisi en entrée ne donne pas nécessairement le même programme, car il se peut que des transformations élémentaires soient appliquées au passage (par exemple, let f x =.. remplacé par let f = fun x -> ..). Il faudra toutefois que le programme affiché soit accepté par Caml, en supposant que l’on ait défini la fonction prInt comme ci-dessus.

Les erreurs que ne connaı̂t pas Caml.
En Caml, un programme est typé, ce qui permet d’éviter d’exécuter des programmes absurdes comme 3 + (fun x -> x+1). Pas de typage en fouine, par conséquent certains programmes exploseront lors de l’exécution.

Réfléchissez à la gestion de ces erreurs (appelées dynamiques), et proposez une solution satisfaisante. Cela peut aller de messages d’erreur un peu explicatifs dans certains cas (quand une addition fait intervenir une fonction, par exemple) à des choses plus sophistiquées, où l’on indique d’où vient l’erreur
dans le code source.

Projet L3IF — débutants Linux

Dans un terminal

  • la touche « tab » permet de compléter la commande courante, les flèches haut et bas se promènent dans l’historique des commandes qui ont été saisies
  • tapez make pour compiler; pour « éteindre et rallumer », tapez make clean puis make
  • apprenez à vous promener dans vos répertoires à coups de cd (cd .. vous fait remonter d’un cran)
  • une fois que vos fichiers Caml sont dans un endroit déterminé, et que vous avez mis en place git pour les modifier, vous pouvez les éditer avec ce que vous voulez : vim, emacs, un environnement de développement sophistiqué, ..

Compiler et exécuter du code Caml.

  • on compile en tapant make. Il se débrouille pour comprendre quels fichiers il doit recompiler, et dans quel ordre. Il se sert d’ailleurs d’un sous-répertoire appelé _build, que vous n’avez pas à aller regarder, a priori.
  • quand on tape ./main.native < tests/t1.txt,on appelle le programme main.native, qui est dans le répertoire courant (c’est le « ./ »), en lui faisant manger le contenu du fichier t1.txt qui est dans le sous-répertoire tests
  • On ne « voit » ce que fait un programme Caml qu’à partir du moment où celui-ci interagit avec le monde extérieur. Typiquement, ce sont les fonctions d’affichage qui déclenchent quelque chose de visible. On trouve volontiers quelque chose comme
    let _ = f x y,
    invocation qui signifie « on lance le calcul de f avec x et y, et on ne donne pas de nom au résultat (le « _ », c’est « pas de nom »). L’idée ici c’est que le calcul de f aura des effets sur l’univers (modification de certaines références, affichage, ..).
  • Pour faire des open dans l’interprête Caml, il faut les précéder de la commande #load.
    • On lance Caml avec une option pour lui dire de regarder dans le répertoire _buildocaml -I _build (il y a un « _ » avant le build !)
    • On fait les incantations#load "cell.cmo";;

      open Cell;;

      et il connaît alors ce qui est défini dans le fichier cell.ml (à condition que vous ayez compilé cell auparavant).

  • Deux mots sur la question 3 du niveau Débutants du rendu 1.Pour récupérer dans un fichier les instructions du petit langage qui sert à modifier les cases du tableur, et les traduire en des valeurs Caml, on s’appuie sur ce que contiennent les fichiers lexer.mll et parser.mly.

    Il y a trois entités : la chaîne de caractères qui correspond au mot que l’on veut reconnaître (p.ex., « MULT », avec les guillemets, car c’est une chaîne de caractères) ; le mot du langage (on dit lexème, ou token) (p.ex., MULT sans guillements) ; et la valeur Caml à laquelle on aboutit (p.ex., M, qui est un constructeur du type oper, défini dans le fichier cell.ml).

    Dans lexer.mll, on associe le lexème MULT à la chaîne de caractères « MULT ». Puis, dans parser.mly, on dit que le mot MULT est associé à M, ligne 47, après avoir déclaré vers le début du fichier que MULT est un lexème. On notera en passant que parser.mly contient des règles de grammaire, dans l’esprit de ce que vous avez vu en FDI.

ER02: Calcul numérique et calcul numérique rigoureux (15-19 Janvier 2018)

Intervenants, présentation de l’école et ressources utiles : voir la version anglaise.

Planning de l’école de recherche ER02

8h15-10h 10h15-12h 14h15-16h 16h15-18h
Monday Chebyshev (amphi B) Chebyshev (salles de TP E001 et 125) Validated numerics (amphi B)
Tuesday Validated numerics (amphi B) Validated numerics (amphi B) Chebyshev (amphi B) Chebyshev (salles de TP E001 et 125)
Wednesday Chebyshev (amphi B) Validated numerics (amphi B) Validated numerics (amphi B)
Thursday Validated numerics (amphi B) Validated numerics (amphi B)
Friday Chebyshev (salles de TP E001 et 125) Chebyshev (amphi B) Exam (amphi B)