Re: [Caml-list] Big_int comparisons

["Yaron M. Minsky" <yminsky@cs.cornell.edu>]

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