February 08, 2008
bearophile Wrote:

> dominik:
> > walter did AWHILE ago Bigint implementation for zortech I believe, wouldn't it be nice to make it a part of D, not library per se? Be ti simple BCD implementation, I don't care, but I care for BigInt.
> 
> I'd like to have such bignum lib in the std lib. If someone here knows of a *working* bignum lib, please tell me, because I have tried many but none works.
> 
> Muti precision integral values are very useful, not for crypto purposes as some say, but because they don't overflow, so you can use them without caring of that *large* class of bugs (a certain percentage, like 10-30%, of all bugs comes from integral type overflows/underflows). Reducing that cognitive burden has the side effect of speeding up coding a bit too, because you can focus your minds on other things.
> Experience shows that on modern CPUs a certain (often large) percentage of the code doesn't need to be optimized a lot (this is why scripting languages are so used today), while you can use fixnums in the speed critical sections of the code.
> Said that, the DMD can grow smarter: it can infer some of the situations where a bigint doesn't actually needs to be a bigint (silly example: for(bigint i =0; i < 100; n++) {}) and it can replace them with fixnums :-) This can probably speed up the code enough, so people will use them in a more relaxed way, and this will reduce bug count even more :-) I don't know how much easy such bound inferring is, and how much it can slow down the compiler.
> 
> Bye,
> bearophile

And at the same time, I like this idea.  Though, I'd imagine unless you're trying to calculate pi to the centillionth decimal place there's not really much need for more than say, 256 bits.  But I'm sure that was once said about 32 bit numbers.

Regards,
Dan
February 08, 2008
Dan wrote:
> bearophile Wrote:
> 
>> dominik:
>>> walter did AWHILE ago Bigint implementation for zortech I believe, wouldn't it be nice to make it a part of D, not library per se? Be ti simple BCD implementation, I don't care, but I care for BigInt.
>> I'd like to have such bignum lib in the std lib. If someone here knows of a *working* bignum lib, please tell me, because I have tried many but none works.
>>
>> Muti precision integral values are very useful, not for crypto purposes as some say, but because they don't overflow, so you can use them without caring of that *large* class of bugs (a certain percentage, like 10-30%, of all bugs comes from integral type overflows/underflows). Reducing that cognitive burden has the side effect of speeding up coding a bit too, because you can focus your minds on other things.
>> Experience shows that on modern CPUs a certain (often large) percentage of the code doesn't need to be optimized a lot (this is why scripting languages are so used today), while you can use fixnums in the speed critical sections of the code.
>> Said that, the DMD can grow smarter: it can infer some of the situations where a bigint doesn't actually needs to be a bigint (silly example: for(bigint i =0; i < 100; n++) {}) and it can replace them with fixnums :-) This can probably speed up the code enough, so people will use them in a more relaxed way, and this will reduce bug count even more :-) I don't know how much easy such bound inferring is, and how much it can slow down the compiler.
>>
>> Bye,
>> bearophile
> 
> And at the same time, I like this idea.  Though, I'd imagine unless you're trying to calculate pi to the centillionth decimal place there's not really much need for more than say, 256 bits.  But I'm sure that was once said about 32 bit numbers.

In scientific computing, it's probably useful. In most ordinary scenarios, you aren't dealing with anything that 64 bits can't handle. With most graphics, you're going for speed rather than accuracy, but with things like Pixar, you might want large floating point numbers for additional accuracy.

> Regards,
> Dan
February 08, 2008
On 08/02/2008, Dan <murpsoft@hotmail.com> wrote:
> And at the same time, I like this idea.  Though, I'd imagine unless you're trying to calculate pi to the centillionth decimal place

He said integers. Pi is not an integer.
February 08, 2008
Janice Caron wrote:
> On 08/02/2008, Dan <murpsoft@hotmail.com> wrote:
>> And at the same time, I like this idea.  Though, I'd imagine unless you're trying to calculate pi to the centillionth decimal place
> 
> He said integers. Pi is not an integer.

Look up how people compute pi to large numbers of significant figures. Hint: they don't use floating point.

--bb
Top | Discussion index | About this forum | D home