拜托,面试别再让我数1了!!!

简介: 面试中,除了TopK,是否被问过:求一个正整数的二进制表示包含多少个1?

面试中,除了TopK,是否被问过:求一个正整数的二进制表示包含多少个1?

画外音:姊妹篇《拜托,面试别再问我TopK了!!!》。

例如:

uint32_t i=58585858;

i的二进制表示是:

0000 0011 0111 1101 1111 0011 0000 0010

于是,i的二进制表示包含15个1。

到底有几种方法,这些思路里蕴含的优化思路究竟是怎么样的,今天和大家聊一聊。

一、位移法

思路:既然输入n是uint32,每次取n的最低位,判断是不是1,位移32次,循环判断即可。

伪代码:

do{

    if ((n&1)==1){

       result++;

    }

    n>>= 1;

    i++;

} while(i<32);

分析:不管n的二进制表示里包含多少个1,都需要循环计算32次,比较耗时。有没有可能,每次消除掉一个1,这样来降低计算次数呢?

二、求与法

观察一下n与n-1这两个数的二进制表示:

最末位一个1会变成0

最末位一个1之后的0会全部变成1

其他位相同

栗子:

           x = 1011 0000

         x-1= 1010 1111

x & (x-1) = 1010 0000

于是,n&(n-1)这个操作,可以起到“消除最后一个1”的功效。

思路:逐步通过n&(n-1),来消除n末尾的1,消除了多少次,就有多少个1。

伪代码:

while(n){

   result++;

   n&=(n-1);

}

分析:这个方法,n的二进制表示有多少个1,就会计算多少次。总的来说,n的长度是32bit,如果n的值选取完全随机,平均期望由16个1构成,平均下来16次,节省一半的计算量。

画外音:校招时,我问过这样的面试题,“如何快速判断一个正整数是不是2的x次幂”,巧妙解法是

return !(n&(n-1));

即,如果n是2的x次幂,二进制表示只有一个1。

三、查表法

空间换时间,是算法优化中最常见的手段,如果有相对充裕的内存,可以有更快的算法。

思路:一个uint32的正整数n,一旦n的值确定,n的二进制表示中包含多少个1也就确定了,理论上无需重新计算:

1的二进制表示中包含1个1

2的二进制表示中包含1个1

3的二进制表示中包含2个1

…

58585858的二进制表示中包含15个1

...
提前计算好结果数组:

result[1]=1;

result[2]=1;

result[3]=2;

…

result[58585858]=15;

…

伪代码:

return result[n];

查表法的好处是,时间复杂度为O(1),潜在的问题是,需要很大的内存。

内存分析:

假如被分析的整数是uint32,打表数组需要记录2^32个正整数的结果。

n的二进制表示最多包含32个1,存储结果的计数,使用5个bit即可。

故,共需要内存2^32 * 5bit = 2.5GB。

画外音:5个bit,能表示00000-11111这32个数。帮忙看下,算错了没有,上一篇文章bit和Byte算错了8倍。

四、二次查表法

查表法,非常快,只查询一次,但消耗内存太大,在工程中几乎不被使用。

算法设计,本身是一个时间复杂度与空间复杂度的折衷,增加计算次数,往往能够减少存储空间。

思路:

(1)把uint32的正整数n,分解为低16位正整数n1,和高16正整数n2;

(2)n1查一次表,其二进制表示包含a个1;

(3)n2查一次表,其二进制表示包含b个1;

(4)则,n的二进制表示包含a+b个1;

伪代码:

uint16 n1 = n & 0xFFFF;

uint16 n2 = (n>>16) & 0xFFFF;

return  result[n1]+result[n2];

问题来了:增加了一倍的计算量(1次查表变2次查表),内存空间是不是对应减少一半呢?

内存分析:

被分析的整数变成uint16,打表数组需要记录2^16个正整数的结果。

n1和n2的二进制表示最多包含16个1,存储结果的计数,使用4个bit即可。

故,共需要内存2^16 * 4bit = 32KB。

画外音:帮忙看下,算错了没有。

好神奇!!!

计算量多了1次(1倍),内存占用量却由2.5G降到了32K(1万多倍),是不是很有意思?

五、总结

数1,不难;但其思路有优化过程,并不简单:

(1)位移法,32次计算;

(2)n&(n-1),能消除一个1,平均16次计算;

(3)查表法,1次查表,2.5G内存;

(4)二次查表法,2次查表,32K内存;

知其然,知其所以然。

思路比结论重要。

希望大家对“数1”有新的认识,谢转。

