There's nothing inherently imperative about bignums. The current
algorithms may have an imperative flavour, but that may be partly
because that's what suits the implementation language. If the
algorithms are divide-and-conquer, perhaps a tree representation would
work very nicely.
And even in th
On 21 June 2005 22:52, John Meacham wrote:
> On Tue, Jun 21, 2005 at 03:48:44PM +0100, Simon Peyton-Jones wrote:
>>
> Do any of you have insight into why GHC uses GMP as opposed to
> another library for arbitrary precision numbers?
>> ...
>>>
>>> Right - that's three reasons to use
People,
When intending to write a library for large numbers,
it worths to keep in mind the following.
1. Efficient multiplication, division and gcd methods may occur
rather involved mathematically.
2. It is natural for `arithmetics' to include factorization.
Suppose, GHC would like to inc
I have installed ghc-5.02.3 and ghc-cvs-6-4-branch-June-15
on the same Linux machine, ported DoCon to 6-4-branch, and compared
DoCon-2.06 - ghc-5.02.3
to DoCon-2.09 - ghc-cvs-6-4-branch-June-15
on computer algebra (the CA algorithms are the same).
1. They work correct.
2. The per
Serge D. Mechveliani wrote:
3. It is natural to extend further the library to
algebraic numbers.
Bignum arithmetics and algebraic numbers are worlds apart.
Sergey - as always - is ambitious to perfection. That's good, but
let people do the basics first...
Jerzy Karczmarczuk
__
I believe that native support for bignums is a rather interesting and
good idea for Haskell and for other functional languages. Developing
native support provides the opportunity to implement many
optimizations for a specific language (without, of course, sacrificing
the usefulness of the design fo
