English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

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

Browse thread
[Caml-list] Big_int comparisons
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-02-02 (12:34)
From: Yaron M. Minsky <yminsky@c...>
Subject: Re: [Caml-list] Big_int comparisons
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:


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 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