New exact notation for any size numbers

[Keiji]

Well, after reading that site about huge numbers, I came across this, which details Bowers' notation on angle brackets. I've adapted this notation slightly, so that a <1> b is a added to itself b times, or a*(b+1), and a <2> b is a multiplied by itself b times, etc. Using this notation I have written the numbers 1-60 as follows, using only the numbers 1, 2 and 3:

Code: Select all

0001 = 1
0002 = 2
0003 = 3
0004 = 2 <2> 1
0005 = 1 <1> (2 <1> 2)
0006 = 3 <1> 1
0007 = 1 <1> (3 <1> 2)
0008 = 2 <2> 2
0009 = 3 <2> 1
0010 = 2 <1> (2 <2> 1)
0011 = 1 <1> (1 <1> (3 <2> 1))
0012 = 3 <1> 3
0013 = 1 <1> (3 <1> 3)
0014 = 2 <1> (3 <1> 1)
0015 = 3 <1> (2 <2> 1)
0016 = 2 <2> 3
0017 = 1 <1> (2 <2> 3)
0018 = 2 <1> (2 <2> 2)
0019 = 1 <1> (2 <1> (2 <2> 2))
0020 = (2 <2> 1) <1> (2 <2> 1)
0021 = 3 <1> (2 <2> 2)
0022 = 2 <1> (2 <1> (2 <2> 1))
0023 = 1 <1> (2 <1> (2 <1> (2 <2> 1)))
0024 = (2 <2> 1) <1> (1 <1> (2 <1> 2))
0025 = (1 <1> (2 <1> 2)) <2> 1
0026 = 2 <1> (3 <1> 3)
0027 = 3 <3> 1
0028 = 1 <1> (3 <3> 1)
0029 = 1 <1> (1 <1> (3 <3> 1))
0030 = 3 <1> (3 <2> 1)
0031 = 1 <1> (3 <1> (3 <2> 1))
0032 = 2 <2> (2 <2> 1)
0033 = 3 <1> (2 <1> (2 <2> 1))
0034 = 2 <1> (2 <2> 3)
0035 = (1 <1> (2 <1> 2)) <1> (3 <1> 1)
0036 = (3 <1> 1) <2> 1
0037 = 1 <1> ((3 <1> 1) <2> 1)
0038 = 2 <1> (2 <1> (2 <2> 2))
0039 = 1 <1> (2 <1> (2 <1> (2 <2> 2)))
0040 = (2 <2> 2) <1> (2 <2> 1)
0041 = 1 <1> ((2 <2> 2) <1> (2 <2> 1))
0042 = (3 <1> 1) <1> (3 <1> 1)
0043 = 1 <1> ((3 <1> 1) <1> (3 <1> 1))
0044 = (2 <2> 1) <1> (2 <1> (2 <2> 1))
0045 = (3 <2> 1) <1> (2 <2> 1)
0046 = 2 <1> (2 <1> (2 <1> (2 <2> 1)))
0047 = 1 <1> (2 <1> (2 <1> (2 <1> (2 <2> 1))))
0048 = (2 <2> 3) <1> 2
0049 = (1 <1> (3 <1> 2)) <2> 1
0050 = (1 <1> (2 <1> 2)) <1> (3 <2> 1)
0051 = 1 <1> ((1 <1> (2 <1> 2)) <1> (3 <2> 1))
0052 = 2 <1> ((1 <1> (2 <1> 2)) <2> 1)
0053 = 1 <1> (2 <1> ((1 <1> (2 <1> 2)) <2> 1))
0054 = (2 <2> 2) <1> (3 <1> 1)
0055 = (1 <1> (2 <1> 2)) <1> (2 <1> (2 <2> 1))
0056 = 2 <1> (3 <3> 1)
0057 = 1 <1> (2 <1> (3 <3> 1))
0058 = 2 <1> (1 <1> (3 <3> 1))
0059 = 1 <1> (2 <1> (1 <1> (3 <3> 1)))
0060 = 3 <1> (3 <2> 1)

Notice that as the numbers go up, the length of the expression to represent it becomes more erratic. Therefore, you could have very large numbers represented by short strings. The reason I've only used the numbers 1, 2 and 3 is to show that even when reduced to only 3 different numbers it still never reaches more than 5 operators by the time we get to 60. Rewritten using the numbers 1-9, the list becomes:

