ERic (Entity-Relationship interactive calculator) est un jeune logiciel libre, en ligne de commande, sous licence EUPL-1.1.
ERic permet d’éditer et de sauvegarder des ontologies et des bases de connaissance sous forme de graphes entités/relations. Ensuite, grâce à son algorithme de subsomption, ERic est capable d’interroger sa base de connaissance de façon remarquablement flexible.

ERic v0.2c ajoute le support des nombres réels flottants et des unités SI du système international de mesure.

• Le forum d’ERic hébergé par developpez.net
• Le dépôt SVN d’ERic

Pour ceux qui aiment la théorie des catégories et les preuves diagrammatiques Paul-André Melliès présente une (nouvelle?) approche graphique à la croisée du calcul des séquents et de la théorie des noeuds.

Cliquez sur l’image pour télécharger les slides pdf.

Ce billet annonce la disponibilité immédiate d’ERic v0.2a

ERic (Entity-Relationship interactive calculator) est un jeune logiciel libre, en ligne de commande, sous licence EUPL-1.1.
ERic permet d’éditer et de sauvegarder des ontologies et des bases de connaissance sous forme de graphes entités/relations. Ensuite, grâce à son algorithme de subsomption, ERic est capable d’interroger sa base de connaissance de façon remarquablement flexible.

• Le forum hébergé par developpez.net
• Le dépôt SVN

Le système d’exploitation MorphOS, un OS léger et convivial descendant de feu AmigaOS est enfin disponible en version 2.5 sur matériel Apple, eMac, Mac mini G4, en plus des plateformes déjà supportées (Pegasos 1 & 2 et EFIKA).

La procédure d’enregistrement de MorphOS 2.5 est intégrée à la version de démonstration et consiste à :

• installer la version de démonstration librement téléchargeable
• utiliser l’outil RegTool pour s’enregistrer
• le paiement s’effectue à l’aide de PayPal

Les conditions d’utilisation assez restrictives (la licence est liée au matériel) sont destinées à limiter le piratage. Espérons que cela n’empêchera pas les passionnés d’informatique alternative de découvrir ce système plein d’atouts pour ne pas dire culte puisqu’il a le don de déclencher un attachement que certains qualifient d’irrationnel.

L’installation par défaut écrase toutes les données du disque, pour installer MorphOS 2.5 en multi-boot sur Mac Mini reportez vous à ces instructions.

Renseignez-vous sur MorphOS et l’Amiga :

• visitez le site d’un utilisateur satisfait par MorphOS
• visitez un site de fans de cette machine mythique qu’est l’Amiga
• adhérez au groupe DVP des utilisateurs d’Amiga et compatibles
• apprenez la fabuleuse histoire de l’Amiga, découvrez des personnages hauts en couleur comme Jay Miner, son chien Mitchy, et revivez la passion de l’informatique comme elle ne sera plus jamais

Si vous ne l’avez pas déjà fait dépêchez-vous de visionner ou de télécharger
la vidéo conférence de Heinrich Apfelmus sur les GADTs (Generalized Algebraic Data Types).

Un exercice simple pour débutant en ocaml c’est d’écrire un interpréteur pour un petit langage simple comme par exemple une calculatrice :

type arithmetic =
   | Cst of int
   | Neg of arithmetic
   | Add of binary
   | Sub of binary
   | Mul of binary
   | Div of binary
and binary =
   arithmetic * arithmetic

Mais cet exercice anodin change complètement de nature quand on passe à un langage fortement normalisant, dans ce cas vous devez aussi prouver que le programme se termine toujours et sans accident, quelles que soient les circonstances.

Cette preuve ce fait en deux étapes :

• d’abord il changer d’algèbre initiale
• ensuite il faut établir une égalité entre les deux types algébriques

Le changement d’algèbre initiale se fait en paraphrasant la déclaration du type, en remplaçant chaque occurrence de arithmetic par une occurrence de fold f :

let rec fold f = function
   | Cst n -> f#cst n 
   | Neg a -> f#neg (fold f a)
   | Add (a,b) -> f#add (fold f a) (fold f b)
   | Sub (a,b) -> f#sub (fold f a) (fold f b)
   | Mul (a,b) -> f#mul (fold f a) (fold f b)
   | Div (a,b) -> f#div (fold f a) (fold f b)

Le paramètre f est une égalité entre les deux types algébriques :

let id x = x   
   
let eval =
   fold (
      object
         method cst = id
         method neg = (~-)
         method add = ( + )
         method sub = ( - ) 
         method mul = ( * ) 
         method div = ( / )
      end )

À cette étape on est à l’abri des boucles infinies.
Mais on n’est pas à l’abri des interruptions intempestives, par exemple lors d’une division par zéro.

# eval (Div(Cst 1,Cst 0));;
Exception: Division_by_zero.

Dans les langages fortements normalisants les exceptions n’existent pas.
Pour simuler les exceptions on utilise la monade result pour propager le diagnostic d’erreur.

type ('a,'b) result =
   | Ok of 'a
   | Error of 'b 

let ok1 f v =
   match v with
   | Ok x -> Ok (f x)
   | Error _ -> v

let ok2 f v1 v2 =
   match v1,v2 with
   | Ok x1,Ok x2 -> Ok (f x1 x2) 
   | Error _, _ -> v1
   | _, Error _ -> v2

let result2 f v1 v2 =
   match v1,v2 with
   | Ok x1,Ok x2 -> f x1 x2 
   | Error _, _ -> v1
   | _, Error _ -> v2
   
let safe_division a b =  
   if b=0 then Error "Division_by_zero"
   else Ok (a/b)  

À l’aide de cette monade result on peut définir une nouvelle égalité qui prend en compte les possibilités d’erreur :

let ok n = Ok n   
      
let eval =
   fold (
      object
         method cst = ok
         method neg = ok1 (~-)
         method add = ok2 ( + )
         method sub = ok2 ( - ) 
         method mul = ok2 ( * ) 
         method div = result2 safe_division
      end )

Cette fois le programme suit son cours jusqu’au bout, sans interruption :

# eval (Div(Cst 1,Cst 0));;
- : (int, string) result = Error "Division_by_zero"      

Bien sûr un tel raffinement de style n’est pas forcément utile ou même désirable dans chaque code ocaml. Le langage étant multi-paradigmes par nature il vous invite à trouver le style qui vous convient le mieux.

Cependant, avec cette introduction courte et informelle sur les récurseurs et les monades, j’espère avoir donné quelques encouragements à ceux qui voudraient faire le grand saut vers un assistant de preuve.

– damien

Un MIME (Multipurpose Internet Mail Extension) est une information système pour identifier les types de fichier et leur affecter certains attributs comme une commande par défaut ou une icône personnalisée.

Dans ce billet je vais encore plus loin en vous proposant directement un panel d’icônes taillées sur mesure pour le gestionnaire de fichiers ROX-Filer.

Bien sûr si vous semblez frappé d’injustice du fait que votre langage de programmation favori ne soit pas représenté, vous pouvez me faire une proposition que j’ajouterai pour élargir la gamme de fichiers sources personnalisables.

Ce n’est pas la première fois que je vous parle de jeu-vidéo et de programmation fonctionnelle.
Cette fois il s’agit de Raincat, un jeu SDL écrit en Haskell, pour Windows et Linux.

Le jeu consiste à déposer les accessoires (dans la colonne à droite) sur le parcours du chaton afin que celui-ci atteigne la sortie du niveau malgré la pluie et diverses projections d’eau. Car le Raincat est réellement hydrophobe, la moindre goutte sur son pelage délicat et vous devrez recommencer le niveau.

À vrai dire ce petit puzzle ne m’a pas rendu accro. Maintenir un chaton propre et toujours au sec m’apparaît difficilement comme un enjeu ludique motivant.

Ce qui est peut être plus intéressant que le jeu en lui-même c’est le témoignage que le fossé qui séparaient les langages académiques des applications quotidiennes se comble de jours en jours.

Sylvain Le Gall et l’équipe organisatrice de la 3ième rencontre des programmeurs Objective-Caml vous donnent rendez-vous le 16 Avril à Paris.

Malheureusement je ne pourrai pas être présent cette année.

Hello,

For the third time, I am proud to invite all OCaml enthusiasts to join
us at OCaml Meeting 2010 in Paris.

This year event takes place in Paris on Friday 16th April 2010.
Subscription is opened and will be closed on Friday 2nd April 2010.

Presentations include:

• Enforcing Type-Safe Linking using Inter-Package Relationships for
  OCaml Debian packages
• The Ocamlviz visualization toolkit
• Cluster computing in Ocaml
• Ocaml in a web startup
• React, functional reactive programming for OCaml
• OASIS, a Cabal like system for OCaml
• OPA, same web, but with types and lambda
• OC4MC, Objective Caml for MultiCore
• Lwt, Cooperative Light-Weight Threads
• naclgrid: the collaborative rendering farm, a JoCaml-powered
  desktop grid

The meeting is sponsored by INRIA, the Caml Consortium and OCamlCore.
Inscription is free but the number of participants is limited.

Further information and inscriptions:

http://wiki.cocan.org/events/europe/ocamlmeetingparis2010

The day after OCaml Meeting, Mehdi Dogguy from PPS helps me to organize
an informal day where OCaml teams can meet to work. We will have 2
classrooms, each can host 45 persons. There will be an internet access
and a blackboard in each room. Inscription is free.

Further information and inscriptions:

http://wiki.cocan.org/events/europe/ocamlhackingday2010

Hope to see a lot of you,

Regards,

Sylvain Le Gall on behalf of the OCaml Meeting organization team.

Le tas binaire est un tableau qui implémente un arbre pseudo-complet vérifiant la propriété de tas.
Un tableau est de taille fixe. Par conséquent un tas binaire est borné, on ne peut y insérer qu’un nombre fixe et limité d’éléments. Bien sûr on pourrait redimensionner le tableau dynamiquement, mais cela a un impact négatif sur le coût des opérations.
Qu’on prêche le style impératif ou le style fonctionnel est étrangé à l’affaire.
La bonne question c’est de savoir si on connait d’avance le nombre d’éléments à insérer ou non.

Si on le connait alors un tas binaire fera très bien l’affaire.
Si on ne le connait pas, alors autant opter tout de suite pour un arbre binaire, même si on veut garder un style impératif.
Ça serait exactement la même problématique avec un dictionnaire. On peut faire une recherche dichotomique dans un tableau trié. Ou alors on peut faire une recherche dans un arbre ordonnée.
Dans les deux cas l’algorithme de recherche est le même, il s’agit dune boucle qui à chaque étape découpe l’espace de recherche en deux moitiés dont une seule peut contenir l’élément recherché.
Le paradigme a bien un impact sur le programmeur mais c’est parce que le programmeur est trop attaché à la syntaxe.
En réalité le paradigme impacte plus fortement la façon de faire que la façon de penser.
L’expérience aussi est un facteur qui impacte la façon de faire.
C’est pourquoi je préfère parler de style plutôt que de paradigme.

Le tas de Braun

Un petit rappel de quelques définitions :

• propriété de tas
• arbre complet
• arbre de Braun

On l’appelle tas de Braun parce que l’insertion répétée dans l’arbre vide produit un arbre de Braun.
Un autre nom est heap-ordered binary tree mais c’est moins spécifique.

