Daniel Dudley wrote: > > Hi Joachim, > > I'm getting an exception in ECLiPSe when using big numbers: > > 2^(1000036). => successful result > 2^(10000036). => > > Application Error > The exception unknown software exception (0xc00000fd) > occurred in the application at location 0x00cb4cd3. I get different results on different machines. The limitation is probably due to the (hardware) stack size, which often has a small default, and I don't know how to change it on Windows at runtime. The Gmp library which handles the bignums allocates temporary values on that stack, using alloca(). Note that the limit seems to be hit earliest when you try to print the numbers (you get a bit further when you run the query with an anonymous result variable which doesn't get printed). Also, the power operation causes the overflow earlier than the shift. > > I get the same exception when using <<(2,10000036,Result), > which (surprisingly for bit manipulation) is an extremely > slow operation (ie. with regard to a power of 1000036). As long as it works, it seems to scale nicely: [eclipse 8]: time(_ is 2<<1000036). Success, time = 0.0 yes. [eclipse 9]: time(_ is 2<<10000036). Success, time = 0.0199999999999996 yes. [eclipse 10]: time(_ is 2<<100000036). Success, time = 0.199999999999999 yes. [eclipse 11]: time(_ is 2<<1000000036). Success, time = 2.27 yes. (this is on Linux) > The exception occurs immediately upon running the query. > > There's a total of 256 Mb of RAM available, which should be > sufficient to cater for the result of the second expression, > even with other applications running concurrently. > > Actually, raising 2 to the power of 10000036 is peanuts > compared to what I have in mind, so reliable processing of > really big integers is essential to my research. You should probably consider a different approach. Abusing bignums as bitmaps is not going to be very efficient. Since there is no destructive assignment in Prolog, every operation will create a new bignum, which involves allocating and filling megabytes of memory. As for the bignum implementation itself, Eclipse relies on the Gmp multiprecision library which is hard to beat in terms of reliability and performance... > > Best regards, > Daniel -- Joachim Schimpf / phone: +44 20 7594 8187 IC-Parc, Imperial College / mailto:J.Schimpf@ic.ac.uk London SW7 2AZ, UK / http://www.icparc.ic.ac.uk/eclipseReceived on Tue May 22 11:51:21 2001
This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:08:06 PM GMT GMT