Crypto Compression Concept Worth Big Money - I Did It!

[balanghai]

Encoding all possible one to three byte files using only 62 printable characters gives a total of 426 resulting index values, compared to the 242234 that would be required for full uniqueness.
Of those 426 values, only 26 were uniquely mapped to by a single string.
Lowest used index was 76, highest was 790. (These indexes all start with 1 = the 3 of 3.14).
Most popular index was 517, which was mapped to by 18891 different strings.

Is it possible to make a formula to just make a solution set instead of imaging or presenting the binaries?

Instead of file a= 101010001010101010 = 1 * forumula * metadata * index * convert to binary * encode binary ?

[murraypaul]

However you approach it, it is simply impossible to design a lossless compression algorithm that reduces the size of all possible input files given to it.

[B(asic)Miner]

0 = no change in Hunt Value. 1s = +1 to Hunt Value.   However, how we search for our Hunt Value changes here:   We have to double confirm every Hunt Value against the Index at that location being even (0) or odd (+1).  We can only accept a Hunt Value which double confirms the bit we are encoding.  For example:   Here is  our data to be encoded:

0010 0001  (space added for readability only)

Our first Hunt Value is 4, but we can't stop on just any 4 now, it must be an EVEN 4!  Here goes:   The first 4 in Pi is at index 2 (if you are counting indexes 1-50 and not 0-49 like coders do, so let's please just use 1-50 to keep this easy to read (no offsetting for now))  That means the first 4 IS a 4 AND it's EVEN.  

Let's continue:  the 2nd 0 in our encoding byte example ....  the next four we find in Pi is at Index 19 (odd) but we are looking for an EVEN 4 because our encoding bit is still 0.   Our third 4 is at Index 23 (no good still) so we keep going ....  ah, at Index 36, we have our 2nd EVEN 4!   So now our 2nd bit is encoded ....   Next we are encoding (our third encoding bit) a 1, so now we need to find the next ODD 5 (it increments+1 and because it's a 1, its ODD too) ...  so our first 5 from that location is at Index 48 (an even, so its no good) ... but at Index 51, we have our first ODD 5, we just encoded that bit.  

This process continues accordingly.  This spreads out the hops a great distance, ensuring the path taken is more unique, but at a cost of having to use way more of the Index for every byte "stored" ...

>SNIP


DECODING CHANGES:
We now have an additional checksum for helping to narrow down the possible paths that could have been taken.  

Please someone (murraypaul that means YOU-wink) run the proofs you ran before using this new method and see if they are not all unique. I beg you.  I am very curious to see what comes from this.

The following two letter strings give the same index value as 'Pi', using the new method outlined above:

String: 0M (0011000001001101) Index: 197
String: 0Y (0011000001011001) Index: 197
String: 0e (0011000001100101) Index: 197
String: 0i (0011000001101001) Index: 197
String: 1I (0011000101001001) Index: 197
String: PM (0101000001001101) Index: 197
String: PY (0101000001011001) Index: 197
String: Pe (0101000001100101) Index: 197
String: Pi (0101000001101001) Index: 197
String: QI (0101000101001001) Index: 197
String: rA (0111001001000001) Index: 197

The following single letter strings give the same index as P:
String: 0 (00110000) Index: 110
String: P (01010000) Index: 110

Encoding the same 1.3MB file as before now gives:

After byte 1295988, pi position is 202830581
After byte 1295989, pi position is 202830702
After byte 1295990, pi position is 202830819

So you are now using 157 digits of Pi for each byte encoded, almost exactly the 160 that would be expected.

Murraypaul, thanks for your hard work.  I am saddened by my failure to make this plan work out.  I don't feel any time was wasted myself, perhaps you do. But I thank you anyway.  You have earned my respect with your diligence and willingness to provide proofs.  I feel I have made some friends here, even if I'm not in your calibre of excellence.  I hope you will want to keep chatting with me down the road.  Please don't take my willingness to try again to find some other solution as a fool-headed waste of time.  It's how I choose to spend my brain power, what there is of it, and what makes me happy.  You can, of course, continue to help me understand my flawwed approaches.  Who knows, maybe I'll actually give one of you an idea of your own.  That would be cool, a payback for your time and effort.  

Peace, brothers.

[rigel]

