[Caml-list] Num library

[Caml-list] Num library

[Alain Frisch]

Hello Caml List,

I'm considering using the Num library (from the standard distribution) for
implementing numbers in an interpreter. Questions:

- Is there any benchmark available ?  What is the overhead when dealing
  with "small" integers ?

- How does the library compare with other large/rational numbers
  implementations ?

- The manual mentions two special elements 1/0 and 0/0; it seems
  that -1/0 is also available. Is it a bug in the manual or the
  implementation ?


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

Re: [Caml-list] Num library

[sebastien FURIC]

 Hello,

Alain Frisch a écrit :
> 
> Hello Caml List,
> 
> I'm considering using the Num library (from the standard distribution) for
> implementing numbers in an interpreter. Questions:
> 
> - Is there any benchmark available ?  What is the overhead when dealing
>   with "small" integers ?
> 
> - How does the library compare with other large/rational numbers
>   implementations ?

 I made some benchmarks with Dolphin Smalltalk (a pure Smalltalk
bytecode interpreter) and O'Caml (using ocamlopt) a few months ago. To
my great surprise, Dolphin Samlltalk outperformed O'Caml by a factor of
4 over various tests IIRC. I think the same results may be obtained with
other modern big numbers implementations against O'Caml's one.
 The context was the following: I had to rewrite a program that performs
symbolic manipulations from Smalltalk to O'Caml and this benchmark was
the first thing I did to test O'Caml's performance (I was a little
disappointed!). Finally, despite O'Caml's poor performance over bignum
computations, O'Caml outperformed Smalltalk by a factor of 100 over
"real world" benchmarks! (because only a few percents of the time is
spent in bignum calculations and most of the time is spent doing
substitutions etc.).

 Sébastien.
-------------------
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

Re: [Caml-list] Num library

[Yaron M. Minsky]

Num is by all accounts a pretty mediocre bignum implementation.  There's
also mlgmp, which is an interface to GMP.  I haven't used it, but GMP is
fast.  There's also Numerix, which I have used. Numerix at least at one
point was a good deal faster than GMP in many cases, and is very easy to
use.  I'm not sure how GMP and Numerix compare in terms of speed these
days, since GMP has seen more development and Numerix has not.
y

> Hello,
>
> Alain Frisch a écrit :
>>
>> Hello Caml List,
>>
>> I'm considering using the Num library (from the standard distribution)
>> for implementing numbers in an interpreter. Questions:
>>
>> - Is there any benchmark available ?  What is the overhead when
>> dealing
>>   with "small" integers ?
>>
>> - How does the library compare with other large/rational numbers
>>   implementations ?
>
> I made some benchmarks with Dolphin Smalltalk (a pure Smalltalk
> bytecode interpreter) and O'Caml (using ocamlopt) a few months ago. To
> my great surprise, Dolphin Samlltalk outperformed O'Caml by a factor of
> 4 over various tests IIRC. I think the same results may be obtained
> with other modern big numbers implementations against O'Caml's one.
> The context was the following: I had to rewrite a program that performs
> symbolic manipulations from Smalltalk to O'Caml and this benchmark was
> the first thing I did to test O'Caml's performance (I was a little
> disappointed!). Finally, despite O'Caml's poor performance over bignum
> computations, O'Caml outperformed Smalltalk by a factor of 100 over
> "real world" benchmarks! (because only a few percents of the time is
> spent in bignum calculations and most of the time is spent doing
> substitutions etc.).
>
> Sébastien.
> -------------------
> 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


-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
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

Re: [Caml-list] Num library

[Pierre Weis]

> Num is by all accounts a pretty mediocre bignum implementation.  There's
> also mlgmp, which is an interface to GMP.  I haven't used it, but GMP is
> fast.  There's also Numerix, which I have used. Numerix at least at one
> point was a good deal faster than GMP in many cases, and is very easy to
> use.  I'm not sure how GMP and Numerix compare in terms of speed these
> days, since GMP has seen more development and Numerix has not.
> y

I'm afraid this is a bit rough, not a fair scientific study.