Code: Select all

0001 = 1
0002 = 2
0003 = 3
0004 = 4
0005 = 5
0006 = 6
0007 = 7
0008 = 8
0009 = 9
0010 = 2 <1> 4
0011 = 1 <1> (1 <1> 9)
0012 = 3 <1> 3
0013 = 1 <1> (3 <1> 3)
0014 = 2 <1> 6
0015 = 3 <1> 4
0016 = 2 <2> 3
0017 = 1 <1> (2 <2> 3)
0018 = 2 <1> 8
0019 = 1 <1> (2 <1> 8)
0020 = 4 <1> 4
0021 = 3 <1> 8
0022 = 2 <1> (2 <1> 4)
0023 = 1 <1> (2 <1> (2 <1> 4))
0024 = 4 <1> 5
0025 = 5 <2> 1
0026 = 2 <1> (3 <1> 3)
0027 = 3 <3> 1
0028 = 1 <1> (3 <3> 1)
0029 = 1 <1> (1 <1> (3 <3> 1))
0030 = 3 <1> 9
0031 = 1 <1> (3 <1> 9)
0032 = 2 <2> 4
0033 = 3 <1> (2 <1> 4)
0034 = 2 <1> (2 <2> 3)
0035 = 5 <1> 6
0036 = 6 <2> 1
0037 = 1 <1> (6 <2> 1)
0038 = 2 <1> (2 <1> 8)
0039 = 1 <1> (2 <1> (2 <1> 8))
0040 = 8 <1> 4
0041 = 1 <1> (8 <1> 4)
0042 = 6 <1> 6
0043 = 1 <1> (6 <1> 6)
0044 = 4 <1> (2 <1> 4)
0045 = 9 <1> 4
0046 = 2 <1> (2 <1> (2 <1> 4))
0047 = 1 <1> (2 <1> (2 <1> (2 <1> 4)))
0048 = (2 <2> 3) <1> 2
0049 = 7 <2> 1
0050 = 5 <1> 9
0051 = 1 <1> (5 <1> 9)
0052 = 2 <1> (5 <2> 1)
0053 = 1 <1> (2 <1> (5 <2> 1))
0054 = 8 <1> 6
0055 = 5 <1> (2 <1> 4)
0056 = 2 <1> (3 <3> 1)
0057 = 1 <1> (2 <1> (3 <3> 1))
0058 = 2 <1> (1 <1> (3 <3> 1))
0059 = 1 <1> (2 <1> (1 <1> (3 <3> 1)))
0060 = 3 <1> 9

Now, the reason I've left it only using the numbers 1-9 is because this way it can be shortened even more. By removing all the angle brackets and spaces, leaving only numbers and brackets, we get the following:

Code: Select all

0001 = 1
0002 = 2
0003 = 3
0004 = 4
0005 = 5
0006 = 6
0007 = 7
0008 = 8
0009 = 9
0010 = 214
0011 = 11(119)
0012 = 313
0013 = 11(313)
0014 = 216
0015 = 314
0016 = 223
0017 = 11(223)
0018 = 218
0019 = 11(218)
0020 = 414
0021 = 318
0022 = 21(214)
0023 = 11(21(214))
0024 = 415
0025 = 521
0026 = 21(313)
0027 = 331
0028 = 11(331)
0029 = 11(11(331))
0030 = 319
0031 = 11(319)
0032 = 224
0033 = 31(214)
0034 = 21(223)
0035 = 516
0036 = 621
0037 = 11(621)
0038 = 21(218)
0039 = 11(21(218))
0040 = 814
0041 = 11(814)
0042 = 616
0043 = 11(616)
0044 = 41(214)
0045 = 914
0046 = 21(21(214))
0047 = 11(21(21(214)))
0048 = (223)12
0049 = 721
0050 = 519
0051 = 11(519)
0052 = 21(521)
0053 = 11(21(521))
0054 = 816
0055 = 51(214)
0056 = 21(331)
0057 = 11(21(331))
0058 = 21(11(331))
0059 = 11(21(11(331)))
0060 = 319

This is very space-saving to store in a computer, as since there are only 11 different symbols it can be stored with two characters per byte. With very large numbers this would be useful. Consider one googolplex, 10^(10^100). A computer currently would be unable to store this number. However, if we convert it to this notation, one google, 10^100 is ten multiplied by itself 99 times. 99 is too large - so we reduce it to 9 added to itself 10 times. 10 is also too large, so we reduce it to 2 added to itself 4 times.

