RE: libraries for Integer
Hi Sergey, | In what way the Haskell implementations may use the GMP library? | (GNU Multi-Precision integers ?) Hugs 98 doesn't use gmp at all. For legal reasons (later rendered irrelevant by changes to the Hugs license), Hugs used it's own implementation of multi-precision integers. | And there also exist other powerful libraries for Integer and for the | number theory. Probably, some of them written in C. One could consider | exploiting them in the Haskell implementation. I guess that H/Direct would be the best way to take advantage of these right now. All the best, Mark
Re: libraries for Integer
Mark P Jones wrote: I guess that H/Direct would be the best way to take advantage of these right now. I agree actually. Integer only needs to be an implementation of multiprecision arithmetic; we shouldn't tie it to GMP. There are other multiprecision arithmetic packages out there, for example the LIP package included in NTL http://www.shoup.net/ntl/ Of course where it so happens that GMP is used for the implementation of big integers, there is no reason why the implementation should not provide additional access, via HDirect or a specially written interface, to additional GMP functions.
Re: libraries for Integer
George Russell ([EMAIL PROTECTED]) wrote: : I agree actually. Integer only needs to be an implementation of : multiprecision arithmetic; we shouldn't tie it to GMP. There are : other multiprecision arithmetic packages out there, for example But it is pretty fast. : the LIP package included in NTL :http://www.shoup.net/ntl/ Do you have any data about comparisons with this or other packages? Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED]
Re: libraries for Integer
Marc van Dongen wrote: Do you have any data about comparisons with this or other packages? I've just looked around Dave Rusin's page: http://www.math.niu.edu/~rusin/known-math/index/11YXX.html but it doesn't seem to contain any up-to-date comparisons; in particular not of GMP 3. There are two things in favour of LIP: (1) it has the magic name of "Lenstra" attached to it (Arjen in this case). (2) I believe it will be better than GMP 2 for integers with thousands of digits or more because it implements FFT multiplication (or something similar). But I can't remember for sure. However if GMP now implements Toom-Cook that should make a big difference here. Sorry I can't be more helpful. But there is unlikely to be a simple answer to the question "Does LIP or GMP multiply numbers fastest?"; it will depend on how big the numbers are, what platform you are using, and how much difficult the interface is to use. (GMP is faster if you use the mpn_ functions, but then you have to do all your own allocation and only get non-negative integers.)
Re: libraries for Integer
George Russell wrote: (GMP is faster if you use the mpn_ functions, but then you have to do all your own allocation and only get non-negative integers.) Sorry, I meant GMP is faster if you use mpn_ than if you use the other GMP functions, not that the mpn_ functions are faster than LIP.
Re: libraries for Integer
George Russell ([EMAIL PROTECTED]) wrote: [...] : Sorry I can't be more helpful. But there is unlikely to be a simple : answer to the question "Does LIP or GMP multiply numbers fastest?"; : it will depend on how big the numbers are, what platform you are using, : and how much difficult the interface is to use. (GMP is faster if Thanks anyway. [...] Regards, Marc
Re: libraries for Integer
No. It is all right. For example, gcdExt 4 6 = (2,-1,1),so -1*4 + 1*6 = 2 = gcd 4 6. Maybe, you forgot of negatives? -- Sergey Mechveliani [EMAIL PROTECTED]
Re: libraries for Integer
Wed, 19 Apr 2000 10:19:08 +0400 (MSD), S.D.Mechveliani [EMAIL PROTECTED] pisze:
I have an impression that Haskell-98 calls `Integral' various models
for the domain of integer numbers. And this is for Haskell-98'.
While the good standard of future (I hope for Haskell-2) has, to my
mind, to remove Integral and introduce GCDRing, FactorizationRing,
EuclideanRing, Field - see
http://www.botik.ru/pub/local/Mechveliani/basAlgPropos/
Why I don't like this proposal:
- It's too complicated.
- Relies on controversial type system features, like undecidable
instances and overlapping instances.
- Relies on type system features that are not implemented and it's
not clear if they can be correctly designed or implemented at all,
like "domain conversions".
- Has many instances that should not exist because the relevant type
does not have the class property; they return Nothing or fail,
instead of failing to compile.
- Properties like commutativity cannot be specified in Haskell.
The compiler won't be able to automatically perform any optimizations
based on commutativity.
- belongs is strange. IMHO it should always return True for valid
arguments, and invalid arguments should be impossible to construct
if the validity can be checked at all.
- Tries to turn a compiled language into an interpreted language.
FuncExpr, too much parsing (with arbitrary rules hardwired into
the language), too much runtime checks.
- It's too complicated.
- It's not true that it's "not necessary to dig into mathematics".
I studied mathematics and did not have that much of algebra.
- I perfer minBound to looking at element under Just under Just under
tuple of osetBounds.
- Uses ugly character and string arguments that tune the behavior,
e.g. in syzygyGens, divRem, canFr. I like Haskell98's divMod+quotRem
better.
- Uses unneeded sample arguments, e.g. in toEnum, zero, primes, read.
- Have I said that it's too complicated?
--
__("Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++$ P+++ L++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+++ DI D- G+ e h! r--%++ y-
