Alexandria - Derniers commentaires

Re : Part-of-Speech Tagging From 97% to 100%: Is It Time for Some Linguistics?

2012-02-06T02:41:49+01:00

merci pour cette exelente explication

j’aimerai bien que tu nous eclaircir POS pour l pen arabic tree bank

et aussi le parseur bilexical de stanford
j’ai essayé de suivre les traces de l’excecusion , le logiciel execute la fct parse de la classe exhaustivePCFG puis la fct parse() de la classe exhaustivedependency et enfin getbestparse() de la classe Bilexicalparser

j’aimerai bien que tu m’expliquele role de chaque fct et l’algorithme suivi merci

Re : Allocation Removal by Partial Evaluation in a Tracing JIT

2011-10-09T19:35:54+02:00

L’optimisation réelle n’est pas inoubliable (pour de vrais frameworks de dataflow optimization, cf. Hadoop), mais c’est une bonne description du principe des tracing JITs et du projet Pypy.

Re : Exceptional syntax

2011-10-08T15:10:42+02:00

L’idée principale est de combiner les deux syntaxes let x = foo in bar et try foo with baz en une syntaxe commune let-try x = foo with baz in bar, ayant la sémantique suivante: si foo renvoie une erreur, on la passe à baz et on renvoie le résultat (ou on la propage), et sinon on évalue bar qui peut contenir la variable x.

Ça permet de simplifier et de rendre plus efficace l’exemple classique:


let rec read_all acc =
  let result =
    try Some (read_line ())
    with End_of_file -> None in
   match result with
   | None -> List.rev acc
   | Some line -> read_all (line :: acc)


let rec read_lines acc =
  let-try line = read_line ()
  with End_of_file -> List.rev acc
  in read_all (line :: acc)

Re : Resource-safe Systems Programming with Embedded Domain Specific Languages

2011-09-18T00:11:47+02:00

Il y a plusieurs raisons pour lesquelles la section "Related Work" est la plus importante après l’introduction.

Pour commencer, elle est importante pour le débutant qui connaît mal le domaine car elle permet de savoir ce que les autres chercheurs font, et donc d’avoir des pistes de documentation future. En ce sens c’est souvent la partie la plus instructive quand on survole un article sur lequel on n’a pas le temps ou les moyens de se pencher sérieusement. En plus, le fait de lire une présentation des idées de l’article en différentiel par rapport à l’existant permet souvent de mieux comprendre le contexte de la recherche, et même parfois les idées principales de l’article (mieux qu’un développement technique dans le corps de l’article).

Elle est aussi très importante si on essaie d’évaluer la qualité de l’article. En recherche, il est facile de réinventer l’existant sans forcément s’en rendre compte; la seule façon de s’en protéger est de bien étudier l’état de l’art (ou de discuter avec des gens qui le connaissent bien), et cette section témoigne de ce travail défensif. Si la section Related Work est faiblarde et manque des pans importants de la recherche liée à l’article (comme dans le cas du présent article), on a tendance à supposer que les auteurs ignorent les recherches non citées, et ça nuit beaucoup à la crédibilité de l’article.

En pratique c’est donc la partie que les gens lisent souvent directement après l’introduction, quand ils survolent un article. Certains auteurs la mettent d’ailleurs directement après l’introduction, plutôt que juste avant la conclusion. Ça a l’inconvénient d’empêcher d’y mentionner des détails techniques présentés dans le corps de l’article, mais ce n’est pas une excellente idée de toute façon.

Re : Resource-safe Systems Programming with Embedded Domain Specific Languages

2011-09-17T22:18:34+02:00

En fait, ce que m’a intéressé le plus dans cet article, c’est la partie qu’ils appellent "well-typed interpreter", je trouve ça assez amusant (notamment quand on ajoute des types linéaires) de définir un type avec les règles de typage du langage intégrées. En plus, ça faisait une application très "real-world" de types dépendants un peu compliqués, et donc j’ai envoyé cet article.

Sinon, pourrais-tu expliquer un peu plus ton avis la section "Related work" ? Je suis loin d’être un grand lecteur d’articles, alors je ne comprends sûrement pas son importance.

