Re: [Caml-list] égalité physique (==) avec Pervasives.(+)

[Diego Olivier Fernandez Pons <Diego-Olivier.FERNANDEZ-PONS@cicrp.jussieu.fr>]

    Bonjour,

On Tue, 7 Jan 2003, Christophe Raffalli wrote

> Même l'orsqu'il s'agit d'une optimisation, il est important d'être
> sur qu'elle remplit son usage ! (même si le programme marche quel
> que soit le résultat de ==)

C'est une remarque fort juste au demeurant !

Un des problèmes des solveurs de contraintes est la nécessité de
manipulation de fonctions sous deux formes :

- une forme explicite pour la propagation de contraintes

let f = fun x y -> x + y < 10 && 0 < x + y

si vous avez des bornes sur y, vous pouvez en déduire des bornes sur
x, mais pour ce faire il faut pouvoir 'traverser' f

- une forme 'compilée' pour l'énumération exhaustive

si vous avez épuisé toutes l'information dont vous disposiez, il ne
reste pas d'autre solution que d'essayer tous les couples (x, y) avec
un mécanisme de retour en arrière.

La librairie FaCiLe a choisi une forme explicite pour la propagation
(sous forme de syntaxe abstraite que l'on construit lors de la
déclarations de contraintes) et une fonction d'évaluation (donc assez
lente) pour la recherche.

Si je suppose résolue la question de la compilation à la volée
de fonctions (par exemple Dynamic Caml), on peut essayer un compromis
par une double représentation des fonctions

f = (f_abstraite, f_compilée)

Seulement, pour permuter de représentation selon les besoins, je ne
vois pas d'autre solution que :
- hacher la représentation courante (par exemple f_compilée)
- aller chercher la valeur dans une table (clé, g_abstraite,
g_compilée)
- vérifier l'égalité physique g_compilée == f_compilée
- en déduire que g_abstraite est bien une représentation abstraite de
la fonction voulue.

(ou bien une solution plus ou moins équivalente)

Je suis tout à fait d'accord sur le fait que l'égalité physique n'est
pas la panacée, mais je n'ai pas vraiment d'autre solution à proposer.

Et il y a bien sûr toujours le problème des applications partielles,
et je n'ai aucun moyen de prouver la correction du code, et je n'ai
aucune garantie sur la stabilité du code dans les futures versions, et
je ne sais même pas si cette optimisation remplit son usage...

Cela dit, mon courrier précédent n'était qu'une tentative de
résolution partielle du problème.

        Diego Olivier

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners