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