C++ code will not compile

[Blake Huff]

Jonathan:

That was an excellent down and dirty lesson on how to anticipate the  
size of an answer (I wish someone had taught me that when I first  
started in with computers), but I think there's a small mistake.  The  
math in question is: (4294967295 ^ 126976), not (126976 ^  
4294967295).   The code snippet he presented to us compiles and runs  
fine for me, on my G4, producing a 1223155 digit number.  Quite  
reasonable!

Any other thoughts an why Greg's code would segfault?

Blake


On Mar 6, 2006, at 3:07 AM, Jonathan A. Zylstra wrote:

> Greg Davis wrote:
>
>> Blake,
>>
>> Thanks for the reply, the code compiles now but it segfaults after  
>> a few
>> seconds.
>>
>> I guess maybe I'll have to buy a new computer unless somebody here  
>> has a
>> better idea. :P
>>
>>
> Well, I recommend a computer with at least. ~ 8.5 GB of memory that  
> can be devoted exclusively to that program.
> It segfaults because you have run out of memory ... here's why:
>
> No. of decimal digits of your number:
> (126976 ^ 4294967295) = (10 ^ x)
> Log[base 10] (126976 ^ 4294967295) = Log[Base 10](10 ^ x)
> 4294967295 * Log [b10] (126976) = x * Log[b10] (10)
> 21920317535 = x, number of decimal digits [yes, nearly 22 billion ]
>
> to convert to base 2, multiply by (log[b10] (10) / log[b10] (2) )  
> ~=  3.3219
>
> Which gives you [about]  72817718668 bits , which is about 8.5 GB.
> Plus there is some overhead for the mpz_t class ... keeping track  
> of all that memory!
>
> It looks small from an algebraic standpoint on paper ... but that's  
> a huge number.
> Try some interesting numbers like (2^3021377)-1 ... only about  
> 368kb of memory. [see www.mersenne.org for that number ...]
>
> Jonathan A. Zylstra
>
>> Thanks for any further suggestions.
>>
>>
>>
>> Blake Huff wrote:
>>
>>
>>> Gregg:
>>>
>>> I assume it's because 2^32 = 4294967296, which is too large as  
>>> the  range of an unsigned long integer should be 0-4294967295.   
>>> If it  compiled correctly, it would have to be done on a 64 bit  
>>> system (or  something larger than 32 bits).
>>>
>>> Blake
>>>
>>>
>>> P.S. To get the same effect, try this:
>>>
>>> mpz_set_ui(x, 4294967295);
>>> mpz_add_ui(x, x, 1);
>>>
>>> It might take an extra computational cycle or two, but that's why  
>>> we  make ghz processors, no?
>>>
>>>
>>>
>>>
>>>
>>> On Mar 5, 2006, at 11:47 AM, Greg Davis wrote:
>>>
>>>
>>>
>>>> Hi guys,
>>>>
>>>> I got this code from some forums:
>>>>
>>>> #include <iostream>
>>>> using namespace std;
>>>> #include <gmp.h>
>>>>
>>>> int main()
>>>> {
>>>> mpz_t x;
>>>> unsigned int y=126976;
>>>> mpz_init(x);
>>>> mpz_set_ui(x,4294967296);
>>>> cout << "\nx: " <<x << endl;
>>>> cout << "\ny: " <<y << endl ;
>>>> mpz_pow_ui(x, x, y);
>>>> cout << "x^y is  " << x << endl;
>>>> mpz_clear(x);
>>>> }
>>>>
>>>> but when I try to compile it I get:
>>>>
>>>> bignum.cpp:11: error: integer constant is too large for "long" type
>>>>
>>>> Can anyone help me figure out why it does this? It seems to  
>>>> compile  fine
>>>> on his computer.
>>>>
>>>> Thanks for any help.
>>>> _______________________________________________
>>>> gmp-discuss mailing list
>>>> gmp-discuss at swox.com
>>>> https://gmplib.org/mailman/listinfo/gmp-discuss
>>>>
>>>>
>>> Blake Huff
>>> stangmechanic at gmail.com
>>>
>>>
>>>
>>> _______________________________________________
>>> gmp-discuss mailing list
>>> gmp-discuss at swox.com
>>> https://gmplib.org/mailman/listinfo/gmp-discuss
>>>
>>>
>>>
>>
>> _______________________________________________
>> gmp-discuss mailing list
>> gmp-discuss at swox.com
>> https://gmplib.org/mailman/listinfo/gmp-discuss
>>
>>
>

Blake Huff
stangmechanic at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gmplib.org/list-archives/gmp-discuss/attachments/20060307/7161b060/attachment.html