Re : Resource-safe Systems Programming with Embedded Domain Specific Languages

2011-09-17T16:56:38+02:00

Je serais intéressé par un peu plus de contexte : pourquoi soumettre ce papier, quel est l’aspect qui était intéressant ?

J’ai été personnellement assez déçu par cet article. Il se décompense en deux parties:

une présentation d’une forme limitée de sucre syntaxique pour écrire des programmes dans des DSL en utilisant la syntaxe du langage hôte; leur méthode supporte un petit nombre de syntaxes codées en dur : lambda-terms, let-binding, idiomes/applicatives, do-notation, et gestion d’indice de De Bruijn pour les variables.
la présentation de quelques DSL utilisant cette syntaxe pour faire du "deep embedding" (coder à la main un AST pour les termes du DSL et un système de tyapge) pas trop douloureux. Les DSL démontrés embarquent des règles de typage pour la gestion des ressources où certaines actions modifient le contexte de typage (le type d’un file handler passe de File à Unit quand on le ferme), style "type state" et autres.

Je trouve que la partie "sucre syntaxique" n’est pas intéressante. Elle est très ad-hoc et limitée. Je préfère les approches par quotation (comme dans Camlp4) ou, plus fin (et plus restreint, mais moins qu’ici) l’approche des mixfix et des "syntax declaration" de Agda. Leur construction n’est pas novatrice; elle est peut-être plus proche des "computation expressions" de F#, mais bref il y a déjà eu des choses dans ce domaine qui sont équivalentes ou préférables à celle-ci – qui ne sont pas discutées ou même mentionnées dans cet article.

La partie sur les DSL est aussi un peu ad-hoc mais sans doute plus intéressante; ils utilisent les facilités de "calcul au niveau des types" de leur type dépendant pour implémenter (au niveau des types) un système de typage pour les DSL, qui fait des choses un peu plus fines que les systèmes habituels. Bref, ils font le choix du "deep embedding" plutôt que le "shallow embedding" (traduire les constructions dans le système hôte directement), plus coûteux en effort d’implémentation mais demandant moins du système hôte. Il pourrait être intéressant de voir si on peut pousser cette approche en proposant des bibliothèques réutilisables de systèmes de types préparés pour un deep embedding (tu veux embarquer un langage avec types linéaires ? ajoute cette bibliothèque et hop).

J’ai été très déçu par la section "Related Work" de l’article (c’est la section la plus importante après l’introduction). Elle est beaucoup trop courte, pas assez développée, parle beaucoup des travaux précédents des auteurs et pas assez du reste. Surtout, il concerne uniquement la question des DSL, et non le sucre syntaxique; il n’y a rien strictement rien à ce sujet, et ça pose la question de si la présentation détaillée de ces points de syntaxe a sa place dans l’article.

Si j’étais relecteur pour une conférence et qu’on me demandait mon avis sur l’article, je proposerais sans doute de le refuser.

Re : Computational Geometry

2011-09-14T09:48:33+02:00

(Je me demande si la description que j’ai faite dans "abstract ou résumé" n’aurait pas plutôt être en commentaire.)

Re : How efficient is speech?

2011-08-31T13:48:17+02:00

Ce papier exprime une théorie selon laquelle la quantité d’information (entropie) par seconde est maintenue constante "naturellement" lorsque quelqu’un parle. En effet, plus d’effort (et donc plus de temps) sera porté sur les mots qui ont le plus d’importance pour la phrase. Suivant le contexte, le même mot pourra être exprimé plus ou moins vite, par exemple.

C’est une théorie qui aurait été évoquée de manière indépendante par différents chercheurs, cet article est seulement le plus récent. Le plus vieux pourrait bien être « Explaining phonetic variation: A sketch of the H&H theory » par Lindblom.

Je n’ai pas lu l’article.

Re : Relaxing the Value Restriction

2011-08-31T08:58:10+02:00

Article mentionné dans une discussion de forum suite à une question d’un débutant OCaml.

Re : Yield : Mainstream Delimited Continuations

2011-08-26T10:25:35+02:00

