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 

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