My name is John,
and I'm from Sweden (so pardon my English).
I'm a 16 year old student, with the strange interest of inventing.
To continue the research on my latest invention, which is actually a
program to minimize the size of images to insignificance, without
any effects on the quality. Anyone who knows anything about computers
must realize that it will draw down disk space drastic, when the
images are what make programs and games so heavy.
Enough of that and to
the question, [level: secondary] (i guess). I
have encountered problem with the lack of memory every calculator
seems to have. No calculator, on or off the computer, I've found
has the amount of memory or writing space to calculate the sums I want
to solve. The sums are in great importance for my continued progress.
The sums are following:
167772161310270, 16777215995328, 16777215786432 and 16777215480000
I have earlier searched for patterns in small sums in order to
calculate the great, but without finding any constant patterns
obvious enough for me to notice. My best guessing is that there
aren't any, and the only way to solve the sums is to use some sort
of highly advanced master calculating tool, used by the pro
mathematicians or something like that.
I would appreciate all help I can get.
John,
If you have access to
a unix or linux system, you can make a file called fbb containing
the following two lines:
16777215^480000
quit
then type
bc fbb > obb &
After 15 minutes or longer you will have the result in the file obb (of size 3569863).
As you can see, big exponents yield numbers with many digits. For instance,
16777215480000 > (107)480000 = 103360000,
a number with more than 3 million digits.
It is easy to compute the last few digits using modular arithmetics and "repeated squaring'':
16777215480000 mod 1000000000 = 212890625,
so these are the correct last nine digits. However, to compute the whole result, you need memory space to store your answer and all the intermediate calculations, and this is a lot of reading and writing on memory, not counting computations.
Claude