Thus, we get:
10 = 2 <1> 4
99 = 9 <1> (2 <1> 4)
10^100 = (2 <1> 4) <2> (9 <1> (2 <1> 4))
10^(10^100) = (2 <1> 4) <2> ((2 <1> 4) <2> (9 <1> (2 <1> 4)))

Shortening this reduces it to "(214)2((214)2(91(214)))", which being only 23 characters long can be stored in only 12 bytes of data.

The general rule for the string of characters is "In each group of numbers, where a group is everything between one "(" and its respective ")" exclusively, only 3 numbers or groups are allowed, no more and no less."

Given this rule I will now generate a completely random valid string of characters to prove that it can be expanded to angle-bracket notation:
"23((628)7(5(187)(95(751))))" - 27 characters, occupying 14 bytes
expands to 2 <3> ((6 <2> 8) <7> (5 <(1 <8> 7)> (9 <5> (7 <5> 1))))

This must be a huge number, as (7 <5> 1), or seven hyper-5ed to itself 1 time, is seven hyper-4ed to itself seven times, which expands to:

Code: Select all

7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7))))))) ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7))))))) ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7))))))) ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7))))))) ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7))))))) ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7))))))) ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ (7 ^ 7)))))))

As you can see, this is very obviously one of the hugest numbers ever imagined. Then we have 9 <5> n, 9 hyper-5ed to itself n times, where n is the very long expression composing of sevens written above, which must be zillions of times larger itself.

A note to be said here is that if, in (a <b> c), a is 1, then that expression can simply be replaced by 1. The only exception is addition: one added to itself ten times is eleven, but one multiplied, exponented or even hyper-n-ed to itself ten times is still 1. Thus we can replace the <(1 <8> 7)> in the previous expression by <1>.

Well, that was yet another very long post from me. What does everybody think about this notation?

[Aale de Winkel]

well as to a comment, rather a nasty system of getting used to for this 'decimal' guy, but if it work it work. personally I do think I would explain your googoplex to an alien visitor as:
10 = (2[sup]3[/sup] + 2)
100 = (2[sup]3[/sup] + 2)[sup]2[/sup]
g = 10[sup]100[/sup]
G = 10[sup]g[/sup]
(helas the superscript tag failed to understand the intended, so I had to write it out this way)

Or to put it otherwise I haven't the faintest what prompted the nasty notation you propose, it is reasonable to expect any alien, me, fred, emily or any outerspacian, understand prime numbers. The regular system based on prime numbers has the same thing your system has, that rather huge numbers re simply to express, while smaller ones need rather huge strings.

In case any new number system should be invented at least base it on the prime numbers.

