View mode: basic / threaded / horizontal-split · Log in · Help
June 28, 2010
MPIR lib
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
June 28, 2010
Re: MPIR lib
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.
June 28, 2010
Re: MPIR lib
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/
June 28, 2010
Re: MPIR lib
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
June 28, 2010
Re: MPIR lib
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
June 28, 2010
Re: MPIR lib
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
June 29, 2010
Re: MPIR lib
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><
July 11, 2010
Re: MPIR lib
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.
July 11, 2010
Re: MPIR lib
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><
Top | Discussion index | About this forum | D home