Compression : Some new Idea.
-
Hum... And how will the text compressed ???:confused: You will need to store the difference between the two characters and this will be stored in a 1 byte type (can be more if you use integers but then you increase the size of your file !!!!). So, you will store 1 byte instead of 1 byte. There is no compression at all and you will lose a lot of time for nothing ;P
I Will answer to ur question First u can use 6 bits for storing the difference.one thing understand that i now think on it. this some raw idea. come to the idea Out of 6 bits 3 bit u can use for the range.. that is using 3 bits u can represent from 1-7. when i find the difference is 72 i the bits is something like this 111010 . first 3 bits is 10 ^ that number. then it is added with 2 that is 010. then we get 111010. Similarly for 65 bits like 110101 .. now we can save 2 bits.. :-D . For big file it may compress. Also we can do this repeatidly .. Then the final result will be small file(I hopes.. I should do this): ) bye KD krishnadk
-
Hum... And how will the text compressed ???:confused: You will need to store the difference between the two characters and this will be stored in a 1 byte type (can be more if you use integers but then you increase the size of your file !!!!). So, you will store 1 byte instead of 1 byte. There is no compression at all and you will lose a lot of time for nothing ;P
I Will answwe to ur question First u can use 6 bits for storing the difference.one thing understand that i now think on it. this some raw idea. come to the idea Out of 6 bits 3 bit u can use for the range.. that is using 3 bits u can represent from 1-7. when i find the difference is 72 i the bits is something like this 111010 . first 3 bits is 10 ^ that number. then it is added with 2 that is 010. then we get 111010. Similarly for 65 bits like 110101 .. now we can save 2 bits.. :-D . For big file it may compress. Also we can do this repeatidly .. Then the final result will be small file(I hopes.. I should do this): ) bye KD krishnadk
-
Hai guys I have a new idea for compressing files.. it work as follows Example: samlpe text : "something is better than nothing" first s is placed first letter as usual now i will find the difference between s and o and only that difference is placed and so on.. How is this idea pls respond if u understand what i said(my language is poor . :( i know it). bye krishnadevan krishnadevan@ushustech.com mail to me if u interested... any new ideas also welcome.. ;) krishnadk
What you have explained is a simple cypher. It would be very easy to crack. :) Ant.
-
Yes it could but to go from the lowest letter to the highest letter it will have to be as many bits as the letters anyways. You could use some type of encding to save bits for the differences using some type of average difference and making these ther shortest code but I'd bet this will not help as the differences between letters looks distributed to me. John
-
What you have explained is a simple cypher. It would be very easy to crack. :) Ant.
-
Hai guys I have a new idea for compressing files.. it work as follows Example: samlpe text : "something is better than nothing" first s is placed first letter as usual now i will find the difference between s and o and only that difference is placed and so on.. How is this idea pls respond if u understand what i said(my language is poor . :( i know it). bye krishnadevan krishnadevan@ushustech.com mail to me if u interested... any new ideas also welcome.. ;) krishnadk
krishnadevank wrote: How is this idea Put some metrics together and you'll have your answer. Only empirical testing will tell you if the algorithm is sound or not.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
-
I Will answer to ur question First u can use 6 bits for storing the difference.one thing understand that i now think on it. this some raw idea. come to the idea Out of 6 bits 3 bit u can use for the range.. that is using 3 bits u can represent from 1-7. when i find the difference is 72 i the bits is something like this 111010 . first 3 bits is 10 ^ that number. then it is added with 2 that is 010. then we get 111010. Similarly for 65 bits like 110101 .. now we can save 2 bits.. :-D . For big file it may compress. Also we can do this repeatidly .. Then the final result will be small file(I hopes.. I should do this): ) bye KD krishnadk
Your basic idea is good. You take advantage that text files contain bytes from a relatively small set (26 small and 26 capital letters), so the differences would be small. Yes, the result should be smaller than source. But read a specification of the LZW algorithm, it is a classic compression approach, when the source file contains bytes from a small set. It brings you idea even deeper. Robert-Antonio "I launched Norton Commander and saw, drive C: on the left, drive C: on the right...Damn, why I need two drives C:??? So I formatted one..."
-
Hum... And how will the text compressed ???:confused: You will need to store the difference between the two characters and this will be stored in a 1 byte type (can be more if you use integers but then you increase the size of your file !!!!). So, you will store 1 byte instead of 1 byte. There is no compression at all and you will lose a lot of time for nothing ;P
cedric moonen wrote: So, you will store 1 byte instead of 1 byte. There's merit in this! Historically, we've put text through compression/encryption algorithms, with what appears to be gibberish coming out the other end. Folks get a hold of this gibberish and spend countless hours and computing power trying to reverse engineer it back to something legible. What if the gibberish was not gibberish at all but the actual text itself. So, no matter what decompression/decryption algorithm gets used, nothing legible comes out. It's akin to the old if-it-had-been-a-snake-it-would-have-bit-you type of thing. :-D
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
-
Hai guys I have a new idea for compressing files.. it work as follows Example: samlpe text : "something is better than nothing" first s is placed first letter as usual now i will find the difference between s and o and only that difference is placed and so on.. How is this idea pls respond if u understand what i said(my language is poor . :( i know it). bye krishnadevan krishnadevan@ushustech.com mail to me if u interested... any new ideas also welcome.. ;) krishnadk
Ok you found the difference how are you going to regenrate the original text, So according to your logic "ABCDEF" will be compressed to "11111". ??? Any sense ?
God is Real, unless declared Integer.
-
Ok you found the difference how are you going to regenrate the original text, So according to your logic "ABCDEF" will be compressed to "11111". ??? Any sense ?
God is Real, unless declared Integer.
-
ok you are rite. the output will be A111 and it is good as long as the difference is positive, This logic will take a beating if the difference it negative. plus maximum difference is 25 i.e Z-A so you will end up allocating as many bits as for each alphabets i.e 6 bits if you are not using variable bit rate. so its out of the window.
God is Real, unless declared Integer.
-
ok you are rite. the output will be A111 and it is good as long as the difference is positive, This logic will take a beating if the difference it negative. plus maximum difference is 25 i.e Z-A so you will end up allocating as many bits as for each alphabets i.e 6 bits if you are not using variable bit rate. so its out of the window.
God is Real, unless declared Integer.
i agree that's why from the start i said it was a simple substitution unless applied to a large alphabet in order to gain something The idea is not new, it dates since Sir Bacon whose cipher was based on Cesar cypher plus a changing offset at each next character. ;) Papa while (TRUE) Papa.WillLove ( Bebe ) ;
-
krishnadevank wrote: How is this idea Put some metrics together and you'll have your answer. Only empirical testing will tell you if the algorithm is sound or not.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
-
Ok you found the difference how are you going to regenrate the original text, So according to your logic "ABCDEF" will be compressed to "11111". ??? Any sense ?
God is Real, unless declared Integer.
-
-
krishnadevank wrote: Can u explain it . Didn't you already explain it here?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
-
Your basic idea is good. You take advantage that text files contain bytes from a relatively small set (26 small and 26 capital letters), so the differences would be small. Yes, the result should be smaller than source. But read a specification of the LZW algorithm, it is a classic compression approach, when the source file contains bytes from a small set. It brings you idea even deeper. Robert-Antonio "I launched Norton Commander and saw, drive C: on the left, drive C: on the right...Damn, why I need two drives C:??? So I formatted one..."
But text files do not contain only 26 or 52 letters. They contain whitespace, other characters ... And the differences can not be any better than the whole. It takes 6 bits to represent 52 letters + some formatting chars. It will still take 6 bits to represent the differences otherwise you will not be able to have any Za words... And LZW would certianlly be better as text files like this will get very high compression if the data is real words and not random. What he has designed is a very poor encryption scheme with no compression at all. Just bit packing. John