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 NAA08206; Mon, 2 Feb 2004 13:34:37 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA10758 for ; Mon, 2 Feb 2004 13:34:35 +0100 (MET) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id i12CYYv13073 for ; Mon, 2 Feb 2004 13:34:35 +0100 (MET) Received: from user-0cdfhfr.cable.mindspring.com ([24.215.197.251] helo=[192.168.0.3]) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AndHa-0005cR-00; Mon, 02 Feb 2004 07:34:30 -0500 Subject: Re: [Caml-list] Big_int comparisons From: "Yaron M. Minsky" To: Alain.Frisch@ens.fr Cc: Caml List In-Reply-To: References: Content-Type: text/plain Organization: Cornell University Message-Id: <1075725268.29371.16.camel@flapdragon.homeip.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 02 Feb 2004 07:34:29 -0500 Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 yaron:01 minsky:01 yminsky:01 cornell:01 2004:99 alain:01 frisch:01 yaron:01 minsky:01 generic:01 nat:01 generic:01 nat:01 confuses:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2004-02-02 at 07:23, Alain.Frisch@ens.fr wrote: > 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 confuses me, because as I mentioned, michel quercia appears to have fixed this problem while working on Numerix. Here's his patch: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=fa.j11k5cv.r5cu86%40ifi.uio.no&rnum=1&prev=/groups%3Fq%3Dgroup:fa.caml%2Bauthor:michel%2Bauthor:quercia%2Bcompare%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dfa.j11k5cv.r5cu86%2540ifi.uio.no%26rnum%3D1 Also, what is going on with the Nat type? It seems to be completely undocumented. Is Big_int built on Nat? Are there efficiency reasons to choose one or the other if both will do semantically? > 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). Agreed. Plus, I'm considering porting some code over from using Numerix to using Big_int, and I'm concerned that I maybe introducing runtime errors somewhere in my code, and it's hard to track down where they might be. > 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? Yaron -- |--------/ Yaron M. Minsky \--------| |--------\ http://www.cs.cornell.edu/home/yminsky/ /--------| Open PGP --- KeyID B1FFD916 Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916 ------------------- 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