Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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, 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              \--------|
|--------\ /--------|

Open PGP --- KeyID B1FFD916
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: