Infinite Compression Explained

Because most of you don't read my blog,(i don't read random blogs as well) and have so much questions about what i'm doing with my programs, i'll write it here:
All of the programs(about 6 developed so far) despite wildly varying routines are targeted to generate large integers.
These integers are not files. Following transformations occurs:
encode
1.file is converted to large integer X(arbitrary length).
2.X multiplied by some scale factor e.g. 10e1000 to get a lower bound
2.(X+1)by some scale factor e.g. 10e1000 to get an uppper bound
3.a search is performed for finding numbers inside that range which are easy to represent via formula.
4.if number(s) found its saved to a file.
decode:
1.a formula is supplied with number(s) and filesize
2.the formula generates an integer/float, which is then divided by scale factor(e.g. 10e1000).
3.the first filesize bytes are then written to output.

the proces isn't perfected yet, because the formulas currently used in my programs either too slow to search or cuttoff at float precision(for non-integer parameters)
________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>80
/prog/ - Technical Support and Google Alternative

hmm, it could be used as separate module to call,system("convert.exe filename")

_______________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

1st program will use GMP and perform data conversions.
2nd will use MAPM to implement algorithms.

________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>82
system() considered harmful
>>83
please keep pointless posts like this confined to within your blog.

BROTIP: dont see his posts

I have a better idea:

Since pi is irrational, eventually you'll encounter any possible combination of numbers. So, just search for the numbers that correspond to your file and save the position where you found the numbers.

For unpacking you use a digit-extraction algorithm.

TAAAAAAAADAAAAAAAAAAAAAAAAAA

mpz_export crashes my program.
>>86 This is technically impossible:the probability of finding such strings >~10 bytes is astronomically low.

_______________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>86
What if the position needs a lot more space to store than the original data. There's no guarantee you'll find it at all ( you can have irrational numbers which exhibit very well defined patterns, yet don't belong in Q), and even if you found it, you may need more data to store the position than the original data you were compressing.

IHBT

>>87
>>88
MY PLANS FOR WORLD DOMINATION WON'T BE SPOILED BY BRATS LIKE YOU

>>87
This is technically impossible:the probability of finding such strings >~10 bytes is astronomically low.
I'd almost believe you actually know this in some traditional sense of the word ``know'' except that you cannot figure out how to use GMP's functions to calculate with rational exponents, which pretty much guarantees your knowledge of math is limited to middle-school pre-algebra.

Thankfully, everyone else here knows it, too.

>>88
I always hypothesized that the size of an index into an irrational number (or just any piece random data in general) to specify some content will be, on average, strictly bigger than the data itself (maybe some constant higher).

So, write each byte as three decimal digits, concatenating them after "0.". For example "hello" would be 0.104101108108111. Now you can store an arbitrary amount of information by just storing a number between 0 and 1. For example, you could make a mark at the correcponding place in an 1 inch ruler. This is truly INFINITE COMPRESSION; it's easy to implement, and very fast.

>>90 Rational exponents or w/e idiotic suggestion you propose are adding another layer of calculations:
see instead of float^float (with set precision), i'll have to
((float^long int)^long int)^long int)^long int)^long int)^long int)...../(float^long int)^long int)^long int)^long int)^long int)
 this process is proportional to the power size, and each steps loses precision.


_________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>93
i hope those are unsigned

>>94
Only unsigned long ints. its specified in the only function which takes 'arbitrary' powers.
— Function: void mpf_pow_ui (mpf_t rop, mpf_t op1, unsigned long int op2)
using numbers larger then ulong and in floating point, requires a "new process",( all when all normal libraries have anyfloat^anyfloat) which is typical of "Lunix mindset" of "If it doesn't work you aren't coding hard enough".
The result would be huge waste of CPU time and float precision.


__________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Comparision:
mp_expt(a, b, c)     <--MPI
 m_apm_pow(apmresult, decimal_places, apm_x, apm_y)  <--MAPM
(a process involvign spllitting the float power,finding amount of computations,performing a sequence of exponentiations and divisions, etc <--GMP

_________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Progress: Conversion utility done. Will be published shortly.

________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>93
Another layer of calculations? How, exactly, do you suppose floating point exponentiation works?

unsigned my anus

100 GET YES!!!! LOL

why mpz_out_str(output, 10, data); crashes and
mpz_out_str(output, 16, data); does not?


____________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Btw i'm developing new algorithm to work with GMP integer powers. It could work with some new ideas,without sacrificing precision.

_______________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Fuck that Shannon guy up the ass with a rolled-up copy of SICP.

________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

I've been thinking that I could make my algorithm compress files 20% more just by integrating it in with a matrix based encryption algorithm.

________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

ok, that didn't work.
my next plan is to assign an arbitrary number to every combination of bits, the receiving computer will be equipped with a list of every number and its corresponding value.
therefore, you can email someone a number (say, 102) and the receiver can look through they're data dictionary and find that 102 = original data (say, 11010101000100101011110101010000101011110101010100101010101101010100010010101111010101000010101111010101010010101010110101010001001010111101010100001010111101010101001010101011010101000100101011110101010000101011110101010100101010101010101000100101011110101010000101011110101010100101010101).
infinite compression here i come!!!

________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

I love you FV and all you trolls who go by the name of him.

<3

>>105 Thats preposterous. The index of every number is just the number itself.



_________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

I ponder if releasing the current code is worthwhile,since  its decoding algorithm isn't working yet( i haven't figured out why it corrupts files) and will take a long time to debug(not to mention dozens of bugs i fixed today).



______________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>107
no, "101001010010010101010100" takes up 24 bytes, but "10822996" only takes up 8.
once again you overlook the facts and talk without thinking


______________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>109
no data saved as binary values is way smaller than an int.

This thread needs stickied.
>>109 That was golden :)

>>110 Hes obviously trolling.
 Its just represented in different base on screen, the numbers are the same.



__________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>109
no data saved as binary values is way smaller than an int.>>112
uhu...sure

Appears to be working, no crashes so far. Corruption problem solved.
I'll have to remove debug code before publishing.

_______________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

This thread is so confusing. I don't know what's invisible and not invisible anymore.

You can check out the code here: It works, decodes, and searches(only in integer powers of course).
http://frozenvoid.blogspot.com/2009/06/integer-power-search.html

_________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Fixed corruption error when encoded in base36. New version(already in blog) is base10 exclusive.



_______________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

>>116
Of course!

new version^[1] coming tommorow.
I'm trying to optimize the code without sacrificing search space(which is scarce enough in int powers).


[1]with dynamic range extension inside the precision loop
______________________________
http://xs135.xs.to/xs135/09042/av922.jpg
orbis terrarum delenda est

Everyone, just GTFO. This thread is shit. Those who are not sageing this thread are shit. Please die.