Once more, just one question to you: which layer of the Num library
had you benchmarked ?

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

Re: [Caml-list] Num library

[Alain Frisch]

On Thu, 10 Oct 2002, Pierre Weis wrote:

> Once more, just one question to you: which layer of the Num library
> had you benchmarked ?

Mmmh, I did not intend to launch a new flamewar here ...

Maybe you can give some information yourself about the library. If I want
to manipulate only integers (no rational numbers), most of which will be
small integers, is it better to use Num or Big_int ?  Would Num benefit to
be specialized to (small+big) integers (that is, throwing away the Ratio
constructor) ?  Because int values and Big_int values can be distinguished
at runtime, one could imagine implementing the union "by hand" (without
explicit tagging, and thus avoiding a lot of memory allocation and
garbage collection). What would be the gain ?

General question: the library seems to be extremely stable since a several
years. Does it mean you consider that it is just good as it is, or does it
mean you don't want to continue working on it  ?

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

Re: [Caml-list] Num library

[Pierre Weis]

> On Thu, 10 Oct 2002, Pierre Weis wrote:
> 
> > Once more, just one question to you: which layer of the Num library
> > had you benchmarked ?
> 
> Mmmh, I did not intend to launch a new flamewar here ...
> 
> Maybe you can give some information yourself about the library. If I want
> to manipulate only integers (no rational numbers), most of which will be
> small integers, is it better to use Num or Big_int ?  Would Num benefit to
> be specialized to (small+big) integers (that is, throwing away the Ratio
> constructor) ?  Because int values and Big_int values can be distinguished
> at runtime, one could imagine implementing the union "by hand" (without
> explicit tagging, and thus avoiding a lot of memory allocation and
> garbage collection). What would be the gain ?

The Num library is fairly sophisticated and fairly well integrated
into the Caml language. We still need some lexical additions to be
quite confortable to input numbers, but still it is a really mature
and useful library.

Now, some quick info to understand why it is so difficult to bench
unubounded precision arithmetic packages.

Our Num library has 4 arithmetic layers:

- nat: positive integers. Allocation is explicit, operations are pure
side effects (result is stored in operands).

- big_int: signed integers. Allocation is implicit, operations are
functional.

- ratio: rational numbers. Allocation is implicit, operations are
functional, but normalization is a side-effect. Normalization is
either automatic or explicitely required by the user. You have to know
that this sophisticated normalization discipline is just mandatory to
obtain good performance with this layer: just changing the
normalization regime of rational arithmetic primitives can have an
exponential impact on the runtime (either systematic normalization or
no normalization at all may exponentiallly win or loose depending on
the computation at hand!)

- num: the higer layer. Numbers are small integers, big integers, or
rational numbers. Necessary coercion between those types are handled
automatically by the library.

The num layer is the more convenient to write programs. The nat layer
is the most efficient if you just need integers. The big_int layer is
generally a bit faster that the num layer, but if you want to be
really efficient you need to use the nat layer. The programmation in
the nat layer is a bit difficult, but the efficiency is (normally)
what you gain: you end with no garbage collection at all, the numbers
are allocated from the beginning of the computation with the right
size to contain the final result, the operations are minimized (both
in the size of operands and in the number of operations required to
obtain the final result). We use to say that nat programming was the
algorithmic proof level: you must state and prove your invariants
while programming; a very profitable and refreshing exercice.

Also the Num library is optimized for computation, not for
printing. The idea being that normally you compute a lot and just
print the final result. If your bench is just printing a lot of big
numbers that are easily obtained with almost no computation (for
instance factorial numbers), you will think the Num library to be very
slow. However, we know that in the Num library the printing of big
numbers is too slow and has to be revisited to go faster.

As for the suggested improvement on the num type ``by hand'', some
Caml compilers were (once) able to automatically do the optimization
you just described (by the way not only for small ints but for the 3
constructors of the type). As you may suspect, the gain depends a lot
on the application at hand. In some cases, the speedup was impressive
(I remember a matrices package that almost never use big numbers,
except in case of ill-conditioned problems: the improvement of num
arithmetic versus big_int arithmetic was impressive). However, you
cannot have the same arithmetic efficiency with small integers
represented as num values since you need to check for potential
overflows for each operation (meaning at least 5 to 10 instructions
instead of 1).