type 'a heap = 

  | E (* 'a empty heap *) 

  | N of 'a non_empty_heap 

and 'a non_empty_heap = 

  {mutable l: 'a heap; mutable e: 'a; mutable r: 'a heap}

Remarques :

• on a un type tas non-vide, il n’y aura pas d’exceptions dans le code, la contrainte sur l’argument des fonctions find_max et remove_max sera exprimée par le type, la contrainte sur le résultat de insert également
• les champs sont mutables, c’est parce qu’on va utiliser le même type pour les deux styles de programmation, les algorithmes seront les mêmes, mais dans un cas on fera de la copie, dans l’autre on fera de la modification sur place

La fonction find_max est triviale :

Le style fonctionnel

On devrait dire le style immutable.
Je commence toujours par le style immutable parce que c’est plus lisible.
J’ai choisi un tas-max plutôt qu’un tas-min, pour un tas-min il n’y aura qu’à changer le signe où inverser le signe de la fonction compare.

let rec add x = function 

  | E -> 

      {l=E;e=x;r=E} 

  | N n ->  

      if compare n.e x > 0 then {l=N (add x n.r);e=n.e;r=n.l}  

      else {l=N (add n.e n.r);e=x;r=n.l} 

                    

let rec remove_max = function 

  | {l=E;r=t} | {r=E;l=t} -> 

      t 

  | {l=N l;e=e;r=N r} -> 

      if compare l.e r.e > 0 then N {l=remove_max l;e=l.e;r=N r} 

      else N {l=N l;e=r.e;r=remove_max r}

Le style impératif

On devrait dire le style mutable.
Je traduis à partir de la version en style immutable.

let rec insert x = function 

  | E -> 

      {l=E;e=x;r=E} 

  | N n -> 

      let nr = n.r in 

      n.r <- n.l; 

      if compare n.e x > 0 then n.l <- N (insert x nr) 

      else (n.l <- N (insert n.e nr); n.e <- x); 

      n 

                    

let rec delete_max h = 

  match h with  

  | {l=E;r=t} | {r=E;l=t} -> 

      t 

  | {l=N l;e=e;r=N r} -> 

      if compare l.e r.e > 0 then (h.e <- l.e; h.l <- delete_max l)  

      else (h.e <- r.e; h.r <- delete_max r); 

      N h

Autres opérations

Il faut mentionner qu’un tas de Braun offre des tas de possibilités de variantes et d’extensions qui seraient bien plus difficiles à implanter à l’aide d’un tas binaire.
Je ne vais pas être exhaustif sur ce point, je vais cependant en citer deux.
Il est également possible de supprimer un élément arbitraire dans un tas en le faissant percoler jusqu’à la racine puis en invoquant remove_max.

La fusion

Il est possible de fusionner deux tas de Braun en un seul tas.

let rec join ha hb = 

  match ha,hb with 

  | t,E | E,t -> 

      t 

  | N a,N b -> 

      if compare a.e b.e > 0 then N {l=join a.l a.r;e=a.e;r=hb} 

      else N {l=ha;e=b.e;r=join b.l b.r}

On peut accélérer l’opération de fusion à l’aide d’une technique dite de « structural bootstrapping ».
Grâce à cette technique il est possible de fusionner deux tas simplement en insérant l’un dans l’autre.

L’arbre tournoi

On peut modifier légèrement les opérations d’insertion et de suppression pour que le tas restitue l’ordre d’insertion quand on le parcourre dans l’ordre infixe.
Toutefois cette modification a un impact sur la performance, le tas n’est plus pseudo-complet comme un arbre de Braun.

Typiquement on insère les scores dans l’arbre tournoi, le gagnant est toujours à la racine.
Le parcourt infixe restitue la liste des scores dans l’ordre d’apparition des joueurs.

let rec add x = function 

  | E -> 

      {l=E;e=x;r=E} 

  | N n ->  

      if compare n.e x > 0 then {n with r=N (add x n.r)}  

      else {l=N n;e=x;r=E} 

                    

let rec remove_max = function 

  | {l=E;r=t} | {r=E;l=t} -> 

      t 

  | {l=N l;e=e;r=N r} as t -> 

      if compare l.e r.e > 0 then 

        N{l=l.l;e=l.e;r=remove_max {t with l=l.r}} 

      else 

        N{l=remove_max {t with r=r.l};e=r.e;r=r.r}

Conclusion

La chose à retenir c’est que ce n’est pas le fonctionnel qui force à changer de structure de données.
Ce qui force à changer de structure de données c’est le fait qu’un tableau n’est pas toujours la meilleure option. Utiliser une liste ou un arbre au lieu d’un tableau n’interdit pas le style mutable.
Il n’y a pas un paradigme impératif qui s’oppose à un paradigme impératif fonctionnel, il y a juste le style mutable et le style immutable qui sont deux façons d’implanter un même algorithme pour une même structure de données.
On peut d’ailleurs très bien adopter le style immutable avec un langage à objets si le ramasse-miettes est suffisamment efficace pour ça.