not a homework question

[Noob]

(Assuming, of course, that "^" denotes exponentiation.)
Yes.

u5 is substantially larger than one googol (10^100); it has 183231
digits compared to just 101 digits for one googol.

u6 is substantially larger than one goolplex; it has 10^183231 digits,
compared to just 10^100+1 digits for one googolplex.

u7, u8, and u9 are Really Really Big (but still tiny compared to the
largest numbers that have actually been used in mathematics).

Are you referring to Graham's number?
World Champion largest number! ^_^

http://en.wikipedia.org/wiki/Graham's_number

 

[Keith Thompson]

Keith Thompson wrote: [...]

u7, u8, and u9 are Really Really Big (but still tiny compared to the
largest numbers that have actually been used in mathematics).

Are you referring to Graham's number?
World Champion largest number! ^_^

http://en.wikipedia.org/wiki/Graham's_number

Yup, that's the one I had in mind.

Graham's number is an upper bound on a number of dimensions for an
n-dimensional hypercube with certain characteristics. Graham and
Rothschild's paper provided a lower bound of 6; Martin Gardner called
this "perhaps the worst smallest-upper-bound ever discovered". (More
recently, the lower bound has been shown to be at least 11.)

So if you need to work with numbers that are too big to represent in
any arithmetic type in C, you can either come up with an alternate
representation (it wouldn't be hard to write C code that could
manipulate Knuth's up-arrow notation, used to describe Graham's
number), or improve your algorithm so you can use smaller numbers.
(There, it's topical!)

But consider this ...

(drum roll please)

GRAHAM'S NUMBER PLUS ONE!!!!

I win.

 

[Coos Haak]

Op Wed, 12 Mar 2008 00:33:53 -0500 schreef CBFalconer:

Since 2 xor 1 is identically zero, that value suffices.

Since when? I get 3.

x = 0;

The value of the expression is 1.

 

[Antoninus Twink]

Op Wed, 12 Mar 2008 00:33:53 -0500 schreef CBFalconer:


Since when? I get 3.
The value of the expression is 1.

CBF is a moaning old fart with no discernible technical knowledge or
skill. If you spend your time correcting his technical errors, you'll
waste a huge amount of time for no reward.

 

[Three Headed Monkey]

(I know your post was written tongue-in-cheek, but it's an interesting

^^^^^^^^^^^^^^^
What does that mean?

problem nonetheless.)

Let u1 = 1 and u(n) = n ^ u(n-1)

Assume base 10.

u1 = 1
u2 = 2
u3 = 9
u4 = 262144
u5 = a number with 183231 digits
u6 = a number with (roughly) 10^183231 digits

u9 might be larger than one googolplex.

So some people say it's to big for C, other people say bigger numbers
have been used on computers.

Can problem be expressed in "spinoza" programming language?
(Author says it can handle unlimited numbers and unlimited strings)

It probably beyond my imagination, but when printing this number
on screen, how much time can I expect? If printed on paper, how many
sheets will it needs?

Another idea, if I rearrange above expression so it calculate
n-th digit of result, like

int n_th_digit(int n);

can this be done so formula is not to big for C language?

 

[Doug Miller]

It probably beyond my imagination,
Obviously.

but when printing this number
on screen, how much time can I expect?

Considerably more than the age of the universe.

If printed on paper, how many sheets will it needs?

There is not enough paper in existence to print this number. There has not
been enough paper manufactured since paper was invented to print this number.
There will not be enough paper manufactured between now and the end of time to
print this number. What part of "there are more digits in this number than
there are atoms in the universe" are you having trouble understanding?

 

[Ben Bacarisse]

^^^^^^^^^^^^^^^
What does that mean?

It means "not seriously" or "as a joke".

So some people say it's to big for C, other people say bigger numbers
have been used on computers.

You can handle any number provided you have a representation for it
that fits in the computer and suits the problem at hand. I can print
a half of pi with absolute accuracy if I am allowed to print "pi/2".
I can write a lightening fast program to print e to as many digits as
you like if I can choose the number system:

#include <stdio.h>

int main(void)
{
putchar('1');
putchar('.');
while (1) putchar('1');
return 0;
}

(the n'th fractional digit has value 1/n!.)

So you C program can express it with a string: "9^8^7^6^5^4^3^2^1"
(exponentiation usually associates to the right).

All this is just to point out that you have not stated the problem.
If the problem is to print, from high-order to low-order the decimal
digits of this number then you are out of luck.

Can problem be expressed in "spinoza" programming language?

It does not exist yet. Look up some other posts by the author a
decide for yourself if you think it will suit you needs when it is
done.

There are other symbolic manipulation languages available now, but I
doubt they can do very much with this expression (Mathematica is the
most famous).

(Author says it can handle unlimited numbers and unlimited strings)

So can C, but unlimited means there is no "arbitrary" limit. If all
the memory chips in all the world were pooled together, for this one C
program there would still be a limit in practice.

Another idea, if I rearrange above expression so it calculate
n-th digit of result, like

int n_th_digit(int n);

can this be done so formula is not to big for C language?

That a very good way to be thinking, but (a) I can't help with any
ideas and (b) you still can't print it -- only little bits of it.

 

[Hans Schneider]

Doug Miller schreibt:

Considerably more than the age of the universe.


There is not enough paper in existence to print this number. There has not
been enough paper manufactured since paper was invented to print this
number. There will not be enough paper manufactured between now and the
end of time to print this number. What part of "there are more digits in
this number than there are atoms in the universe" are you having trouble
understanding?

You should always save paper and print on both sides.

 

[Wolfgang Riedel]

Three Headed Monkey said:




#include <stdio.h>

int main(void)
{
printf("%d\n",
9^(8^(7^(6^(5^(4^(3^(2^1))))))));
return 0;
}

your system has a 255624-bit integer type?

 

[Richard Heathfield]

Wolfgang Riedel said:

your system has a 255624-bit integer type?

Well, not unless I use my bignum library - but it isn't necessary for this
program. (Try it!)

 

[user923005]

                                ^^^^^^^^^^^^^^^
What does that mean?
http://en.wikipedia.org/wiki/Tongue-in-cheek






So some people say it's to big for C, other people say bigger numbers
have been used on computers.

Can problem be expressed in "spinoza" programming language?
(Author says it can handle unlimited numbers and unlimited strings)

A combination of spinoza and pasm would be ideal. But only Herbert
Schildt could code something as complicated as that, with the
assistance of Scott Nudds.

It probably beyond my imagination, but when printing this number
on screen, how much time can I expect? If printed on paper, how many
sheets will it needs?

Grind up the entire universe and turn it into paper. It's not nearly
enough even to get started.

Another idea, if I rearrange above expression so it calculate
n-th digit of result, like

int n_th_digit(int n);

can this be done so formula is not to big for C language?

The formula is small. It's the answer that's the problem.

 

[santosh]

Grind up the entire universe and turn it into paper. It's not nearly
enough even to get started.

<snip>

What if you could employ compression on the sequence on the fly?

 

[Sjouke Burry]

<snip>

What if you could employ compression on the sequence on the fly?

You can compress the output sequence as
9^(8^(7^(6^(5^(4^(3^(2^1)))))))

 

[CBFalconer]

Wolfgang Riedel said:
.... snip ...


Well, not unless I use my bignum library - but it isn't necessary
for this program. (Try it!)

[1] c:\c\junk>cat junk.c
#include <stdio.h>

int main(void) {
printf("%d\n", 9^(8^(7^(6^(5^(4^(3^(2^1))))))));
return 0;
}

[1] c:\c\junk>cc junk.c

[1] c:\c\junk>a
1

 

[user923005]

<snip>

What if you could employ compression on the sequence on the fly?

Sjouke Burry took my snappy answer.

But as far as digits are concerned, I have seen an estimate that there
are about 10^87 elementary particles in the observable universe.
Supposing it is a factor of 1000 too low, then there would be 10^90
elementary particles. If we could encode a 10^10 digits on each
elementary particle and we had 10^90 of them, that would only be a
googol of digits (10^100) which is utterly dwarfed by this number
(which resembles in its construction Archimedian Cycles).

 

[user923005]

You can compress the output sequence as
9^(8^(7^(6^(5^(4^(3^(2^1)))))))

Which lead one man to exclaim:
"I couldn't see the forest for the threes!"