I'm happy to announce that my contribution to TUG 2011, the next TeX
Users Group International conference, has been accepted. Please find the
title and abstract below.
LaTeX Coding Standards
Because LaTeX (and ultimately TeX) is only a macro-expansion system, the
language does not impose any kind of good software engineering practice,
program structure or coding style whatsoever. As a consequence, writing
beautiful code (for some definition of "beautiful") requires a lot of
self-discipline from the programmer.
Maybe because in the LaTeX world, collaboration is not so widespread
(most packages are single-authored), the idea of some LaTeX Coding
Standards is not so pressing as with other programming languages. Some
people may, and probably have developed their own programming habits,
but when it comes to the LaTeX world as a whole, the situation is close
to anarchy.
Over the years, the permanent flow of personal development experiences
contributed to shape my own taste in terms of coding style. The issues
involved are numerous and their spectrum is very large: they range from
simple code layout (formatting, indentation, naming schemes etc.),
mid-level concerns such as modularity and encapsulation, to very
high-level concerns like package interaction/conflict management and
even some rules for proper social behavior.
In this talk, I will report on all these experiences and describe what I
think are good (or at least better) programming practices. I believe
that such practices do help in terms of code readability,
maintainability and extensibility, all key factors in software
evolution. They help me, perhaps they will help you too.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
Bonjour,
nous avons le plaisir de vous inviter au séminaire des étudiants du
LRDE. Il aura lieu le mercredi 16 janvier 2013 à partir de 10 heures en
Amphi 3 (KB).
-----------------------------------------------------------------------
Au programme :
SPOT
* 10h00 : Réduction par simulation pour les TGBA -- Thomas Badie
* 10h30 : Méthodes de réduction par ordre partiel adaptatives -- Pierre
Parutto
VERIFICATION DU LOCUTEUR
* 11h00 : Spherical Discriminant Analysis -- Victor Lenoir
CLIMB
* 11h30 : Parallélisation de Climb -- Laurent Senta
* 12h00 - 14h00 : PAUSE DEJEUNER
VAUCANSON
* 14h00 : FSMXML pour Vaucanson 2.0 -- David Moreira
OLENA
* 14h30 : Calcul du flux optique dans des séquences avec des parties
manquantes -- Sylvain Lobry
* 15h00 : Inpainting rapide préservant la structure -- Coddy Levi
Les Résumés des exposés :
**************************
SPOT
* 10h00 : Réduction par simulation pour les TGBA -- Thomas Badie
L'approche par automates du model checking s'appuie traditionnellement
sur des Automates de Büchi (BA) qu'on souhaite les plus petits
possible. Spot, bibliothèque de model checking, utilise principalement
des TGBA qui généralisent les BA. Nous avons déjà présenté une méthode
de réduction par simulation (dite directe). Cette technique a permis
de produire des automates plus petits que dans les précédentes
versions.
La simulation consiste à fusionner les états ayant le même suffixe
infini. Nous montrons que nous pouvons aussi fusionner ceux ayant le
même préfixe infini (c'est la cosimulation). On peut répéter la
simulation et la cosimulation pour créer la simulation itérée. Cette
méthode est incluse dans Spot 1.0 et est une grande amélioration de la
simulation.
On expérimente aussi une méthode qui consiste à modifier certaines
conditions d'acceptations (appellées sans importances). Puisque celles
qui sont sur les transitions entre composantes fortement
connexes n'ont pas d'influence sur le langage, on peut les modifier
pour aider la simulation.
* 10h30 : Méthodes de réduction par ordre partiel adaptatives -- Pierre
Parutto
Le model checking explicite de systèmes concurrents souffre d'une
croissance exponentielle du nombre d'états représentant un
système. Les méthodes de réduction par ordre partiel sont un
ensemble de méthodes permettant de combattre ce
problème. Celles-ci permettent d'ignorer les états redondants lors
de la génération de l'espace d'états. Parmi elles, nous avons
choisi les algorithmes two phase et ample set comme base pour nos
investigations. Ceux-ci ont été implémentés dans Spot, la
bibliothèque C++ de model checking développée au
LRDE, en utilisant l'interface DiVine. En se basant sur ces
méthodes et sur le fait que les algorithmes dans Spot sont
calculés à la volée, nous avons défini une nouvelle classe de
méthodes appelées méthodes de réduction par ordre partiel
adaptatives. L'idée est de se baser sur l'état courant de
l'automate de la formule et non sur la formule tout entière. Les
résultats obtenus sur notre suite de tests montrent que cette
méthode donne de meilleurs résultats que les méthodes d'ordre
partiel classiques.
VERIFICATION DU LOCUTEUR
* 11h00 : Spherical Discriminant Analysis -- Victor Lenoir
Le rôle de la vérification de locuteur est de vérifier
l’identité présumée d’un segment de
parole. Actuellement, les meilleures performances sont
obtenues par un mapping de chaque segment de parole d’un
locuteur vers un vecteur appelé I-vector. Le score de la
vérification de locuteur est calculé par une distance
cosine entre ces deux vecteurs représentant chacun un
locuteur. Ce rapport décrit une technique de réduction
de dimension appelée Spherical Discriminant Analysis
(SDA). Les objectifs de cette projection sont de maximiser
la distance cosinus entre deux locuteurs différents et de
minimiser la distance cosinus entre deux même locuteurs; il
a été montré que le sous-espace de la SDA, qui est plus
approprié pour la distance cosinus que la Linear
Discriminant Analysis (LDA), obtient de meilleures performances
en reconnaissance faciale. Nous allons comparer les
performances obtenues par la SDA avec celles obtenues par la
LDA.
CLIMB
* 11h30 : Parallélisation de Climb -- Laurent Senta
Climb est une bibliothèque de traitement d’image générique développée
en Common Lisp. Elle fournit une couche de génécité bas-niveau
utiliséee pour définir de nouveaux algorithmes de traitement d’image.
Il est aussi possible de créer des chaînes de traitements soit en
utilisant un "Domain Specific Language" déclaratif ou bien à l’aide
d’une interface graphique. Afin d’améliorer les performances de la
bibliothèque, ces différents niveaux peuvent être parallélisés. Nous
décrirons les différents aspects de ce processus de
parallélisation. Pour chaque niveau, nous détaillons l’implémentation
des traitements parallèles, leurs impacts sur l’utilisabilité de la
bibliothèque ainsi que les gains de performance obtenus.
VAUCANSON
* 14h00 : FSMXML pour Vaucanson 2.0 -- David Moreira
Vaucanson est une bibliothèque de manipulation d'automates et de
transducteurs. La version 2.0 est aujourd'hui en cours de
développement et le design a été revu pour avoir des parties statiques
et dynamiques. Dans Vaucanson 1.4, les entrées/sorties utilisent
intensivement le format XML spécifié par le groupe de Vaucanson,
FSMXML. Mes travaux consistent à développer et rafraîchir des
spécifications du format présent dans Vaucanson 1.4. Cette mise à jour
nous permet la sauvegarde et la lecture d'automates aux Weight Sets
particuliers tels que des expressions rationnelles ou même des
automates pondérés.
OLENA
* 14h30 : Calcul du flux optique dans des séquences avec des parties
manquantes -- Sylvain Lobry
Calculer le flux optique peut être un premier pas vers l'inpainting
vidéo. Pour cette application, nous devons manipuler des séquences
avec des zones manquantes, celles à inpainter. Le flux optique peut
être calculé de manière locale ou globale. Les méthodes globales ont
généralement de meilleurs résultats. Dans le cas de séquences avec
des zones manquantes, les méthodes globales ne peuvent pas être
utilisées de manière directe à cause du manque d'informations dans ces
régions. Nous présentons une méthode combinant des algorithmes locaux
et globaux afin de calculer le flux optique dans ce type de séquences
ce qui nous permet d'inpainter efficacement et simplement des vidéos.
* 15h00 : Inpainting rapide préservant la structure -- Coddy Levi
Le texte sujet à extraction via l'analyse de document peut être
présent dans deux formes : foncé sur fond clair ou clair sur fond
foncé, appelé Inverse Video. Nous présenterons les
problématiques liées à l'extraction de l'inverse video dans
Scribo en utilisant la chaîne de traitement déjà existante, les
problèmes ainsi introduits et les pistes explorées pour
l'amélioration des résultats.
--
Daniela Becker
Responsable administrative du LRDE
Hello, and happy new year to everyone!
I'm pleased to announce that I will be holding a 90 minutes session at
the next ACCU conference in Bristol. The abstract is given below.
The Bright Side of Exceptions
In many programming languages, the term "exception" really means "error". This
is rather unfortunate because an exception is normally just something that
does not happen very often; not necessarily something bad or wrong.
Some ancient languages like C don't support exceptions at all. You need to
indicate them with specific return values from functions. Languages with
explicit support for exceptions (e.g. Java, C++ or Python) provide built-in
facilities for handling them. The most traditional approach to this is the
"try/catch/throw" system, whatever it may actually be called in your favorite
language. As it turns out, this system suffers from limitations which affect
its usability in complex situations. The two major problems are 1. the
obligatory stack unwinding on error recovery and 2. a two-levels only
separation of concerns (throwing / handling).
In this talk, we will demonstrate the benefits of using a system which does
not suffer from these limitations. More precisely:
- the stack is not necessarily unwound on error recovery, which means that the
full execution context at the time the error was signaled is still
available,
- the separation of concerns is 3-fold: the code that signals an error (throw)
is different from the code that handles the error (catch) which itself is
different from the code that chooses how to handle the error (restart).
It turns out that an exception handling mechanism like this is able to handle
more than just errors and in fact, even more than just exceptional events. In
Lisp, this system is called the "condition" system. Conditions are the bright
side of exceptions: not necessarily bad, not even necessarily exceptional.
Conditions become an integral part of your programming paradigms toolkit. We
will provide two examples of "condition-driven development". The first one
will show how to handle actual errors, only in a more expressive and cleaner
fashion than with a regular try/catch/throw system. The second example will
demonstrate the implementation of something completely unrelated to error
handling: a user-level coroutine facility.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
