I want to know if I am calculating the results are right?
3 views (last 30 days)
Show older comments
tina jain on 6 May 2015
Commented: Walter Roberson on 12 May 2015
I have applied run length encoding on a string or characters. Let it be
which after Run length encoding turns to be t6P2t6P2N3t6
so I calculated the compression ratio to be (12/25)*100= 48%
Is it correct???
Walter Roberson on 6 May 2015
Edited: Walter Roberson on 6 May 2015
Close. The original is length 25 not 26.
But how are you going to handle counts of greater than 9? And how are you going to handle characters that do not repeat?
Walter Roberson on 8 May 2015
Your aaAA is a vector that contains a mix of original characters and binary counts. Because of the details of how you built it, the vector will be of type char(). The spaces or not that you see are the results of looking at char() of the binary counts. For example if the count happened to be 9 then the corresponding position would hold char(9) which is the tab character. If you want the character '9' to show up instead of binary 9, then you need to change your program, and you need to take into account that counts of more than 9 might occur so that multiple output character positions in the string might be required to do the encoding.
More Answers (1)
Thomas Koelen on 6 May 2015
Walter Roberson on 12 May 2015
In general, using the whos() byte count to define the compression ratio is wrong. whos() will report the number of bytes used to store the data in the data type you used for your storage, but if you did not pack that datatype completely full then you could create a byte array that was smaller and would be the "real" size.
For example it might be convenient (or sloppy programming) to use double precision values to store results that are integral from 0 to 2^24-1 . That's only 3 bytes worth of value stored in 64 bits (8 bytes). The 3 useful bytes from each value could be saved to an array or written to a file, producing a smaller result.
When you use the whos() byte count you need to understand how much information you have packed into those bytes and adjust accordingly.
For this reason, the calculations would more often be done not by asking the programming language for the number of bytes used for storage (which might include overheads), but instead by multiplying the number of elements stored by the number of used bytes per element. In some cases it instead becomes more useful to multiply the count of the number of elements stored by the number of useful bits per element, and divide the total by the bits-per-byte of 8, rounding up: the result is the number of bytes that the information could be written to in a file, after going through procedures to pack down the information. It isn't always worth going through that trouble of packing down the information just to prove that you could. For example you might run different algorithms, find the one with the smallest theoretical size, and only then bother to do the packing down, since packing down can be a sort-of-expensive operation when you can't access hardware bit-rotate instructions.
Find more on Logical in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!Start Hunting!