The maths are the laws of the universe, and a universal language, but I seriously believe that in 200 years from now (if WW3 doesn't end us "coming soon to a nation near you!") we will have found all the ways to do these same things I'm proposing, because of someone like me didn't listen to the rules and tried it for goddsake.

On the contrary, I think 200 years from now 1+1 will still be 2.

Thanks for your time.

Thanks and sympathy goes to you for starting such an intriguing thread  

Why don't you learn how to program?
This will help you experiment and have fun

[murraypaul]

I think it would make for a neat 'secret decoder ring' type of encryption, especially for kids learning about maths or computing.
Each byte or byte sequence is assumed to occur in Pi somewhere, so you could encrypt your messages by replacing each byte, pair of bytes, etc... with the corresponding index of that next byte sequence in Pi. Essentially a book cipher, with Pi as the cipher, so no need to share the book.
It will increase, not decrease, the length of your message, but would be a fun computing project.

[DeathAndTaxes]

However you approach it, it is simply impossible to design a lossless compression algorithm that reduces the size of all possible input files given to it.

This.  The concept is called perfect compression* and I pointed that out to the OP.


* Note perfect means all inputs are reduces in size it doesn't necessarily imply a high level of compression.  If you found an algorithm which can reduce all inputs by 0.0000000001% then you have found an impossibility.

[OnkelPaul]

The maths are the laws of the universe (...)

Yes, actually, math is even more "universal" as the mathematical laws would be true in any possible universe, even if it were entirely different from the one we live in.
You would really do well to learn how mathematical proofs work, at least as much to understand when someone points out a flaw in an idea that you had. If something has been mathematically proven to be impossible, there is no "try harder" or "maybe in 200 years someone will find a way". It is impossible and it would be impossible in every other universe that could possibly exist.

Onkel Paul

[B(asic)Miner]

Maybe you're right, but I want to wait until

Dude, you remain ignorant of simple logic, and keep on wandering in meaningless details and experiments. I like your creativity, but there is a much more fundamental problem here, that has nothing to do with Pi, hunt values, flipping bits, decimal encoding paths, or ANY other approach you may think of.

Your idea is essentially the same as this: (just replace "2-bit" with "5MB" and "1-bit" with "4KB")

Wow, that is pretty awesome way to describe the problem, probably the easiest and most profound example yet, and yet you wait until the very end to present me with it?  I want to smack you. hahaha. (just kidding).

But .. here it comes, you knew it was coming ... hahaha ...  BUT ....

What if I developed a way, right now, for that 1 bit to be able to contain the 2 bit information?  Would that mean my theory is feasible, then?  If I can demonstrate right here, would that open the doors again?  Here goes:

2 bits would something like

01, right?     so:  00   01   10   11  
 could become:    2     3     4    5

Instead of encoding bits as 1s and 0s, we could encode single bits as (0,1 - the usual combination of binary, plus:),2,3,4,5

Thus everywhere we see pairs like this 00  we would now see 3.  This would be like using molecular science to influence data science.

Can anyone figure out this string using my rules above?  

25 34 32 52  (spaces for readability)  (had to edit this part due to a mistake)

It comes out to a number and a letter and you can find the answer here if you haven't got one of thes URL's yet:   http://www.roubaixinteractive.com/PlayGround/Binary_Conversion/Binary_To_Text.asp


So you can see every bit now displays 2 bits worth of data.  So yes, I've just done what you said isn't possible (wink, just messing with ya).

[Mooshire]

Maybe you're right, but I want to wait until

Dude, you remain ignorant of simple logic, and keep on wandering in meaningless details and experiments. I like your creativity, but there is a much more fundamental problem here, that has nothing to do with Pi, hunt values, flipping bits, decimal encoding paths, or ANY other approach you may think of.

Your idea is essentially the same as this: (just replace "2-bit" with "5MB" and "1-bit" with "4KB")

Wow, that is pretty awesome way to describe the problem, probably the easiest and most profound example yet, and yet you wait until the very end to present me with it?  I want to smack you. hahaha. (just kidding).

But .. here it comes, you knew it was coming ... hahaha ...  BUT ....

What if I developed a way, right now, for that 1 bit to be able to contain the 2 bit information?  Would that mean my theory is feasible, then?  If I can demonstrate right here, would that open the doors again?  Here goes:

2 bits would something like

01, right?     so:  00   01   10   11  
 could become:    2     3     4    5

Instead of encoding bits as 1s and 0s, we could encode single bits as (0,1 - the usual combination of binary, plus:),2,3,4,5

Thus everywhere we see pairs like this 00  we would now see 3.  This would be like using molecular science to influence data science.

Can anyone figure out this string using my rules above?  

25 34 32 52  (spaces for readability)  (had to edit this part due to a mistake)

It comes out to a number and a letter and you can find the answer here if you haven't got one of thes URL's yet:   http://www.roubaixinteractive.com/PlayGround/Binary_Conversion/Binary_To_Text.asp


So you can see every bit now displays 2 bits worth of data.  So yes, I've just done what you said isn't possible (wink, just messing with ya).

...but each number is stored as an 8 bit character, so you effectively quadrupled the size of it instead of halving it.

[B(asic)Miner]

Maybe you're right, but I want to wait until

Dude, you remain ignorant of simple logic, and keep on wandering in meaningless details and experiments. I like your creativity, but there is a much more fundamental problem here, that has nothing to do with Pi, hunt values, flipping bits, decimal encoding paths, or ANY other approach you may think of.

It may still be possible, but I won't know until the proofs are shown here.

The proof HAS been shown here (numerous times) that it is simply NOT possible, but you choose to ignore that.


Your idea is essentially the same as this: (just replace "2-bit" with "5MB" and "1-bit" with "4KB")

You: "I made an amazing discovery, an idea to reduce any 2-bit file by 50%! Using quaternion matrix inversion, I can trace a reverse index into Pi's decimal data (which is, after all, infinite) and find a unique cubic prime for every possible path that can be used to re-create the original file. Thus encoding (not compressing, but encoding!) any 2-bit file in a crypto key that is only 1 bit long!"

Critic: https://i.imgur.com/BpLHqWg.png

[/size]

While you were mocking me, you inadvertantly summed up my theorim perfectly, making it sound totally awesome.  You have quite a gift for boiling down all my long verbages into one tight, condensed grouping that makes perfect sense.  I can see from this (no joke) that you are more than likely a master programmer with a gift for tight, efficient code.  People who can do this with words can do this even better with coding.

Oh, and it's funny too.  Give the man props!

[B(asic)Miner]

Maybe you're right, but I want to wait until

Dude, you remain ignorant of simple logic, and keep on wandering in meaningless details and experiments. I like your creativity, but there is a much more fundamental problem here, that has nothing to do with Pi, hunt values, flipping bits, decimal encoding paths, or ANY other approach you may think of.

Your idea is essentially the same as this: (just replace "2-bit" with "5MB" and "1-bit" with "4KB")

Wow, that is pretty awesome way to describe the problem, probably the easiest and most profound example yet, and yet you wait until the very end to present me with it?  I want to smack you. hahaha. (just kidding).

But .. here it comes, you knew it was coming ... hahaha ...  BUT ....

What if I developed a way, right now, for that 1 bit to be able to contain the 2 bit information?  Would that mean my theory is feasible, then?  If I can demonstrate right here, would that open the doors again?  Here goes:

2 bits would something like

01, right?     so:  00   01   10   11  
 could become:    2     3     4    5

Instead of encoding bits as 1s and 0s, we could encode single bits as (0,1 - the usual combination of binary, plus:),2,3,4,5

Thus everywhere we see pairs like this 00  we would now see 3.  This would be like using molecular science to influence data science.

Can anyone figure out this string using my rules above?  

25 34 32 52  (spaces for readability)  (had to edit this part due to a mistake)

It comes out to a number and a letter and you can find the answer here if you haven't got one of thes URL's yet:   http://www.roubaixinteractive.com/PlayGround/Binary_Conversion/Binary_To_Text.asp


So you can see every bit now displays 2 bits worth of data.  So yes, I've just done what you said isn't possible (wink, just messing with ya).

...but each number is stored as an 8 bit character, so you effectively quadrupled the size of it instead of halving it.

Oh, duh, I should have seen that one, I would be using characters, which are themselvs ASCII binary, meaning each character would be 8 bits, so I would be adding more data.  So can anyone tell me what is going on with computers that can use something other than binary?  (of course that's not helpful to this discussion, but I am curious).  Is that what quantum computers do, compute with more than binary, but some new base number set?  What exists that would be faster than binary, is there anything?

[Nixsy]

Maybe you're right, but I want to wait until

Dude, you remain ignorant of simple logic, and keep on wandering in meaningless details and experiments. I like your creativity, but there is a much more fundamental problem here, that has nothing to do with Pi, hunt values, flipping bits, decimal encoding paths, or ANY other approach you may think of.

Your idea is essentially the same as this: (just replace "2-bit" with "5MB" and "1-bit" with "4KB")

Wow, that is pretty awesome way to describe the problem, probably the easiest and most profound example yet, and yet you wait until the very end to present me with it?  I want to smack you. hahaha. (just kidding).

But .. here it comes, you knew it was coming ... hahaha ...  BUT ....

What if I developed a way, right now, for that 1 bit to be able to contain the 2 bit information?  Would that mean my theory is feasible, then?  If I can demonstrate right here, would that open the doors again?  Here goes:

2 bits would something like

01, right?     so:  00   01   10   11  
 could become:    2     3     4    5

Instead of encoding bits as 1s and 0s, we could encode single bits as (0,1 - the usual combination of binary, plus:),2,3,4,5

Thus everywhere we see pairs like this 00  we would now see 3.  This would be like using molecular science to influence data science.

Can anyone figure out this string using my rules above?  

25 34 32 52  (spaces for readability)  (had to edit this part due to a mistake)

It comes out to a number and a letter and you can find the answer here if you haven't got one of thes URL's yet:   http://www.roubaixinteractive.com/PlayGround/Binary_Conversion/Binary_To_Text.asp


So you can see every bit now displays 2 bits worth of data.  So yes, I've just done what you said isn't possible (wink, just messing with ya).

...but each number is stored as an 8 bit character, so you effectively quadrupled the size of it instead of halving it.

Oh, duh, I should have seen that one, I would be using characters, which are themselvs ASCII binary, meaning each character would be 8 bits, so I would be adding more data.  So can anyone tell me what is going on with computers that can use something other than binary?  (of course that's not helpful to this discussion, but I am curious).  Is that what quantum computers do, compute with more than binary, but some new base number set?  What exists that would be faster than binary, is there anything?

http://en.wikipedia.org/wiki/Qubit

[DeathAndTaxes]

Oh, duh, I should have seen that one, I would be using characters, which are themselvs ASCII binary, meaning each character would be 8 bits, so I would be adding more data.  So can anyone tell me what is going on with computers that can use something other than binary?  (of course that's not helpful to this discussion, but I am curious).  Is that what quantum computers do, compute with more than binary, but some new base number set?  What exists that would be faster than binary, is there anything?

There are no non-binary computers but in theory you could develop one it wouldn't improve storage though.  Once you abstract everything away it has a physical manifestation (magnetic charge on a disk, high or low signal in ram circuit, transistors in silicon).  Using trinary would be possible but everything would take as much space.  For example most flash ram right now stores 1.5 bits per cell reducing the cell count by 1/3 for a given amount of storage space.

As for quantum computing, no it also works using binary however it involves superposition.  In classical mechanics a bit (or lightswitch if it helps to visualize it) has only two possible states 1=on or 0=off.  Either state can exist but only one state at a time.  In quantum mechanics a qubit can be simultaneously both on and off.  This concept is expanded to larger sets of bits.

For example: Consider first a classical computer that operates on a three-bit register. The state of the computer at any time is a probability distribution over the 2^3=8 different three-bit strings 000, 001, 010, 011, 100, 101, 110, 111. If it is a deterministic computer, then it is in exactly one of these states with probability 1. However, if it is a probabilistic computer, then there is a possibility of it being in any one of a number of different states. We can describe this probabilistic state by eight nonnegative numbers A,B,C,D,E,F,G,H (where A = probability computer is in state 000, B = probability computer is in state 001, etc.). There is a restriction that these probabilities sum to 1.

http://en.wikipedia.org/wiki/Quantum_computer

[B(asic)Miner]

Hey guys, you won't believe it,

a computer company is now going live with a version of Jan Sloot's theorum for data compression ... they even have videos to show it is working.

http://jansloot.telcomsoft.nl/    

Click on "Project 7" link (middle left) you will see the video.  This ... this is mind blowing.  I was right.  But maybe not about how MUCH compression total ... it says a Factor of 4, does that mean it's 4 times more efficient?   So a 4 GB file becomes a 1GB file?  Is that how "factor of 4" works?

Let me know what they are doing, if you can find some place to read in English (which I can't yet) ...  

[B(asic)Miner]

I'm getting a sickening feeling of jealousy here:


It seems this is for real, guys.  Look here on youtube:   http://www.youtube.com/watch?v=ITW5bjTipPA


The video tells some very interesting things:  

1) It won't work with a file smaller than 64 bytes.  Just like I was proposing.
2) At 3:30 seconds in, the video claims "On the Internet, we grab a file that contains random data.  Compression software can not handle such files (sometimes they make these files even bigger). Project 7 does not use any compression techniques and it handles every file as equal, just a file containing a sequence of numbers."
3) It does not compress, it encodes, just like my theory (which you said was impossible!)
4) It's super fast at encoding, just like my idea.
5) It uses 7 layers to cross link the key in a unique way to create encoding like the method I proposed, but using high level maths which I could not propose.
6) The files are stored on your hard drive and can be seen by Windows even though they are now 4-factor smaller.  Movies will play in realtime, but the data is massively smaller on the hard drive.
7) They are working on a 8-factor version but it still isn't working yet.  If they can do 4 and now 8, then at some point they will be doing 16 or 32.  As time goes on, systems become more evolved and get faster.
There is one part of the video at 8:30 seconds that says how much encoding was done to the file:   it says original (I can't read it) ... but later it says the video is 7 MB after being encoded and I believe it says the video was 28MB before being encoded.  7 MB isn't as good as my idea, but there is a working version, so it's much better than my idea in reality.  Later, they will have 8-Factor, that means the 28MB video will be just 3.5MB but still be just as high quality (there example is a HD video!)
9) It says it will encode all files equally, something many people here have told me is impossible to say.  One guy here said if anyone claimed they could reduce all files sizes by even 0.000001% they would be lying.  But they demonstrate that they can shrink every file size by the same exact 4-Factoring.  That means you are wrong somehow.

OR ... they are a farce. And this video is fluff, and they are making fools of themselves and advertising something they don't really have.  That would be foolish.  Who knows until it's actually released to the Public?  They might just have a heartattack and all their data cards get lost, and disappear into moon, right?  Hahaha.

Later.


Man!  Here is another youtube:  http://www.youtube.com/watch?feature=player_detailpage&v=kQsWP6n03EU

The Jan Sloot Principal turns out to be none other than the DNA method!  Here is what they have to say on the youtube site video:

"DNA is a different way to store data on a very efficient way like SDCS principle from Jan Sloot. Like SDCS it uses Key-codes (DNA-codes) which are smaller then 257 bytes with a Reference Table.
Goto http://jansloot.telcomsoft.nl/Forum for more information."

I knew it!   A Referencing System!  I am a genius.  But DNA based!   With 3 overlaying streams from different algorythms working in tandem to create a unique key the way DNA does!  DAMN!  OMG!  I should have seen that myself!  3 years and I never thought about DNA, how it works!  This is totally exciting!  

[BurtW]

I remember once back in college I was taking an information theory course.  I had stayed out late drinking adult beverages so was kind of hung over.  The teacher was droning on and on about some proof having to do with bases.  You can can create base 2, or base 3 or base 4 and so on devices but what is the mathematically "best" base for information density or some such criteria.

