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 OAA15696; Mon, 2 Feb 2004 14:36:29 +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 OAA16454 for ; Mon, 2 Feb 2004 14:36:28 +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 i12DaRP26683 for ; Mon, 2 Feb 2004 14:36:27 +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 i12DaHaW041315 ; Mon, 2 Feb 2004 14:36:17 +0100 (CET) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.12.3/jb-1.1) id i12DaGm0008995 ; Mon, 2 Feb 2004 14:36:16 +0100 (MET) X-Authentication-Warning: clipper.ens.fr: frisch owned process doing -bs Date: Mon, 2 Feb 2004 14:36:16 +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: <1075725268.29371.16.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 confuses:01 quercia:01 numerix:01 nat:01 hashing:01 generic:01 non-custom:01 boxing:01 implemented:01 alain:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2 Feb 2004, Yaron M. Minsky wrote: > This confuses me, because as I mentioned, michel quercia appears to have > fixed this problem while working on Numerix. Here's his patch: The patch solves the problem for the nat type, not for big_int. If you know the ordering won't be the natural one for big_int, it is ok, but this might be confusing, and for this reason Xavier Leroy rejected a similar patch I proposed. If you read french: http://caml.inria.fr/bin/caml-bugs/wish%20not%20granted?id=1445 Note the problem is only for comparison, not for hashing. > > 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. > > Is that what Michel did? No. -- 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