作业题:升级为4次查表,需要使用多少内存呢?

image.png

架构师之路-分享可落地的架构文章

目录
相关文章
|
3天前
|
云安全 人工智能 运维
阿里云SecOps Agent,全新安全跨产品执行体验
自然语言驱动 云安全中心/WAF/CFW/ 等多款安全产品联动
1593 2
|
3天前
|
机器学习/深度学习 人工智能 调度
🐴 HappyHorse 1.1 现已上线阿里云百炼!快来查收模型使用指南,现在调用享 6 折~
HappyHorse 1.1 是新一代视频生成大模型,全面升级动态表现力、角色一致性、指令遵循、视觉质感与音画协同能力。支持I2V/T2V/R2V三类生成,适配短剧、电商广告、品牌营销等场景,提供高质、流畅、可控的AI视频生产力。
557 3
🐴 HappyHorse 1.1 现已上线阿里云百炼!快来查收模型使用指南,现在调用享 6 折~
|
14天前
|
缓存 测试技术 API
Qwen 3.7 Plus 与 Max 实测:性价比与多模态能力差异解析(2026)
2026 年 6 月 1 日,阿里悄无声息地发布了 Qwen 3.7 Plus,距 Qwen 3.7 Max 上线刚好 11 天。同样的 1M 上下文,同样的 35 小时自治上限。但价格才是头条:Plus 是 0.40/M输入,Max是 2.50/M——便宜约 6 倍——并且还能看图、看视频。Vision Arena 上 Plus 已经排到 #16。所以这周真正值得讨论的问题不是”要不要为视觉能力买单”,而是”Max 凭什么用 6 倍价格换来 2 个百分点的 benchmark 领先”。
|
15天前
|
JavaScript 定位技术 API
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
CodeGraph 是一款爆火的本地代码智能工具,通过 tree-sitter 解析 AST 构建结构化知识图谱(存于 SQLite),为编程 Agent 提前生成“代码地图”。它显著降低 Agent 在中大型项目中的探索成本——实测工具调用减少71%、Token 降57%、速度提升46%,支持19+语言及主流框架路由识别,完全离线、无需 API Key。
904 11
CodeGraph 爆火:编程 Agent 需要的不是更多上下文,而是一张提前画好的代码地图
|
2天前
|
人工智能 监控 前端开发
Electron 监控:让桌面 Agent 监控触手可及
一行代码实现Electron桌面端全景监控,自动还原崩溃现场、预警内存泄漏、全链路追踪、 SSE流式响应与交互埋点,让 AI 助手运行状态清晰可见,助力快速恢复稳定与流畅。
178 125
|
2天前
|
消息中间件 人工智能 Kafka
AI 时代,实时入湖正在告别 ETL:从 Kafka 到 Iceberg 的架构减法
本文围绕“零 ETL”这一趋势,讨论流数据入湖为什么需要做架构减法,并结合 Kafka × Table Bucket 的实践,分析一种将通用入湖能力前移到消息与表存储链路中的方案,如何在降低复杂度的同时,兼顾实时性、一致性、Schema 演进、CDC 语义与开放生态兼容。
184 121
|
7天前
|
缓存 人工智能 运维
GLM 5.2自托管全流程实战:硬件选型、vLLM/SGLang部署与成本盈亏测算
2026年智谱发布GLM 5.2超大混合专家模型,区别于以往仅开放API的闭源大模型,该模型权重以MIT开源协议对外发布,企业与开发者可完整下载、本地审计、私有化部署,实现数据不出环境、自定义微调、自主调度推理资源。GLM 5.2拥有753B总参数,原生支持百万级上下文窗口,在代码生成、长文档推理、数学逻辑等多项基准测试中对标国际顶尖商用模型,是首款可完整自托管的前沿代码向大模型。
614 0
|
15天前
|
人工智能 运维 JavaScript
阿里云Qoder CN(原通义灵码)全解析 产品形态、版本划分与技术适配说明
在AI辅助开发与智能办公工具持续普及的当下,阿里云旗下原通义灵码正式更名为Qoder CN,同时延伸出QoderWork CN、Qoder CN CLI、Qoder CN Mobile等多款配套产品,形成覆盖代码开发、日常办公、终端交互、移动端使用的完整工具矩阵。Qoder CN核心定位为AI智能编码助手,深度适配主流代码编辑器、集成开发环境以及终端场景;QoderWork CN则偏向桌面端综合办公辅助,二者面向不同使用场景,划分了多个版本档位,搭配差异化资源配额、功能权限与计费规则,同时兼容多款主流大模型。
975 8