GMP module support

GMP module support

[farazs]

        I have just joined the list. I need GMP support  so I sat
and read through the whole GMP in Guile discussion from 2002.

        The problem being discussed was mainly related to bignums
or integers. My problem is that of high-precision floating-point
calculations : so speed of GMP apart that is something guile
simply does not offer.

        Is someone working on a loadable-module for GMP?

        I propose that we create a GMP number-tower which is
symmetric to the guile one (except (+)proper rational numbers) and
allow "jumping" between the two by explicit casting. This way one
can keep fixnums for normal stuff like counts and use GMP numbers
selectively in tight loops where they are required.


- faraz < farazs@yapost.com >


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GMP module support

[Marius Vollmer]

farazs@yapost.com writes:

>         I propose that we create a GMP number-tower which is
> symmetric to the guile one (except (+)proper rational numbers) and
> allow "jumping" between the two by explicit casting. This way one
> can keep fixnums for normal stuff like counts and use GMP numbers
> selectively in tight loops where they are required.

Having support for unlimited precision numbers would be a nice
addition to Guile, indeed.  I don't fully understand what you mean
with uilding a second numeric tower.  That shouldn`t be necessary;
just integrate big-floats into the tower that we already have.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GMP module support

[Faraz Shahbazker]

[-- Attachment #1.1: Type: text/html, Size: 2326 bytes --]

[-- Attachment #1.2: Type: text/plain, Size: 1801 bytes --]

> From: Marius Vollmer

> Having support for unlimited precision numbers would be a nice
> addition to Guile, indeed.  I don't fully understand what you mean
> with uilding a second numeric tower.  That shouldn`t be necessary;
> just integrate big-floats into the tower that we already have.

hi,

        Well, from your discussion with Rob(and others)
from 2002, it appeared that there were some problems
regarding integrating GMP types into guile. So when you
say integrating big-floats, do you mean implementing a
separate multi-precision format spec for guile, or do
you mean using mpf_t in guile?

        If it's the first, I am afraid that I do not
have the expertise or experience to talk about it.
If the second, then perhaps you should reiterate in
clear terms the official policy regarding mixing guile
and other GPL'ed stuff (and add it to the docs or
something, so that new-comers like myself don't
go about asking the same question again and again)


  Overall, I think that beside the benifit that
GMP holds for guile-users, guile also holds a certain
amount of benifit for GMP-users. The reason being
that the main strength of GMP lies in it's
time-complexity factor and not it's space-complexity.
While it is still very efficient memory-wise, that
is not what it is used for. On the other hand, the
memory allocation/deallocation/initialization required
is a good reason for not using GMP. Since guile takes
the heartache of memory allocation off your hands, you
are more likely to use it wrapped up nicely in a
Scheme interface.

        The big question then really is whether our
garbage-collector can live-up to our expectations
in the extreme high-performance environments, where
GMP is normally employed?


- Faraz Shahbazker




[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: GMP module support

[Marius Vollmer]

"Faraz Shahbazker" <faraz_ms@rediffmail.com> writes:

> So when you say integrating big-floats, do you mean implementing a
> separate multi-precision format spec for guile, or do you mean using
> mpf_t in guile?

I meant using mpf_t in guile.  We now use mpz_t exclusively as our
multi-precision integers and we could add mpf_t as large floating
point numbers.  We might then have

   fixnum:   30 bits of signed long  (62 bits on 64 bit machines)
   bignum:   mpz_t
   float:    double
   bigfloat: mpf_t 

It would be nice to go from a float to a bigfloat when a calculation
overflows, I'd say.

>         If it's the first, I am afraid that I do not
> have the expertise or experience to talk about it.
> If the second, then perhaps you should reiterate in
> clear terms the official policy regarding mixing guile
> and other GPL'ed stuff (and add it to the docs or
> something, so that new-comers like myself don't
> go about asking the same question again and again)

GMP is LGPL now, as is Guile.  The two can be mixed without problem.

>         The big question then really is whether our
> garbage-collector can live-up to our expectations in the extreme
> high-performance environments, where GMP is normally employed?

What are those expectations?

Generally, I don't really see Guile fit to be a high-performance tool.
I do use it for number crunching, but interpreted Scheme is only used
to setup the calculation and the real crunching is done by small
kernels written in C.  Best of both worlds...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user