BTW: this has really nothing to do with the 4th dimension!
(just stating my opinion, but as said I'm too used to the regular system to see the benefits of yours)

[jinydu]

I think what bobxp implied is that the method you propose (repeated exponentiation) becomes unwieldy when the numbers become sufficiently large.

Googolplex is an incredibly huge number by everyday standards. However, infinity is (obviously) beyond any finite quantity, and that includes googolplex. In fact, I can continue that sequence by defining:

Googolplexplex = 10^Googolplex = 10^(10^(10^100))
Googolplexplexplex = 10^Googolplexplex = 10^(10^(10^(10^100)))
Googolplexplexplexplex = 10^Googolplexplexplex = 10^(10^(10^(10^(10^100))))

Googolplexplexplexplex is tremendously huge, making the vaunted Googolplex seem insignificant in comparison. Still, even this number is smaller than "almost all" natural numbers (since there are a finite number of natural numbers below it and an infinite number above it). We could continue on in this sequence, but it is not difficult to see that the notation would eventually become unwieldy. In fact, that are numbers so incredibly huge that your computer's hard drive doesn't contain enough memory to save it using the notation above. Furthermore, almost all natural numbers are that large!

Using the different notation described at the website, it is practical to express (some) such numbers. However, even bobxp's notation will admittedly become unwieldy for some numbers far larger still. At that point, we could just develop another notation.

[Keiji]

The point is that it enables COMPUTERS to easily store huge numbers. If you use scientific notation you will almost always lose accuracy, but with this method huge numbers can be easily represented without losing accuracy. :wink:

[pat]

with this method huge numbers can be easily represented without losing accuracy. :wink:

But, what good is a number unless you can do something with it. I mean... how fun would it be to try to program something to know that:
914 + 3 = 11(21(21(214))) + 1 = (223)12

[Keiji]

Well, to evaluate expressions, the computer (or person) would do the following:

1. Decompress the numbers.
2. Combine numbers and add parts if necessary.
3. Simplify expression if possible.
4. Compress numbers to get result.

Example: Evaluate 616 + 7.

1. Decompress numbers: 6 <1> 6 + 7
2. Combine numbers: 7 <1> 6
3. Simplify: 7 <2> 1
4. Compress numbers: 721

[pat]

Well, to evaluate expressions, the computer (or person) would do the following:

Sure... and so these numbers are fine for storage, but not particularly for calculation.

[Keiji]

Actually they are fine for calculations. Again this would be much faster with a computer program than a human, but it is actually simpler than you might think:

in Step 2, it would undergo a series of operations by reasoning, and if all fail, just add bits to the expression.
in Step 3, it would replace patterns, starting with the innermost group and working outwards.

[PWrong]

There's a slight mistake near the end of your first post.

This must be a huge number, as (7 <5> 1), or seven hyper-5ed to itself 1 time, is seven hyper-4ed to itself seven times, which expands to

Actually, 7 <5> 1 =7

I imagine you meant to say 7 <5> 2, which is seven hyper-4ed to itself, or 7 <4> 7.

7 <5> 3 would be 7 <4> (7 <4> 7)

Even your angle bracket notation isn't a generalisation of huge numbers. For instance, what about something as ridiculous as

(10 <10> 10) <(10 <10>10)> (10 <10> 10)

We could make a new notation for this:

10>>2 = (10 <10> 10) <(10 <10>10)> (10 <10> 10)
10>>3 = (10>>2) <(10>>2)> (10>>2)
10>>4 = (10>>3) <(10>>3)> (10>>3)

It's pretty obvious that this notation isn't the best we can do either.

In case you're not convinced:

10@2 = 10>>10
10@3 = 10>>10>>10
10@4 = 10>>10>>10>>10

How about one more new notation for good luck, then I'll generalise my notations into a notation.

10$2=10@10
10$3=10@10@10
10$4=10@10@10@10

Ok, now that we're in a repeating pattern, lets say the symbols >>, @ and $ are represented by {2}, {3}, and {4} respectively, and we can go onto {5} and {6} and so on.

so a really huge number would be 7{5}2

Look familiar? This number uses just as many symbols as 7 <5> 2, but it's unimaginably bigger than this unimaginably big number.

And since the notations are so similar, there's no reason we can't do the same thing again. :twisted:

It's pretty clear that it's impossible to generalise notation systems like this, because when we get a general notation, we can just generalise it again to make it bigger. You're just trying to count to infinity. I would imagine computers already use a system like this whenever they have to use such huge numbers. The problem is it doesn't make them any faster. Just because we can compress a number like 7{5}2, it doesn't mean we can find out whether 7{5}2 + 1 is a prime number.

I think Godel proved something like this.

Edit by BobXP: Fixed your quote.

[Keiji]

I've adapted this notation slightly, so that a <1> b is a added to itself b times, or a*(b+1), and a <2> b is a multiplied by itself b times, etc.

That should explain your incorrectly thinking I had made a mistake.

I've also an addition to make: Since the notation only uses 11 characters and there's room for 16, I'll add -, to make numbers that are zero or negative, and /, which can make fractions.

e.g: -36 = -621, 0 = 1-1, 1/10 = 1/214.

[Lakimar]

Notice that as the numbers go up, the length of the expression to represent it becomes more erratic. Therefore, you could have very large numbers represented by short strings.

This is very space-saving to store in a computer, as since there are only 11 different symbols it can be stored with two characters per byte. With very large numbers this would be useful.

The point is that it enables COMPUTERS to easily store huge numbers. If you use scientific notation you will almost always lose accuracy, but with this method huge numbers can be easily represented without losing accuracy.

Your notation does let the googleplex to be represented by less bits than scientific notation, but it does not let all huge numbers to be easily represented withouth losing accuracy.

If you consider all strings with a length that is less than or equal to L tokens, where each token can be one of X data, the number of strings under consideration is no more than (X+1)^L. Thus a string of length L can represent no more than (X+1)^L numbers. To represent every integer from 1 to googleplex requires 10^google possible strings. With 9 symbols, to represent every integer from 1 to googleplex requires strings with lengths of google, the same needed in scientific notation.

[Geosphere]

What about higher base numeric systems?

[Lakimar]

By using higher base number systems, you increase the number of numbers geometricaly. This is a lot, but it is not near the size of googlplex, which transcends the geometric(because it uses a google multiplications).

When you multiply the number of the base by N, you multiply the number of numbers representable by no more than (N+1)^L, which means that numbers as large as googleplex are still out of reach (remember that the googleplex results from many multiplications)(Yes you can represent googlpex using few symbols accurately, but you can not do this with every integer from 1 to googleplex). The base needed to represent googleplex numbers accurately with short strings would end up being astronomical. Each symbol could still be represented in binary, and my argument in my last post would still apply. Astronomical number sometimes will be easy to represent, but to represent any astronomical number, there is not much better than listing the digits. Only some numbers will have patterns in them that will allow much compression. It doesn't matter whether you store a datum in binary or decimal or in any other base; it still uses about the same number of bits to store.

[Keiji]

The only place where my notation is hopeless is PRIME NUMBERS. The only way to represent these numbers (if they're larger than 9) is by using 11(n), where n is the string of characters for the number immediately before the number.

My notation works extremely well with anything that is a multiple of other short (when written in my notation) numbers. And even better when it is an exponent of said numbers, or something raised to the power of said numbers. And even better still when a hyper-n operation can be used, where as n increases, the effectiveness of my notation against decimal or scientific notation.

[Lakimar]

The only place where my notation is hopeless is PRIME NUMBERS.

If writing 11(n) is hopeless to write, isn't n hopeless to write too (after all it is a difference of just a few characters)?

Are prime numbers really hopeless to write? Aren't some prime numbers right after a very simple number? 257 is a prime number, but it is right after 256, a number that is equal to 233, or 2^2^2^2.

Your notation does allow some large numbers to be expressed more concisely than scientific notation, but it does not allow every number to be expressed more concisely.

My notation works extremely well with anything that is a multiple of other short (when written in my notation) numbers. And even better when it is an exponent of said numbers, or something raised to the power of said numbers. And even better still when a hyper-n operation can be used, where as n increases, the effectiveness of my notation against decimal or scientific notation.

How well does it work the rest of the time? On average, can your notation express numbers more concisely than scientific notation without losing accuracy?

In decimal (by this I mean when you simply right out a number's decimal digits), every possible string of length less than or equal to L represents a number less than 10^L (with no integers between 1 and 10^L left out).

In your notation, every possible string of length less than or equal to L represents a number less than a number much larger than 10^L (with many numbers between 1 and this number left out).

The only way to express every number between 1 and a googleplex is to have a googleplex different expressions. You would need a binary string over a google digits long to make a googleplex possibilities.

Your notation can easily express the number 1, and the number googleplex, and maybe 10^1000000 numbers between, but the other say 0.9999999999999999999*googleplex numbers bear less simple expressions.

[PWrong]

It's a good idea, but there's not much point in using higher base systems in a computer. Imagine you have a base googleplex numeric system, rather than base 10 or base 2. Every number from 1 to googleplex has to be a different symbol. But a symbol is just a pattern of black on white. There's only so many patterns of black on white there can be, and they eventually have to be reduced to pixels. The pixels can then be converted to binary, so there's no loss of information. Colour doesn't work either, because you can't detect tiny changes in frequency efficiently.

Sorry about that mistake thing Bob. But the rest of my post still applies. There's always a bigger notation, possibly some that can be just as accurate and concise as others.

Also, I don't think you can solve the problem with prime numbers just by adding one to it. If you have a very big number that might be prime, then you have to find out whether it's prime or not before you can express it in the shortest notation possible. No computer has a chance of proving that a number like googleplex + 3 is prime.

Maybe the prime numbers are distributed specifically to stop us from making huge notations. Which just makes it more of a challenge.

[Lakimar]

I wasn't saying we should make a base google number system, I was saying that it is impossible to represent a googleplex numbers. If you can't represent a googleplex numbers, you can't represent every number between 1 and googleplex, and if you can't do that, you can't represent all large numbers accurately.