bigints

bearophile bearophileHUGS at lycos.com
Wed May 7 05:03:23 PDT 2008


renoX:
> To *avoid* bugs or to *hide* bugs ?

Many smart languages use multiprecision ints by default (for example Lisp, Haskell, Scheme, Python, some Forth variants, etc) because they act more like integer numbers you find in mathematics, instead like finite bitfields like you can find in C language. So they allow you to think of them as integers, that is a simpler concept to understand, so you code faster and/or you put less bugs in (but they are generally slower).
(I have programmed lot of time with both kinds of languages, plus some languages that act like something in the middle, so here I'm talking on the base of my experience).


> IMHO, if there is an integer overflow it's because either your 
> computations are wrong or the input validation isn't strict enough, 
> using big integers can help hide the bugs but doesn't really prevent 
> them (except in a few case)..

I have created a general sum() function for my libs, that return the sum of the values of a given iterable (array, AA keys, iterable class/struct), if you use sum() on an array of bytes/ubytes, you can often have overflow, with bogus results. That was a bug of mine, that later I have partially solved. If you write such sum() in Scheme or Python you usually can't fall into such bug.


> So IMHO the default should be normal int but which throw exception in 
> case of overflow: this help find the bugs sooner instead of hiding the 
> bugs..

That's how Delphi works by default, and if you look at the lists of notes I have posted in this group, that was one of the first suggestions of mine regarding D :-) I think such exceptions (that can be disabled with a compiler flag that acts on the whole program and can be disabled/enabled in specific parts of the code with compiler directives mixed into the code itself) are quite useful.


> But I agree that big ints should be also part of the language..

I think Walter has little against putting a big int module into Phobos, but what I was trying to say is that there are many situations where a smart compiler can use tons of tricks to speed up specific multiprecision/mixed computations, so they probably may enjoy built-in support by the compiler. Maybe today DMD doesn't need to have built-in complex numbers while it may enjoy a smart built-in management of multiprecision ints... :-)

Bye,
bearophile



More information about the Digitalmars-d mailing list