I fell asleep but woke up just in time to see the end of the proof and the answer was e.

Since e is closer to 3 than 2 I expect there is a small amount of gain to be had by doing everything base 3 instead of 2 but base 2 devices are just so much easier to implement.

[murraypaul]

9) It says it will encode all files equally, something many people here have told me is impossible to say.  One guy here said if anyone claimed they could reduce all files sizes by even 0.000001% they would be lying.  But they demonstrate that they can shrink every file size by the same exact 4-Factoring.  That means you are wrong somehow.

No.
They might claim they can do it.
That is not, in any way, the same as demonstrating that they can do it.
You have claimed you can compress any file by 90%+. You have not demonstrated that you can do it.

[BurtW]

I knew it!   A Referencing System!  I am a genius.  But DNA based!   With 3 overlaying streams from different algorythms working in tandem to create a unique key the way DNA does!  DAMN!  OMG!  I should have seen that myself!  3 years and I never thought about DNA, how it works!  This is totally exciting!  

How exactly does DNA store information?  Do you know?

[herzmeister]

ahem

http://en.wikipedia.org/wiki/Infinite_monkey_theorem

I only read a few posts in this thread and I'm not a "Crypto Compression" expert, but this was my first association.

[Mota]

ahem

http://en.wikipedia.org/wiki/Infinite_monkey_theorem

I only read a few posts in this thread and I'm not a "Crypto Compression" expert, but this was my first association.

We tried to tell him numerous times...