Also this optimization does not fit very well with the pattern
matching compiler technology of the current compiler. In addition, it
is not clear that it will be a big win in general (I mean out of the
big number arithmetic domain, where it is clearly a win).

> General question: the library seems to be extremely stable since a several
> years. Does it mean you consider that it is just good as it is, or does it
> mean you don't want to continue working on it  ?

Yes, the library is extremely stable, and this is an extremely
desirable property: bugs are also extremely well chased.

Concerning the development of the library, I once wrote a new
implementation of the library from scratch. Unfortunately, I stopped
when facing the problem of fast printing which is not so trivial. We
may also consider to reimplement the Num library on top of another big
numbers implementation (GMP or Numerix, if only some volonteers added
assembly code for as many processors as necessary to run on all
the platforms where Objective Caml is available).

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

Re: [Caml-list] Num library

[Yaron M. Minsky]

I thought I was mostly passing on the common wisdom about the Num library.
 I didn't test it myself, but the numerix documentation has some
performance numbers which make the Big_int part of Num look quite weak
compared to GMP and Numerix  --- it came up as the loser over both in most
cases, especially for large sizes.   You can find it on Michel Quercia's
page.  But I don't know much about Num's performance outside of Michel's
results, and I'm open to being corrected.
y

>> Num is by all accounts a pretty mediocre bignum implementation.
>> There's also mlgmp, which is an interface to GMP.  I haven't used it,
>> but GMP is fast.  There's also Numerix, which I have used. Numerix at
>> least at one point was a good deal faster than GMP in many cases, and
>> is very easy to use.  I'm not sure how GMP and Numerix compare in
>> terms of speed these days, since GMP has seen more development and
>> Numerix has not.
>> y
>
> I'm afraid this is a bit rough, not a fair scientific study.
>
> Once more, just one question to you: which layer of the Num library had
> you benchmarked ?
>
> Pierre Weis
>
> INRIA, Projet Cristal, Pierre.Weis@inria.fr,
> http://pauillac.inria.fr/~weis/


-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
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

Re: [Caml-list] Num library

[Pierre Weis]

>  I made some benchmarks with Dolphin Smalltalk (a pure Smalltalk
> bytecode interpreter) and O'Caml (using ocamlopt) a few months ago. To
> my great surprise, Dolphin Samlltalk outperformed O'Caml by a factor of
> 4 over various tests IIRC. I think the same results may be obtained with
> other modern big numbers implementations against O'Caml's one.
[...]

What do you know about Caml big numbers library ? Are you sure to have
used the proper layer of the library tuned to performance or have you
used the casual layer tuned to coding facility ?

What do you know of the Smalltalk big numbers library ? In which
language is it written ? What are the algorithms used ?

What were your benchmark programs ? What are your figures ?

Be serious on such a topic please! Comparing arithmetic packages is
not a trivial task and you cannot state ``Dolphin Samlltalk
outperformed O'Caml by a factor of 4'' without strong arguments and
evidence that this is indeed true.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

Re: [Caml-list] Num library

[Sebastien Furic]

Pierre Weis wrote:
> 
> >  I made some benchmarks with Dolphin Smalltalk (a pure Smalltalk
> > bytecode interpreter) and O'Caml (using ocamlopt) a few months ago. To
> > my great surprise, Dolphin Samlltalk outperformed O'Caml by a factor of
> > 4 over various tests IIRC. I think the same results may be obtained with
> > other modern big numbers implementations against O'Caml's one.
> [...]
> 
> What do you know about Caml big numbers library ? Are you sure to have
> used the proper layer of the library tuned to performance or have you
> used the casual layer tuned to coding facility ?
> 
> What do you know of the Smalltalk big numbers library ? In which
> language is it written ? What are the algorithms used ?
> 
> What were your benchmark programs ? What are your figures ?
> 
> Be serious on such a topic please! Comparing arithmetic packages is
> not a trivial task and you cannot state ``Dolphin Samlltalk
> outperformed O'Caml by a factor of 4'' without strong arguments and
> evidence that this is indeed true.
> 
> Pierre Weis

 My intention was not to begin a flame war.

 Dolphin's numerical algorithms are written in assembly language, like
