English version
Accueil propos Tlchargement Ressources Contactez-nous

Ce site est rarement mis jour. Pour les informations les plus rcentes, rendez-vous sur le nouveau site OCaml l'adresse ocaml.org.

Browse thread
Objective Caml release 3.08.2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-11-25 (18:04)
From: Frédéric_Gava <frederic.gava@w...>
Subject: Re: [Caml-list] Objective Caml release 3.08.2
> > Why an order for the fold operator ?
> Because Set.t is an ordered container,
Ok, but it is an abstract type : you do not know (except when you used
ocamlbrowser) how it works
and you do not need it (you do not want to know how really work the Thread
for example (simple user point of view) ).

> and order matters for folds if the operator being folded
> isn't associative.
Ok. That's right. This is why I thinks, another fold is necessary for
associative operators (and thus for possible optimizations of this fold) and
thus wihtout side-effects.

> These functions are deterministic and depend on order:
> Set.min_elt, Set.max_elt, Set.elements, Set.fold, Set.iter

Ok, for Set.iter  but Set.elements could also give the elements of the set
in any order: you need to specify to the SGBD that you want an ordered table
in SQL, why here it is necessary. You can  sort your list if you need
(peraps it takes more time but two functions could be give to the users:
Set.elements and Set.order_elements). A Set.elements without ordering the
elements would be more efficient.

 > Set.choose, however, chooses at random, and Set.for_all
> doesn't appear to be ordered either (is that a bug
> in the doc or deliberate?)
What would be the interest of sorting all the times the elements ?

Frédéric Gava