Entropy
Time Limit: 2000/1000 MS (Java/Others) Memory Limit: 65536/32768 K (Java/Others)
Total Submission(s): 2962 Accepted Submission(s): 1121
Problem Description
An entropy encoder is a data encoding method that achieves lossless data compression by encoding a message with “wasted” or “extra” information removed. In other words, entropy encoding removes information that was not necessary in the first place to accurately encode the message. A high degree of entropy implies a message with a great deal of wasted information; english text encoded in ASCII is an example of a message type that has very high entropy. Already compressed messages, such as JPEG graphics or ZIP archives, have very little entropy and do not benefit from further attempts at entropy encoding.
English text encoded in ASCII has a high degree of entropy because all characters are encoded using the same number of bits, eight. It is a known fact that the letters E, L, N, R, S and T occur at a considerably higher frequency than do most other letters in english text. If a way could be found to encode just these letters with four bits, then the new encoding would be smaller, would contain all the original information, and would have less entropy. ASCII uses a fixed number of bits for a reason, however: it’s easy, since one is always dealing with a fixed number of bits to represent each possible glyph or character. How would an encoding scheme that used four bits for the above letters be able to distinguish between the four-bit codes and eight-bit codes? This seemingly difficult problem is solved using what is known as a “prefix-free variable-length” encoding.
In such an encoding, any number of bits can be used to represent any glyph, and glyphs not present in the message are simply not encoded. However, in order to be able to recover the information, no bit pattern that encodes a glyph is allowed to be the prefix of any other encoding bit pattern. This allows the encoded bitstream to be read bit by bit, and whenever a set of bits is encountered that represents a glyph, that glyph can be decoded. If the prefix-free constraint was not enforced, then such a decoding would be impossible.
Consider the text “AAAAABCD”. Using ASCII, encoding this would require 64 bits. If, instead, we encode “A” with the bit pattern “00”, “B” with “01”, “C” with “10”, and “D” with “11” then we can encode this text in only 16 bits; the resulting bit pattern would be “0000000000011011”. This is still a fixed-length encoding, however; we’re using two bits per glyph instead of eight. Since the glyph “A” occurs with greater frequency, could we do better by encoding it with fewer bits? In fact we can, but in order to maintain a prefix-free encoding, some of the other bit patterns will become longer than two bits. An optimal encoding is to encode “A” with “0”, “B” with “10”, “C” with “110”, and “D” with “111”. (This is clearly not the only optimal encoding, as it is obvious that the encodings for B, C and D could be interchanged freely for any given encoding without increasing the size of the final encoded message.) Using this encoding, the message encodes in only 13 bits to “0000010110111”, a compression ratio of 4.9 to 1 (that is, each bit in the final encoded message represents as much information as did 4.9 bits in the original encoding). Read through this bit pattern from left to right and you’ll see that the prefix-free encoding makes it simple to decode this into the original text even though the codes have varying bit lengths.
As a second example, consider the text “THE CAT IN THE HAT”. In this text, the letter “T” and the space character both occur with the highest frequency, so they will clearly have the shortest encoding bit patterns in an optimal encoding. The letters “C”, “I’ and “N” only occur once, however, so they will have the longest codes.
There are many possible sets of prefix-free variable-length bit patterns that would yield the optimal encoding, that is, that would allow the text to be encoded in the fewest number of bits. One such optimal encoding is to encode spaces with “00”, “A” with “100”, “C” with “1110”, “E” with “1111”, “H” with “110”, “I” with “1010”, “N” with “1011” and “T” with “01”. The optimal encoding therefore requires only 51 bits compared to the 144 that would be necessary to encode the message with 8-bit ASCII encoding, a compression ratio of 2.8 to 1.
English text encoded in ASCII has a high degree of entropy because all characters are encoded using the same number of bits, eight. It is a known fact that the letters E, L, N, R, S and T occur at a considerably higher frequency than do most other letters in english text. If a way could be found to encode just these letters with four bits, then the new encoding would be smaller, would contain all the original information, and would have less entropy. ASCII uses a fixed number of bits for a reason, however: it’s easy, since one is always dealing with a fixed number of bits to represent each possible glyph or character. How would an encoding scheme that used four bits for the above letters be able to distinguish between the four-bit codes and eight-bit codes? This seemingly difficult problem is solved using what is known as a “prefix-free variable-length” encoding.
In such an encoding, any number of bits can be used to represent any glyph, and glyphs not present in the message are simply not encoded. However, in order to be able to recover the information, no bit pattern that encodes a glyph is allowed to be the prefix of any other encoding bit pattern. This allows the encoded bitstream to be read bit by bit, and whenever a set of bits is encountered that represents a glyph, that glyph can be decoded. If the prefix-free constraint was not enforced, then such a decoding would be impossible.
Consider the text “AAAAABCD”. Using ASCII, encoding this would require 64 bits. If, instead, we encode “A” with the bit pattern “00”, “B” with “01”, “C” with “10”, and “D” with “11” then we can encode this text in only 16 bits; the resulting bit pattern would be “0000000000011011”. This is still a fixed-length encoding, however; we’re using two bits per glyph instead of eight. Since the glyph “A” occurs with greater frequency, could we do better by encoding it with fewer bits? In fact we can, but in order to maintain a prefix-free encoding, some of the other bit patterns will become longer than two bits. An optimal encoding is to encode “A” with “0”, “B” with “10”, “C” with “110”, and “D” with “111”. (This is clearly not the only optimal encoding, as it is obvious that the encodings for B, C and D could be interchanged freely for any given encoding without increasing the size of the final encoded message.) Using this encoding, the message encodes in only 13 bits to “0000010110111”, a compression ratio of 4.9 to 1 (that is, each bit in the final encoded message represents as much information as did 4.9 bits in the original encoding). Read through this bit pattern from left to right and you’ll see that the prefix-free encoding makes it simple to decode this into the original text even though the codes have varying bit lengths.
As a second example, consider the text “THE CAT IN THE HAT”. In this text, the letter “T” and the space character both occur with the highest frequency, so they will clearly have the shortest encoding bit patterns in an optimal encoding. The letters “C”, “I’ and “N” only occur once, however, so they will have the longest codes.
There are many possible sets of prefix-free variable-length bit patterns that would yield the optimal encoding, that is, that would allow the text to be encoded in the fewest number of bits. One such optimal encoding is to encode spaces with “00”, “A” with “100”, “C” with “1110”, “E” with “1111”, “H” with “110”, “I” with “1010”, “N” with “1011” and “T” with “01”. The optimal encoding therefore requires only 51 bits compared to the 144 that would be necessary to encode the message with 8-bit ASCII encoding, a compression ratio of 2.8 to 1.
Input
The input file will contain a list of text strings, one per line. The text strings will consist only of uppercase alphanumeric characters and underscores (which are used in place of spaces). The end of the input will be signalled by a line containing only the word “END” as the text string. This line should not be processed.
Output
For each text string in the input, output the length in bits of the 8-bit ASCII encoding, the length in bits of an optimal prefix-free variable-length encoding, and the compression ratio accurate to one decimal point.
Sample Input
AAAAABCD THE_CAT_IN_THE_HAT END
Sample Output
64 13 4.9 144 51 2.8
Source
Greater New York 2000
题目大意:求输入的字符串的霍夫曼编码的编码效率。
题意分析:此题思路比较简单,基本原理就是大学数据结构中的霍夫曼编码的实现:把给每个字符在字符串中出现的次数作为该字符的权值,然后建立二叉树存储该字符,权值越小,在二叉树中的深度越深,权值越大,在二叉树中的深度越浅。方法就是:
1、每次选择所有字符串队列中权值最小的两个字符,然后建立一个新节点,将这两字符节点连接起来,新节点的权值为这两个字符节点的权值之和。
2、然后将新节点加入原队列中,再迭代进行上述操作,直到最后建成一棵树,即只剩一个节点。因为每次从队列中选择权值最小的节点,故采用优先队列比较合适。
3、得到的这棵树中,所有字符节点都在叶节点上,用叶节点的权值乘以该叶节点的深度(根节点的深度为0),即为该霍夫曼编码的编码长度。
#include<stdio.h>
#include<string.h>
int INF=0x3f3f3f3f;//无穷大
typedef struct
{
int data;//记录字母出现次数
int pa;//记录父亲结点
} jd;
jd d[80];//建立80个结点。应该够用了
char s[20005];//读取文本
void huffman(int n)
{
int m1,m2,x1,x2,t,i,j;//m1,m2记录两个权值较小的结点,x1,x2记录对应下标
for(i=0;i<n;i++)
{
m1=m2=INF;//初始化为无穷大
for(j=0;j<n+i;j++)//找到两个较小值的根结点
{
if(m1>d[j].data&&d[j].pa==-1&&d[j].data!=0)
{
m2=m1;
m1=d[j].data;
x2=x1;
x1=j;
}
else if(m2>d[j].data&&d[j].pa==-1&&d[j].data!=0)
{
x2=j;
m2=d[j].data;
}
}
if(m2!=INF)//如果找到两个较小值
{
t=n+i;
d[t].data=m1+m2;//加入结点
d[x1].pa=d[x2].pa=t;//删除两个已最小的结点
}
}
}
int main()
{
int i,l,c,p,ans;
while(scanf("%s",s))
{
if(strcmp(s,"END")==0)//结束标志
break;
for(i=0;i<80;i++)//初始化
{
d[i].data=0;
d[i].pa=-1;
}
l=strlen(s);//记录字符串长度
for(i=0;i<l;i++)
if(s[i]=='_')
d[26].data++;//建立字符与数字下标的映射
else
d[s[i]-'A'].data++;
huffman(27);//建立哈弗曼树
for(i=0;i<=26;i++)
{
c=0;//c记录编码所需长度
if(d[i].data!=0)
{
p=i;
while(d[p].pa!=-1)
{
c++;
p=d[p].pa;
}
if(c==0)//如果为根节点长度为1
c=1;
d[i].data=c;//将data赋值为所需字节数。方便下面算总数
}
}
ans=0;//ans记录所需总字节数
for(i=0;i<l;i++)
{
if(s[i]=='_')
ans+=d[26].data;
else
ans+=d[s[i]-'A'].data;
}
printf("%d %d %.1fn",8*l,ans,8.0*l*1.0/ans);//这个位置开始用的是%.1lf就WA了 应该是编译器的问题
}
//在杭电上用C++ G++ 用%.1lf都能过
不知道为什么用GUN C++就过不了了
//当时比赛时发我们坑惨了 整整一个多小时都在检查这个程序
return 0;
}
// 建议当大家确认结果完全正确时 检查一下你的%.lf 与%.f 以后最好就用%.f吧
然后看一下你的数组有没有开在主函数里面等问题
最后
以上就是愤怒白猫最近收集整理的关于Problem I hdu 1053 Entropy Entropy的全部内容,更多相关Problem内容请搜索靠谱客的其他文章。
本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
发表评论 取消回复