www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - bigints

reply bearophile <bearophileHUGS lycos.com> writes:
When I talk about adding multiprecision integral numbers to D (mostly becasue
using them avoids most integer bugs), I usually add that the compiler can then
use many tricks to speed them up, this simple post shows few examples of those
tricks (so to be faster they may enjoy compiler support, as today D complex
numbers have):
http://factor-language.blogspot.com/2008/04/performance-improvements.html

With AST macros and multiprecision numbers D may look closer to a Lisp ;-)

Bye,
bearophile
Apr 21 2008
next sibling parent "Scott S. McCoy" <tag cpan.org> writes:
Wow, factor!  I interviewed the kid who designed that language just a
few months ago.  He's sharp as a tack, and passed up our job to work on
DSL research.

On Mon, 2008-04-21 at 05:29 -0400, bearophile wrote:

 When I talk about adding multiprecision integral numbers to D (mostly becasue
using them avoids most integer bugs), I usually add that the compiler can then
use many tricks to speed them up, this simple post shows few examples of those
tricks (so to be faster they may enjoy compiler support, as today D complex
numbers have):
 http://factor-language.blogspot.com/2008/04/performance-improvements.html
 
 With AST macros and multiprecision numbers D may look closer to a Lisp ;-)
 
 Bye,
 bearophile
Apr 21 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 When I talk about adding multiprecision integral numbers to D (mostly
 becasue using them avoids most integer bugs), I usually add that the
 compiler can then use many tricks to speed them up, this simple post
 shows few examples of those tricks (so to be faster they may enjoy
 compiler support, as today D complex numbers have): 



Coincidentally, I had just made a blog post about why ints are core 
types, and touched on the same issues:

http://dobbscodetalk.com/index.php?option=com_myblog&show=Core-vs-Library.html&Itemid=29
Apr 21 2008
prev sibling next sibling parent reply renoX <renosky free.fr> writes:
bearophile a écrit :

 When I talk about adding multiprecision integral numbers to D (mostly
 becasue using them avoids most integer bugs)


To *avoid* bugs or to *hide* bugs ?

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)..

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..

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

renoX


, I usually add that the
 compiler can then use many tricks to speed them up, this simple post
 shows few examples of those tricks (so to be faster they may enjoy
 compiler support, as today D complex numbers have): 
 http://factor-language.blogspot.com/2008/04/performance-improvements.html
 
 
 With AST macros and multiprecision numbers D may look closer to a
 Lisp ;-)
 
 Bye, bearophile
May 07 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
May 07 2008
prev sibling next sibling parent Nick B <nick.barbalich gmail.com> writes:
bearophile wrote:

 When I talk about adding multiprecision integral numbers to D (mostly because
using them avoids most integer bugs), I usually add that the compiler can then
use many tricks to speed them up, this simple post shows few examples of those
tricks (so to be faster they may enjoy compiler support, as today D complex
numbers have):
 http://factor-language.blogspot.com/2008/04/performance-improvements.html
 
 With AST macros and multiprecision numbers D may look closer to a Lisp ;-)
 
 Bye,
 bearophile




 Walter Bright wrote (under a seperate thread) :

 The scrolling issue is a real one, too. Things tend to scroll up
 and away. The way to have them not get lost is:

 1) Enhancement requests should go into bugzilla with perhaps a link 


to > the corresponding archives page


If no one objects to your excellent suggestion, then following Walters 
suggestion (above), you should put this request into bugzilla.

cheers
Nick
May 08 2008
prev sibling parent Nick B <nick.barbalich gmail.com> writes:
bearophile wrote:

 When I talk about adding multiprecision integral numbers to D (mostly becasue
using them avoids most integer bugs), I usually add that the compiler can then
use many tricks to speed them up, this simple post shows few examples of those
tricks (so to be faster they may enjoy compiler support, as today D complex
numbers have):
 http://factor-language.blogspot.com/2008/04/performance-improvements.html
 
 With AST macros and multiprecision numbers D may look closer to a Lisp ;-)
 
 Bye,
 bearophile



Bearophile

Where you going put this as a Enhancement requests into bugzilla or did 
you change your mind ?

Nick B
May 21 2008