From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA10155; Mon, 2 Feb 2004 13:24:07 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA10181 for ; Mon, 2 Feb 2004 13:24:05 +0100 (MET) From: Alain.Frisch@ens.fr Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i12CO5P15165 for ; Mon, 2 Feb 2004 13:24:05 +0100 (MET) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.12.10/1.01.28121999) with ESMTP id i12CNvaW004435 ; Mon, 2 Feb 2004 13:23:57 +0100 (CET) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.12.3/jb-1.1) id i12CNtBt025168 ; Mon, 2 Feb 2004 13:23:55 +0100 (MET) X-Authentication-Warning: clipper.ens.fr: frisch owned process doing -bs Date: Mon, 2 Feb 2004 13:23:55 +0100 (MET) X-X-Sender: frisch@clipper.ens.fr Reply-To: Alain.Frisch@ens.fr To: "Yaron M. Minsky" cc: Caml List Subject: Re: [Caml-list] Big_int comparisons In-Reply-To: <1075664556.29371.6.camel@flapdragon.homeip.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; alain:01 frisch:01 caml-list:01 yaron:01 minsky:01 generic:01 nat:01 generic:01 nat:01 non-custom:01 boxing:01 implemented:01 alain:01 caml:01 int:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 1 Feb 2004, Yaron M. Minsky wrote: > Does anyone know why there's no support for Big_int comparisons? Do you mean the generic comparison functions ? The reason is that the type big_int is a Caml record type, and it is not possible to attach custom comparison functions to the values of such types. One could imagine adding a comparison function to the underlying nat objets (which are custom blocks), which would allow using the generic comparison functions on big_int objects. The problem is that even if the order on nat is the natural order on non-negative integers, the induced order on big_int will not be the natural order on integers. Even worse for the num type, which admit several representation for the same numer. This is annoying, because you cannot use the generic comparison functions on large datastructures which contains somewhere deep in the structure some nat, big_int or num. Even if you don't care about the meaning of the ordering (you only need one ordering to implement some kind of set). A solution could be to allow attaching custom generic operations to non-custom blocks (for instance, by boxing values in a block with a special GC tag + the custom operations; i.e.: custom blocks whose content is traced by the GC). This could be implemented with custom blocks by registering/unregistering global roots, but I guess the performance would be bad. Alain ------------------- 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