Visiblement ils comparent principalement les yields de C#, JavaScript, Ruby, Python et F#. Si vous programmez dans un de cas langages ça doit pouvoir vous intéresser. :)

Re : Do we Need Dependent Types?

2011-06-27T18:29:02+02:00

Je ne sais pas si c’était ironique, mais le tampon BRICS est accolé à beaucoup d’excellents articles, et je pense que "Basic Research" est plutôt à comprendre au sens "recherche fondamentale"

Re : Do we Need Dependent Types?

2011-06-21T11:27:48+02:00

Ça doit être pour ça que ça a été publié dans « Basic Research in Computer Science »

Re : Depixelizing Pixel Art

2011-06-21T14:51:20+02:00

Voir la page des comparaisons pour examiner les résultats plus en détail. J’aime bien le « Cursor 1 ».

Re : Do we Need Dependent Types?

2011-06-14T17:11:38+02:00

J’ai été déçu par cet article. Le titre est très sensationnaliste, mais en réalité l’article n’est effectivement qu’une application de plus du style proposé par Danvy, que certains des lecteurs d’Alexandria connaissent bien puisqu’il ressemble aux techniques pour écrire un "stack-based language" en style naturel dans un langage fonctionnel.

Donc bref, sans vouloir être désagréable, et sans vouloir non plus trop m’avancer parce que je n’ai pas lu l’article en entier, je l’ai seulement survolé, ce n’est pas la révolution. Par ailleurs l’article est "un résumé" d’un article JFP de 2001, évidemment comme ce "résumé" a inondé le web je n’ai pas pu mettre la main sur l’article journal original qui est certainement plus intéressant. En particulier il n’y a pas de section "Related Works", et ça manque cruellement ici (c’est souvent la partie qui aide le plus à comprendre l’intérêt d’un article).

Pour des "vrais faux types dépendants", on peut aussi consulter le travail d’Oleg sur les "Lightweight static capabilities" ou, plus théorique, le langage "Omega" de Tim Sheard (qui utilise des type-level datatypes et des types singletons pour faire une partie de ce qu’on peut faire avec des types dépendants, en préservant la distinction de phase). Enfin, si on veut jouer avec des types dépendants pour de vrai, une option pas trop invasive est le Strathclyde Haskell Enhancement de Conor McBride.

Re : A Tail-Recursive Machine with Stack Inspection

2011-06-06T15:01:23+02:00

J’ai trouvé le concept de "Stack inspection" très intéressant, merci ! C’est amusant que les gens aillent aussi bas-niveau mais j’imagine que c’est parce qu’on peut pas raisonner plus haut avec la JVM et le CLR.

Je ne sais pas comment la primitive test est implémentée avec l’optimisation activée. Je pensais que c’était simple mais un parcours rapide du papier semble dire que ce n’est pas juste "on garde les privilèges les moins élevés des appels antérieurs comme ça on a effectivement du O(1) mémoire gratuitement".

Sinon, est-ce que des gens ont déjà essayé de coupler la stack inspection avec des privilèges plus fins (genre des capabilities) ?

Enfin, ça fait visiblement partie des prétextes évoqués pour la non-implémentation de l’optimisation des appels terminaux dans Java. J’ai l’impression que c’est devenu maintenant culturel : comme dans Python, les stack traces sont omniprésentes en Java, et j’ai vraiment le sentiment que les gens ont pas envie d’enlever la garantie qu’on pourra toujours voir la pile en entier. Ce qui voudrait dire qu’on aura jamais de TCO dans Java, et que la récursivité ne sera donc jamais idiomatique.

Re : Speciﬁcation and Veriﬁcation: The Spec# Experience

2011-06-03T12:04:19+02:00

Un autre article lié, dans le monde Java, et marrant à lire : Secret Ninja Formal Methods (PDF, 15 pages), Joseph Kiniry et Daniel Zimmerman, 2008.

Our goal is not only for our students to use formal methods in their software design and implementation process, but also for them to enjoy doing so. To accomplish this lofty goal, we employ shinobi-iri (stealth and entering methods) — we sneak up on our blissfully unaware students, slip a dose of formal methods into their coursework and development environments, then with a thunderclap disappear in a puff of smoke.

Re : Speciﬁcation and Veriﬁcation: The Spec# Experience

2011-06-03T11:42:29+02:00

Un pas important vers la popularisation des techniques intra-language de vérification, au delà des systèmes de types.

Il y a un paragraphe de l’article qui est trop amusant à lire pour que je me retienne de le citer en entier :

Third, a conclusion we have drawn from our interaction with developers is that real developers do appreciate contracts — contracts are not just an esoteric feature prescribed by “Dijkstra clones”. Unfortunately, we have also seen an unreasonable seduction with static checking. When programmers see our demos, they often develop a romantic enthusiasm that does not correspond to verification reality. Postinstallation depression can then set in as they encounter difficulties while trying to verify their own programs.

Re : Part-of-Speech Tagging From 97% to 100%: Is It Time for Some Linguistics?

2011-06-03T09:48:31+02:00

Merci pour les précisions.

Re : A Tail-Recursive Machine with Stack Inspection

2011-06-02T22:04:04+02:00

Une petite anecdote. John Clements est l’auteur de DrScheme, un environnement de programmation pour Scheme destiné aux débutants. Matthias Felleisen est le guru Racket. À l’époque ils travaillent sur une espèce de débuggueur permettant de visualiser les étapes de réduction d’un programme dans le langage source; ils s’étaient donc confrontés au problème de trouver une sémantique par réduction qui préserve des informations de contexte sur les fonctions appelantes (pour aider l’utilisateur à comprendre ce qui se passe), sans sacrifier les appels terminaux, qui sont au cœur des constructions de boucles de Scheme. Ils sont allés à une conférence d’info, et ont vu une présentation de Cédric Fournet et Andrew Gordon, deux chercheurs de MS qui travaillaient sur une formalisation de la sécurité par inspection de pile, et qui expliquaient que leur modèle empêchait la tail-récursion. Ça a fait tilt, et Clements et Felleisen ont écrit cet article. On peut donc dire que DrScheme a directement¹ contribué à la recherche en sécurité.

¹: directement, ou pas, puisque Java n’intègre toujours pas l’optimisation des appels terminaux aujourd’hui.

Par ailleurs John Clements a continué à travailler dans l’"éducatif". Je sais que ça intéresse certaines personnes ici, mais je n’ai pas lu sa bibliographique plus récente. Quelques titres:

Improving Engineering Education through Creativity, Collaboration, and Context In a First Year Course
Implications of Integrating Test-Driven Development into CS1/CS2 Curricula

Re : Part-of-Speech Tagging From 97% to 100%: Is It Time for Some Linguistics?

2011-05-30T10:14:43+02:00

Merci pour ton commentaire. J’essaie de répondre de manière complète, mais c’est pas grave si tu lis pas tout, toussa.

J’ai lu l’article, mais ça m’a un peu donné l’impression d’une recherche orientée par une méthode donnée de mesure des résultats, et pas l’inverse.

Oui c’est totalement ça. Tu n’es pas le seul à faire ce reproche mais je pense que c’est un autre débat, cf. Neats vs Scruffies sur Buzzerl et l'article récent de Peter Norvig sur le sujet (très long, mais tu peux te contenter du début).

Ensuite, concernant les règles d’apprentissage, tu noteras aussi qu’il ne corrige pas les règles d’apprentissage, mais celles de son corpus ! Un mauvais corpus implique qu’il va apprendre de mauvaises choses, et donc se tromper davantage. On considère de manière générale que le corpus ne se trompe pas (les gens utilisent "gold standard" dans la littérature pour dire ça) donc les méthodes d’apprentissage utilisées sont potentiellement sensibles au bruit.

