I made a simple modification to my code to test the method plus multiplication, just out of curiosity because the result of this example is still not “smaller” than the initial number in this case. Follows:

s = 2855754796332;
w = Flatten@
   ParallelTable[{If[Abs[q*m^n - s] < 1000000, {q, m, n}, {}], 
     If[Abs[q*m^n - s] < 1000000, (-1)*(q*m^n - s), {}]}, {m, 2, 
     3000}, {n, 2, 10}, {q, 1, 10000}] // AbsoluteTiming

s = 193791;
w = Flatten@
   ParallelTable[{If[Abs[q*m^n - s] < 100, {q, m, n}, {}], 
     If[Abs[q*m^n - s] < 100, (-1)*(q*m^n - s), {}]}, {m, 2, 
     1000}, {n, 2, 15}, {q, 1, 1000}] // AbsoluteTiming

Arriving at one of the results:

6231*771^3 + 757*2^8 - 1

This was another attempt to represent the number in a smaller way, but I believe that some numbers are shorter if they are represented extensively and others in the form of operations, depends on the initial number. It may be that someone knows another code that creates an even smaller form of representation of large numbers....

1300^4 - 51^5 - 3^11 - 6^4 + 5^2 + 1

output=2855754796332

So here, above, the output result is reached if the input is:

1300^4 - 51^5 - 3^11 - 6^4 + 5^2 + 1

?

Isn't that the same amount of bits anyway though? It takes as many in to get the output out, in the end of the story?

See above.

Also, here is some further tests to show slow increase in desired result:

9^8=43,046,721

9^8.1=53,624,632

9^8.2=66,801,863

9^8.3=83.217.148

9^8.4=103,666,176

9^8.5=129.140.163

8^9=134,217.728

9^9=387,420,489

And maybe we can do this to parts of the big number:

947 282280 100563 482238 53483 4535834 34753322

?

Do you have a reason to believe there is a "small" representation of 94728228010056348223853483453583434753322 ? It strikes me as plausible that there may be no such.

By the way, 36^^whatever parses the alphanumerics in whatever as a number in base 36.

36^^3973g9f3igvh4a6e3o60cz93y96 == 94728228010056348223853483453583434753322

but 37^^xxx is nothing because mm stops at 36 (you'd have to find an algorithm in a book that allows computing such a thing on a PC with limited widths)

x=94728228010056348223853483453583434753322;
x>>filename; (*Put*)
y<<filename;

A PC already stored numbers efficiently. If you assign x a value, you can later use the label x instead of the value of x without worry about how many bytes it is or how that is stored in memory. Mathematica has MANY many ways to show the value of bytes in memory or to use labels instead of them.

"Maybe some sort of exponential greedy-wise" perhaps you have already read the algorithm and are waiting for others to respond knowing it for some reason? Yes there are many algorithms involving exponent number representation - the best are patented and on the Intel chip i assume.

Really the best generic compression is (g)zip statistically you aren't going to beat it for the average case. Mathematica has a compression module(s) you can use.

Sparse Data is what they call it when arrays store (large) values in an incomplete array as if in a complete array.

But for your problem, you wish to add 1 to a number stored in bytes. You need only represent it algebraically as

y:=x+1

If you wish to see the binary storage for some reason:

2^^y

You can use BaseForm and NumberForm etc to add 0's padding if you want the right widths - i'm sure you can find an existing .nb working with bits.

As far as how Mathematica performs x+1 - it uses Intel Math for speed when it can, it uses algorithms otherwise. Mathematica uses arbitrary precision numbers unless you tell it not to. There are free (GPL) libraries to find which do this showing one how it is done, and some books show these algorithms. They are not particularly interesting in that there isn't much to learn and once done and coded - it does not need attention.

If you open bash(1) you can use hexdump(1) to see machine storage in text form.

Mathematica does have some binary and bit tool libraries - which include reading and writing bytes at a time to a file.

There are MANY compression algorithms (they alter the representation of bits to an smaller alternate form: but are not set up to Add[] after doing so, not in general). The best is zip, statistically, for the average case. Some go to great effort to use an algorithm like bzip (tuned to work well with text but works poorly with images). ((Mpeg is for images but includes many things other than compression)). gzip (pkzip) is FAST and the best for the average case: it's "un-beatable" if you don't want to juggle a hundred compression programs while doing your every day file explorer work. It may not compress the best in all cases but it does it statistically good job so FAST the other algorithms need not be considered - if you need to pick one; the other algorithms increase in waiting time outweigh their benefit.