|
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
|
|
|
|
|
It seems to me its a substitution and not a compression
am i wrong?
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
Hum...
And how will the text compressed ???
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 
|
|
|
|
|
Size of the data for string difference may be less than 1 byte.
|
|
|
|
|
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
|
|
|
|
|
|
I agree as this will not save anything because differences have to be as big as the values.
John
|
|
|
|
|
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..  . 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
|
|
|
|
|
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.. . 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..."
|
|
|
|
|
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
|
|
|
|
|
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.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
What you have explained is a simple cypher. It would be very easy to crack. 
Ant.
|
|
|
|
|
I will talk to u after i will Do it..
until bye
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)
|
|
|
|
|
Hai DavidCrow .
Can u explain it . It will help me.
so pls do it
bye
krishnadk
|
|
|
|
|
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)
|
|
|
|
|
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.
|
|
|
|
|
From what i understood it will be
A11111
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
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 ) ;
|
|
|
|
|
ABCDEF is not compressed to 11111
it like 12345. understand
krishnadk
|
|
|
|
|
|
Hi!.
I have an object, a big object, with many arrays of others object, so, I have problems when I serialize this object, because it seems that is not stored on disc completely.
There is a limit of size, of the object, to serialize?. That is, "more than xxx bytes are not possible to be stored in a single object".
'Cause I trace the serialization process, (both, store and load), and first, when the object is being stored, I see the values of the fields going to the CArchive object through the operator << :
if(ar.IsStoring)
ar<<field1<<field2; <---="" this="" line
...
and="" they="" are="" the="" right="" values,="" (numbers).
but="" when="" i="" trace="" same="" method,="" want="" to="" read="" from="" file="" object,="" values="" that="" see="" allways="" 0.
...
else
ar="">>field1>>field2; <-- this line
...
I can load a part of the object well, but other no.
All the data to serialize are of type long.
I don't know if the problem is when I try to save the data, (that it seems to be correct, 'cause there are not errors and I can see the right values going to CArchive), or when I try to read the data, (that also it seems to be correct, but nevertheless is not it 'cause I load allyaws 0).
Thank you.
|
|
|
|
|
Can u post your Serialize Method, I think it will help to answere you.
thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