Enfin, Les gens sont passés à autre chose que le PoS tagging, surtout en anglais/français qui sont des langues faciles à gérer de ce point de vue là (la "sélection du tag le plus fréquent donne déjà des résultats pas si horribles). En arabe (qui est une langue pathologique où le PoS tagging a beaucoup d’ambiguïtés à résoudre), on voit émerger MADA, le "Stanford PoS tagger de l'arabe" qui permet depuis peu aux gens de passer à autre chose.

Le retard de l’arabe sur l’anglais a été conditionné d’une part par le retard de l’apparition du « Penn Arabic Treebank »¹, un corpus annoté qui a enfin permis aux gens de diposer de suffisamment de données afin de comparer leur résultats, et de la difficulté de l’analyse moprphologique de l’arabe (que je peux détailler si quelqu’un est intéressé). Tout comme le tagger de Stanford, c’est un programme assez sophistiqué, non pas du point de vue de la méthode d’apprentissage, mais du point de vue des « features » utilisée et des nombreux ajustements nécessaires.

La recherche actuelle² se concentre davantage sur la morphologie et les aspects syntaxiques du PoS tagging. On ne veut plus savoir si c’est un adjectif, mais si c’est un adjectif épithète antéposé, par exemple. Mais ouais, la plupart des gens font des choses plus appliquées. Pour ma part, ce n’est pas vraiment de la recherche, j’essaie d’améliorer le PoS tagger interne qui fait partie des "low hanging fruits" de la chaîne linguistique du labo. La difficulté vient du fait qu’il faut gérer sept langues différentes, j’essaie de faire des compromis satisfaisants. :)

¹ qui est utilisable depuis 2005, alors que je vois au moins 1992 pour le Penn Treebank anglais.

² LREC est une conférence facile d’accès qui donne une bonne vue d’ensemble de ce que font les gens.

Re : Foundations of Algebraic Specification and Formal Software Development

2011-05-29T22:48:33+02:00

Les mauvaises langues diront probablement que c’est le livre qui clôt le développement de la théorie des institutions.

OBTW, ayez le courage de faire vos résumés à la main.

Re : Part-of-Speech Tagging From 97% to 100%: Is It Time for Some Linguistics?

2011-05-28T09:47:44+02:00

J’ai lu l’article, mais ça ma un peu donné l’impression d’une recherche orientée par une méthode donnée de mesure des résultats, et pas l’inverse. En gros le type dit qu’on peut gagner quelques pourcents en supprimant de petites erreurs dans les règles d’apprentissages, c’est bien mais ça ne nous dit pas comment répondre à des questions importantes indépendamment de ces règles. Peut-être qu’il est temps de s’intéresser à d’autres domaines que le PoS tagging, ou d’apprendre à utiliser cette information de façon résistante aux erreurs.

Re : Thorn: Robust, Concurrent, Extensible Scripting on the JVM

2011-05-27T09:59:04+02:00

Ça pue, c’est pas libre.

Re : Kleisli Arrows of Outrageous Fortune

2011-05-16T21:23:46+02:00

Je ne sais pas si on peut déjà le poster (il n’a pas l’air d’être officiellement publié), mais il est amusant, intéressant et plein de jeux de mots et de références. Le papier est plutôt basé sur Winging It (mais pas complètement), mais je pense qu’on peut le lire sans avoir lu Slicing It, je dirais, et montre comment on peut utiliser des monades indexées un peu spéciales pour empêcher le méchant vrai monde de rendre les programmes inutiles, en mettant dans les types des information sur le monde. En fait l’idée c’est que ses monades permettent de dire « si au début P, alors Q après », donc il paraît que ça fait penser à la logique de Hoare et tout. L’exemple est utile : il s’agit d’une monade dans laquelle on peut ouvrir des fichiers, et qui empêche le programme de faire des opérations (par exemple lire le fichier) sans être sûr qu’il est disponible (qu’il existe et qu’il est ouvert)

Re : Part-of-Speech Tagging From 97% to 100%: Is It Time for Some Linguistics?

2011-05-11T22:55:51+02:00

Le PoS tagging a pour but de choisir, pour chaque mot, une étiquette grammaticale (nom, adverbe, adjectif, etc.) pour réduire les ambiguïtés et permettre à d’autres traitements sur le texte d’aller plus loin dans l’analyse.

Ça fait des années que cette tâche résiste aux chercheurs qui n’arrivent pas à dépasser les 97%. Ce papier présente l’intérêt de présenter de manière claire et simple une partie des challenges qui se posent encore aux linguistes informaticiens, c’est donc un bon investissement pour les curieux !