#整型与浮点型的储存问题#

简介: #整型与浮点型的储存问题#

一·整型如何储存
首先我们会输入整型变量的时候,计算机会进行存储,然而它是怎么储存的呢?首先我们要明白我们数字输入的是原码,而计算机在内存中储存的是补码。也就是说我们输入的数字首先转化为二进制的原码然后最终转化为补码储存在计算机内存中,然后我们获取的时候,它会由补码转化为原码供我们使用。

这里我们要注意当我们在编译器调试窗口监视的时候看到的是十六进制的数字,而且储存的顺序是倒回来的:

int i=1;
00000000000000000000000000000001//这是二进制
0x01 00 00 00//十六进制显示//vs下
这是究竟是为什么?这便引入了下面我们要讲的大小端问题。欲知后事如何,请听下回分解。

二·整型大小端储存
先简单介绍一下大小端,它其实是放置数据的两种不同的方式罢了:每个整型数据都会有尾字节,如果在大端机器它会把尾字节处数据放在高地址处,如果是小端的话,他就会放在低地址处;下面展示一个图,来详细说明一下吧。

这样我们会更加详细理解大小端问题把。

那么下面我们是不是可以根据这个来写个代码来判断机器是大端还是小端呢?

int main() {
int n = 1;
if ((char)&n == 1) {
printf("小端");
}
else printf("大端");
return 0;

我们用它判断出了vs2022是小端机器。

三·浮点型规则介绍
首先,我们根据ieee754的规定是如何对浮点数进行处理的,首先所有的浮点数可以根据一个公式v=(-1)^sm2^E:其中(-1)^s表示符号位,而m是有效数字即尾数,1<m<2;2^E表示指数位,e即阶码

如:

四·浮点型如何储存进去
这里我们可以知道m一定可以写成1.xxxxxxxx形式,那么,在ieee 754规定下,我们会默认把这个1省略掉这样可以空出一位的空间使得要存的浮点数精确度更高一些。这样在32为我们精确的尾数就是24,而64位他就是53了。

下面我们对e的存入进行分析:首先我们要知道e是可以取0~8或者0~11的那么就意味着要存的这个二进制范围是0~255或者0~2047;但是根据ieee 754规定我们在存入的时候要加一个中间值,他在32位下是127,在64位下是1023;若是32位下就是e+127等,如果我们假设e=10;那么10+127=137化成二进制10001001储存起来,64位下也是同理。

五·浮点型如何取出
当我们取出存入的数据时我们就要分三种情况进行讨论:

1·e全为0:那么也就意味这个没有存入之前的e很小;那么也就可以推测出原数字也特别小故m再还原为原来的数字可以不用加1;而是直接还原为0.xxxxxxxxx。

2·e全为1:那么就意味着原来数字加上中间数后还是特别大,原来未存入之前之前也特别大而±就要看s了。

3·e不全为0或者1:那么我们就按照怎么存入的再怎么拿出来;比如在32位下:(0.5)(1/2);那么可以写成(-1)^21*2^(-1);然后我们将e存进去就是126;化成二进制01111110;然后减去1;得到23位:00000000000000000000000;最后储存的二进制就00111111000000000000000000000000。

下面我们举个例子:

include

int main()
{
int n = 9;
float p = (float)&n;
printf("n的值为:%d\n", n);
printf("p的值为:%f\n", p);

*p = 9.0;
printf("n的值为:%d\n", n);
printf("*p的值为:%f\n", *p);
return 0;

}
这里我们定义的整型9:00000000 00000000 00000000 00001001;然后打印第一个应该是9;

接着我们把它转化为浮点型,并用浮点型指针访问应该是按照这样0 00000000 00000000000000000001001;那么我们去访问,由于储存的e全0;所以不用补;数字是个十分小的数故打印0,并精确到后六位;

我们要是按浮点型存入9.0;按浮点型放入:0 10000010 00100000000000000000000,那么当我们用浮点型指针去打印那么就会是9.000000;

但是我们浮点型存进去的结果用整型去打印 整型访问时就会变成每个字节分开的:01000001 00010000 00000000 00000000;故该是个很大的数;

以上就是对它的简单理解。

不足之处大佬多多指点!无论身处何种地位,我始终坚守"不耻下问"的原则。对于我而言,学问无分高低,知识无分贵贱。即使面对一个看似微不足道的问题,我也会虚心请教,因为我相信每个问题都蕴含着学习的机会。不耻下问不仅是我对知识的尊重,更是我对他人智慧的认可。我深知,只有不断学习,才能不断进步,而这一切都离不开一颗愿意虚心请教的心。

相关文章
|
Kubernetes 监控 调度
Kubernetes Pod调度:从基础到高级实战技巧
Kubernetes Pod调度:从基础到高级实战技巧
3361 0
|
9月前
|
SQL Java 关系型数据库
Spring事务传播机制:7种姿势教你玩转"事务接力赛"
事务传播机制是Spring框架中用于管理事务行为的重要概念,它决定了在方法调用时事务如何传递与执行。通过7种传播行为,开发者可以灵活控制事务边界,适应不同业务场景。例如:REQUIRED默认加入或新建事务,REQUIRES_NEW独立开启新事务,NESTED支持嵌套回滚等。合理使用传播机制不仅能保障数据一致性,还能提升系统性能与健壮性。掌握这“七种人格”,才能在复杂业务中游刃有余。
|
运维 持续交付 API
从零构建微服务架构:一次深度技术探索之旅####
【10月更文挑战第28天】 本文记录了作者在从零开始构建微服务架构过程中的深刻技术感悟,通过实战案例详细剖析了微服务设计、开发、部署及运维中的关键要点与挑战。文章首先概述了微服务架构的核心理念及其对企业IT架构转型的重要性,随后深入探讨了服务拆分策略、API网关选型、服务间通信协议选择、容器化部署(Docker+Kubernetes)、以及持续集成/持续部署(CI/CD)流程的设计与优化。最后,分享了在高并发场景下的性能调优经验与故障排查心得,旨在为读者提供一套可借鉴的微服务架构实施路径。 ####
366 3
|
5月前
|
JSON 人工智能 API
从对话到Agent:大模型工具调用能力的量化评测
大模型向Agent进化,工具调用是关键。本文介绍EvalScope评测框架,通过双重验证机制,量化评估模型“会不会用、能不能用好”工具,助力开发者打造可靠AI应用。
715 4
|
6月前
|
人工智能 自然语言处理 机器人
适合电商的智能客服系统推荐(2025年12月更新)
瓴羊Quick Service是阿里云旗下智能客服产品,深度整合电商交易链路,支持全渠道协同与大模型应用,具备高并发稳定性,助力中大型电商实现服务智能化与业务增长。
|
8月前
|
机器学习/深度学习 数据采集 监控
107_DPO:直接偏好优化
在大型语言模型(LLM)的发展历程中,如何让模型输出与人类偏好保持一致一直是研究的核心挑战。从早期的监督微调(SFT)到基于人类反馈的强化学习(RLHF),再到如今的直接偏好优化(DPO),对齐技术经历了显著的迭代与创新。
1505 1
|
SQL 关系型数据库 数据库连接
|
人工智能 自然语言处理 搜索推荐
LLM在电商推荐系统的探索与实践
LLM在电商推荐系统的探索与实践
4717 2
|
数据采集 缓存
访问网站的速度变慢的原因有什么,有哪些解决方法?
随着互联网技术和科技的发展,在上网的时候使用代理ip的使用人数也越来越多,因为业务的需求需要使用http动态代理ip的应用范围越来越多,那么访问网站的速度变慢的原因有什么,有哪些解决方法? 接下来小编就给大家介绍一下
1623 2
|
人工智能 小程序 API
「音视频实时互动」功能上线:几分钟实现模型到应用!
「音视频实时互动」功能上线:几分钟实现模型到应用!
376 13

热门文章

最新文章