This is derived from the GNU multiprecision libs:
http://www.mpir.org/
It has LGPL licence, is this usable as implementation of D2 bigint?

Bye,
bearophile

bearophile wrote:
> This is derived from the GNU multiprecision libs:
> http://www.mpir.org/
> It has LGPL licence, is this usable as implementation of D2 bigint?

No, LGPL is not a Boost compatible license. It is considerably more restrictive.

On 2010-06-28 16:22:47 -0400, Walter Bright <newshound2@digitalmars.com> said:

> bearophile wrote:
>> This is derived from the GNU multiprecision libs:
>> http://www.mpir.org/
>> It has LGPL licence, is this usable as implementation of D2 bigint?
> 
> No, LGPL is not a Boost compatible license. It is considerably more restrictive.

I've used MAPM in the past, it worked well for what I did. The license is much less restrictive, but is still a little more than boost's. But perhaps there's a chance someone can convince the author to make it boost-compatible. It can do arbitrary precision ints and floats.

http://www.tc.umn.edu/~ringx004/mapm-main.html

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Mon, 28 Jun 2010 17:36:19 -0400, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2010-06-28 16:22:47 -0400, Walter Bright <newshound2@digitalmars.com> said:
>
>> bearophile wrote:
>>> This is derived from the GNU multiprecision libs:
>>> http://www.mpir.org/
>>> It has LGPL licence, is this usable as implementation of D2 bigint?
>>  No, LGPL is not a Boost compatible license. It is considerably more restrictive.
>
> I've used MAPM in the past, it worked well for what I did. The license is much less restrictive, but is still a little more than boost's. But perhaps there's a chance someone can convince the author to make it boost-compatible. It can do arbitrary precision ints and floats.
>
> http://www.tc.umn.edu/~ringx004/mapm-main.html
>

What's wrong with d2's bigint that Don has written?

-Steve

Steven Schveighoffer:
> What's wrong with d2's bigint that Don has written?

MPIR is "not invented here" :-) Moving part of the development of a very tricky part of code full of long asm routines (see their amount of code finely tuned for different CPUs) to someone else that has more resources and dedication is sometimes positive. It frees Don to do something else for D, allows to use potentially less buggy code (because more people use the same lib), and MPIR contains several good numerical algos and numeric types that are missing in Don's bigint.

By the way, even if MPIR gets a Boost licence some work can be useful to adapt it to D, because in D I'd like the multi-precision integrals to be very efficient even when they are used with numbers about 32 bits long or less, so in some programs they can be a replacement of normal integers. This can be done using an union with a tag and switching to normal integer operations when numbers are small (in this case zero memory is allocated on the heap to keep such numbers). I don't know if MPIR is already performing this optimization, I think it is not (I have asked this small-number optimization in Don's bigints too in past, and I think he likes this idea).

Bye,
bearophile

On Mon, 28 Jun 2010 18:18:46 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> What's wrong with d2's bigint that Don has written?
>
> MPIR is "not invented here" :-) Moving part of the development of a very tricky part of code full of long asm routines (see their amount of code finely tuned for different CPUs) to someone else that has more resources and dedication is sometimes positive. It frees Don to do something else for D, allows to use potentially less buggy code (because more people use the same lib), and MPIR contains several good numerical algos and numeric types that are missing in Don's bigint.
>
> By the way, even if MPIR gets a Boost licence some work can be useful to adapt it to D, because in D I'd like the multi-precision integrals to be very efficient even when they are used with numbers about 32 bits long or less, so in some programs they can be a replacement of normal integers. This can be done using an union with a tag and switching to normal integer operations when numbers are small (in this case zero memory is allocated on the heap to keep such numbers). I don't know if MPIR is already performing this optimization, I think it is not (I have asked this small-number optimization in Don's bigints too in past, and I think he likes this idea).

OK, I thought you meant we should discard the current bigint in favor of some other implementation.  I wasn't aware that D2's bigint still had missing features (I haven't used it).

-Steve

Hello bearophile,

> Steven Schveighoffer:
> 
>> What's wrong with d2's bigint that Don has written?
>> 
> MPIR is "not invented here" :-) Moving part of the development of a
> very tricky part of code full of long asm routines (see their amount
> of code finely tuned for different CPUs) to someone else that has more
> resources and dedication is sometimes positive. It frees Don to do
> something else for D, allows to use potentially less buggy code
> (because more people use the same lib), and MPIR contains several good
> numerical algos and numeric types that are missing in Don's bigint.

If I'm remembering correctly who's who, it reasonably likely that Don had a hand in some of the code one or the other of those libs. Someone around here has contributed to some high performance numerics libs.

-- 
... <IXOYE><

BCS wrote:
> Hello bearophile,
> 
>> Steven Schveighoffer:
>>
>>> What's wrong with d2's bigint that Don has written?
>>>
>> MPIR is "not invented here" :-) Moving part of the development of a
>> very tricky part of code full of long asm routines (see their amount
>> of code finely tuned for different CPUs) to someone else that has more
>> resources and dedication is sometimes positive. It frees Don to do
>> something else for D, allows to use potentially less buggy code
>> (because more people use the same lib), and MPIR contains several good
>> numerical algos and numeric types that are missing in Don's bigint.
> 
> If I'm remembering correctly who's who, it reasonably likely that Don had a hand in some of the code one or the other of those libs. Someone around here has contributed to some high performance numerics libs.
> 
I have never contributed to any non-D libs.

Hello Don,

> BCS wrote:
> 
>> Hello bearophile,
>> 
>>> Steven Schveighoffer:
>>> 
>>>> What's wrong with d2's bigint that Don has written?
>>>> 
>>> MPIR is "not invented here" :-) Moving part of the development of a
>>> very tricky part of code full of long asm routines (see their amount
>>> of code finely tuned for different CPUs) to someone else that has
>>> more resources and dedication is sometimes positive. It frees Don to
>>> do something else for D, allows to use potentially less buggy code
>>> (because more people use the same lib), and MPIR contains several
>>> good numerical algos and numeric types that are missing in Don's
>>> bigint.
>>> 
>> If I'm remembering correctly who's who, it reasonably likely that Don
>> had a hand in some of the code one or the other of those libs.
>> Someone around here has contributed to some high performance numerics
>> libs.
>> 
> I have never contributed to any non-D libs.
> 

http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel

Close enought for my point, (unless the Don referenced there isn't you).

-- 
... <IXOYE><