all time-critical parts of the interpreter. Unfortunately, Dolphin's
team just announced "new faster algorithms" (and didn't give information
about the algorithms they use).
 Of course, I tried to tune my O'Caml code but I couldn't beat Dolphin's
implementation (despite the use of Nat etc.). Dolphin's bignums are
natively supported by the language and there is no way to hack them.
This is however very convenient for occasional users like me because I
don't have many time to "hack" numerical packages.
 Please note that I'm perfectly happy with O'Caml though.

 Regards,
 Sebastien.
-------------------
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

Re: [Caml-list] Num library

[Pierre Weis]

[...]
>  My intention was not to begin a flame war.

Nor is it mine. I'm sorry to react like this, but this kind of
(seamingly not well argumented) affirmation can hurt people that
worked for years on this kind of topics.

> Dolphin's numerical algorithms are written in assembly language, like
> all time-critical parts of the interpreter.

Is Dolphin's interpreter available on a wide variety of architectures?

> Unfortunately, Dolphin's team just announced "new faster algorithms"
> (and didn't give information about the algorithms they use).
>  Of course, I tried to tune my O'Caml code but I couldn't beat Dolphin's
> implementation (despite the use of Nat etc.).

I would be glad to see your code then. Especially the nat implementation.

> Dolphin's bignums are natively supported by the language and there
> is no way to hack them. This is however very convenient for
> occasional users like me because I don't have many time to "hack"
> numerical packages. Please note that I'm perfectly happy with
> O'Caml though.

Yes, native support for bignums is a win (as I mentioned earlier, it is
very convenient to input numbers)

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

Re: [Caml-list] Num library

[Alessandro Baretta]

Pierre Weis wrote:

> What do you know about Caml big numbers library ? Are you sure to have
> used the proper layer of the library tuned to performance or have you
> used the casual layer tuned to coding facility ?

I hope you will excuse my ignorance on the matter: what do 
you mean by "library layer"? I see no reference to this in 
the docs.

Alex

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

Re: [Caml-list] Num library

[Claude Marche]

I have no benchmark to produce, I just want to share my own experience:
I have an application where integers fit 99% of the time in machine
ints, but not always, and since I want to be sure that no overflow
occurs, I use the Num library. Some time ago, I've tried to used mlgmp
instead. On my own tests, that are not supposed to be exhaustive, mlgmp
was much faster when computing on really large integers, but when
integers are small, Num is much faster.

So I recommend to use mlgmp instead of Num only if you have large
integers most of the time. I tried also numerix, but it seems not
maintained anymore. Also I must say I did not use rational numbers.

As Jean-Christophe said, when using Nums you should take care not to
use structural equality (Pervasives.(=)) since representation of them
is not unique. So use Num.eq_num, Num.compare_num instead. Same issue,
you should not use Pervasives.hash, but something of your own.

Hope this helps.

- Claude


>>>>> "Alain" == Alain Frisch <frisch@clipper.ens.fr> writes:

    Alain> Hello Caml List,
    Alain> I'm considering using the Num library (from the standard distribution) for
    Alain> implementing numbers in an interpreter. Questions:

    Alain> - Is there any benchmark available ?  What is the overhead when dealing
    Alain>   with "small" integers ?

    Alain> - How does the library compare with other large/rational numbers
    Alain>   implementations ?

    Alain> - The manual mentions two special elements 1/0 and 0/0; it seems
    Alain>   that -1/0 is also available. Is it a bug in the manual or the
    Alain>   implementation ?

    Alain> -- Alain

-- 
| Claude Marché           | mailto:Claude.Marche@lri.fr |
| LRI - Bât. 490          | http://www.lri.fr/~marche/  |
| Université de Paris-Sud | phoneto: +33 1 69 15 64 85  |
| F-91405 ORSAY Cedex     | faxto: +33 1 69 15 65 86    |
-------------------
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

Re: [Caml-list] Num library

[Sebastien Furic]

Claude Marche wrote:
> 
> I have no benchmark to produce, I just want to share my own experience:
> I have an application where integers fit 99% of the time in machine
> ints, but not always, and since I want to be sure that no overflow
> occurs, I use the Num library. Some time ago, I've tried to used mlgmp
> instead. On my own tests, that are not supposed to be exhaustive, mlgmp
> was much faster when computing on really large integers, but when
> integers are small, Num is much faster.
> 
> So I recommend to use mlgmp instead of Num only if you have large
> integers most of the time. I tried also numerix, but it seems not
> maintained anymore. Also I must say I did not use rational numbers.
> 
> As Jean-Christophe said, when using Nums you should take care not to
> use structural equality (Pervasives.(=)) since representation of them
> is not unique. So use Num.eq_num, Num.compare_num instead. Same issue,
> you should not use Pervasives.hash, but something of your own.

 You must use Num.eq_num for another reason: Pervasives.( = ) fails at
runtime on bigints and rationals. I had to rewrite parts of what I
considered "generic" data structures when I have used them to store
objects referencing bignums.

 Cheers,

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

Re: [Caml-list] Num library

[Jean-Christophe Filliatre]

Alain Frisch writes:
 > 
 > I'm considering using the Num library (from the standard distribution) for
 > implementing numbers in an interpreter. Questions:
 > 
 > - How does the library compare with other large/rational numbers
 >   implementations ?

I'm not going to comment on the efficiency of Num.

But, for  having tried  to use  it in a  serious software  and finally
replaced  it by  mlgmp, I  can mention  one true  weakness of  the Num
library: there is  no unicity of representation (e.g. 1  can be Int 1,
but  also Ratio  1/1, etc.)  and  consequently you  cannot use  caml's
comparison and hash functions over it.

Of course, you  can use compare_num (hash_num is  lacking, though) but
when  nums are  involved  within  huge datatypes,  you  have to  write
structural comparison  and hash functions  for these types. This  is a
pain, really.

-- 
Jean-Christophe

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

"custom" operators in caml (was: Re: [Caml-list] Num library)

[Chris Hecker]

>when nums are  involved  within  huge datatypes,  you  have to  write
>structural comparison  and hash functions  for these types. This  is a
>pain, really.

This brings up a general issue:  from the C side you can create custom 
blocks that have hooks for various operators 
(finalize,compare,hash,serialize).  Is there any way to do this from the ml 
side?  In other words, if you could hook into the num block somehow and 
register these operators in caml that would allow you do embed them in 
datastructures and use =, and the runtime would call eq_num.

Of course, you don't want the whole block to be custom, because you want 
ocaml to scan it in the gc and you want it to be able to be operated on in 
caml.

I assume there's no way to do this, since you'd need a new block type, and 
there are no more tags left without lowering No_scan_tag, which would break 
everything (or at least anything that has a big constant variant), I 
assume.  But I don't know.

Just another thought in my continuing desire to be able to do everything 
without dropping to C...

Chris

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

Re: [Caml-list] Num library

[Pierre Weis]

Hi Jean-Christophe,

> I'm not going to comment on the efficiency of Num.
> 
> But, for  having tried  to use  it in a  serious software  and finally
> replaced  it by  mlgmp, I  can mention  one true  weakness of  the Num
> library: there is  no unicity of representation (e.g. 1  can be Int 1,
> but  also Ratio  1/1, etc.)  and  consequently you  cannot use  caml's
> comparison and hash functions over it.

You should have reported this behaviour, since it is a bug: the
library was known to provide a normal form to value of type num. If it
fails to do so it is just an implementation flaw that we have to
correct.

> Of course, you  can use compare_num (hash_num is  lacking, though) but
> when  nums are  involved  within  huge datatypes,  you  have to  write
> structural comparison  and hash functions  for these types. This  is a
> pain, really.
> -- 
> Jean-Christophe

Yes, you're right, it is almost impossible to handle: that why the
library was supposed to provide a normal form for nums ...

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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