【哈夫曼编码】HDU1053-Entropy

简介:

Entropy
Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others)
Total Submission(s): 4178    Accepted Submission(s): 1707


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.

 

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
 

 

 

 

哈夫曼编码。
题意是,给出一排字符串,要求求出字符的8位编码的长度,哈夫曼编码值,以及之间的比值
因为仅仅只要求求出哈夫曼编码值,所以不用建立哈夫曼树,可以建立优先队列,只要将每次最小的
出队的两个元素合成一个新的大数,然后放进优先队列中,直到只剩下一个元素为止,那个元素就是哈夫曼编码值。

AC代码:

#include<stdio.h>
#include<string.h>
#include<queue>
#include<algorithm>
using namespace std;
char a[1500];
int flag[27];
int main()
{
    int i,j,n,m,x,y,sum;
    while(scanf("%s",a),strcmp(a,"END")!=0)
    {
       memset(flag,0,sizeof(flag));
       n=strlen(a);
       for(i=0;i<n;i++)
       {
          if(a[i]!='_')
          flag[a[i]-'A']++;
          else
          flag[26]++;
       }
       
       priority_queue<int,vector<int>,greater<int> > q;
       for(i=0;i<=26;i++)
       if(flag[i]!=0)
       q.push(flag[i]);

       
       sum=0;
       while(q.size()>1)
       {
          x=q.top(); q.pop();
          y=q.top(); q.pop();
          q.push(x+y);
          sum+=(x+y);
       }
       
       if(sum==0)
       sum=n;
       
       printf("%d %d %.1lf\n",n*8,sum,(n*8.0)/(sum*1.0));
    }
    return 0;
}
相关文章
VS中出现的printf,scanf等函数不安全而报错的问题的全面解决方法
VS中出现的printf,scanf等函数不安全而报错的问题的全面解决方法
2249 0
|
2月前
|
运维 物联网 语音技术
复用 Qwen3-ASR 的解码器做口述整理:一个 1.7B LoRA 的训练记录
Saymore开源项目创新性地复用Qwen3-ASR-1.7B解码器(本身是语言模型),通过单LoRA实现语音识别后的轻度/深度/邮件/00后四风格文本整理,显存仅需4GB或纯CPU运行。方案兼顾效率、隐私与部署简洁性,已MIT协议开源。(239字)
328 1
|
2月前
|
人工智能 供应链 安全
RSAC 2026披露:100% AI IDE可被Prompt Injection、Claude Code/Codex/Cursor等7款Agent被.git配置反控,Java团队的供应链红线怎么守?
RSAC 2026披露:100%主流AI编程环境存在Prompt Injection风险,跨24个CVE;Manifold发现8个.git配置漏洞,4款工具仍未修复;Cursor/Windsurf因老旧Electron暴露94+浏览器漏洞。Java团队面临Maven、Spring等新攻击面。飞算JavaAI以本地化处理、Java专有模型、五步可追溯工作流构筑供应链安全防线。
|
2月前
|
Unix Apache 开发者
用了开源代码却踩了坑:开发者必须分清的开源协议法律边界
开源不等于免费随便用。本文从律师视角梳理 MIT、Apache、GPL、AGPL 四类常见开源协议的法律边界与传染性风险,并给出开发者可落地的依赖合规清单。
|
4月前
|
自然语言处理 安全 API
越狱攻击为什么难防?大模型安全围栏关键能力拆解
企业 AIGC 应用防越狱攻击,需要从“模型拒答”升级为“安全围栏”。安全围栏不是单一审核接口,而是输入检测、风险分级、输出审核、安全代答、账号风控、权限控制和运营闭环的组合。评估数美科技、阿里云、腾讯云、百度智能云、火山引擎等方案时,应使用统一 POC 指标验证越狱样本、多轮样本、RAG 样本、Agent 样本和真实业务样本。
|
7月前
|
前端开发 JavaScript API
前端简历编写与项目描述技巧:打造脱颖而出的求职利器
在竞争激烈的前端开发领域,一份优秀的简历和清晰的项目描述是获得面试机会的关键。如何通过简洁有力的文字展现技术实力与项目价值?以下是几个核心技巧,助你提升简历竞争力
|
8月前
|
人工智能 自然语言处理 前端开发
AI生成网站入门指南:从零基础到专业建站的路径
零基础建站难?AI生成网站成新选择!无需代码、低成本,三步搞定:①明确目标场景;②用自然语言生成页面与前后端代码(如LynxCode);③优化交互与适配。AI不替代开发者,而是降低门槛、提升效率,助创业者快速验证想法。
|
10月前
|
Java 应用服务中间件 微服务
SpringBoot
Spring Boot是Spring框架的扩展,旨在简化Spring应用的初始搭建和开发过程。它通过自动配置、内嵌服务器、起步依赖等特性,减少繁琐的配置,实现快速开发与部署,提升开发者效率,是现代Java开发尤其是微服务架构的重要工具。
 SpringBoot
|
存储 负载均衡 Java
SpringCloud框架
本文介绍了微服务架构中常用的技术组件与原理,包括Nacos与Eureka的服务注册与发现机制、Nacos的分级存储模型、OpenFeign的远程调用流程、Ribbon与Spring LoadBalancer的负载均衡策略、Hystrix与Sentinel的限流熔断机制、滑动窗口算法原理,以及Spring Cloud Gateway的路由断言与过滤器功能,全面覆盖微服务核心治理能力。
|
机器学习/深度学习 弹性计算 搜索推荐
真正的0代码,0脚本,0门槛,QwQ-32B一键部署!
阿里云最新发布的QwQ-32B模型通过强化学习显著提升了推理能力,在多个核心指标上达到DeepSeek-R1满血版水平,超越了DeepSeek-R1-Distill-Qwen-32B。用户可通过阿里云系统运维管理(OOS)的公共扩展功能,一键部署OpenWebUI+Ollama至ECS,轻松运行QwQ-32B模型。该方案支持本地部署和连接阿里云百炼在线模型,无需编写代码,操作简便,适合新手尝试。具体步骤包括:在阿里云控制台安装OpenWebUI扩展、选择ECS实例并创建、等待几分钟后获取URL链接,即可开始使用。此外,还提供了详细的配置指南和高级玩法介绍,帮助用户更好地利用该模型。