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
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
nd even in the imperative case there is no reason in principle why a
runST-encapsulated imperative algorithm should be slower than C ---
although at the moment GHC does not do a consistently good job of
compiling imperative code.
So I rather agree with John: implementing bignums in Haskell, and tryi
This is a rather interesting question. Most "efficient"
implementations use array-based representations for bignums that are
mutable. The use of mutable arrays appears to be justified, because of
divide-and-conquer multiplication and division algorithms (e.g.
Karatsuba) that perform these operation
On Wed, Jun 22, 2005 at 12:47:02AM +0200, [EMAIL PROTECTED] wrote:
> John Meacham writes:
>
> >I wonder if it would be feasable to implement arbitrary precision
> >integers in pure haskell. unboxed values would probably want to be used
> >in some places for speed and it would be very motivating t
John Meacham writes:
I wonder if it would be feasable to implement arbitrary precision
integers in pure haskell. unboxed values would probably want to be used
in some places for speed and it would be very motivating to improve
ghc's optimizer. There should be no reason manually unboxed haskell c
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 it. Some reasons *not* to use it
> | are: it
| >> 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 it. Some reasons *not* to use it
| are: it has an awkward license, it's big, it needs updating, and we
run
| into problems whe
On 21 June 2005 12:47, Ketil Malde wrote:
> Marco Morazan <[EMAIL PROTECTED]> writes:
>
>> Do any of you have insight into why GHC uses GMP as opposed to
>> another library for arbitrary precision numbers?
>
> Did you have any particular other library in mind? I'm not too
> well-versed in this,
Serge D. Mechveliani wrote:
Efficient arithmetic algorithms for large numbers is a matter of
mathematics. Such algorithms, and libraries, are developed by the
best experts in computational mathematics. Maybe, GMP is such.
There isn't too much mathematics in... everything is known
for years,
On Tue, Jun 21, 2005 at 07:37:08AM -0400, Marco Morazan wrote:
> Hello all,
>
> Do any of you have insight into why GHC uses GMP as opposed to another
> library for arbitrary precision numbers? Also, why would bignums not
> be directly implemented for the GHC or other implementations of
> Haskell?
Marco Morazan <[EMAIL PROTECTED]> writes:
> Do any of you have insight into why GHC uses GMP as opposed to another
> library for arbitrary precision numbers?
Did you have any particular other library in mind? I'm not too
well-versed in this, but I think GMP is fairly efficient, well tested
and
Hello all,
Do any of you have insight into why GHC uses GMP as opposed to another
library for arbitrary precision numbers? Also, why would bignums not
be directly implemented for the GHC or other implementations of
Haskell?
Best wishes,
Marco
___
Glasg
13 matches
Mail list logo
