博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
对于IEEE754移码取值问题的一点臆测
阅读量:6033 次
发布时间:2019-06-20

本文共 979 字,大约阅读时间需要 3 分钟。

hot3.png

  昨晚,科协的群里提到了移码,相对陌生的词汇,我从未见过,后来搜索了下资料,发现了IEEE754中采用的是127(32bit),很是疑惑,一般不都是128吗?

  经过计算发现了一个现象,只能说这个相当巧妙!

—————————————————————————————————————————————————————

1.   首先IEEE754  为何定义规格化、非规格化、无穷大、NaN  

    注:以下均以32位浮点数为例   

        A.  规格化:阶数(exp)不为0和255  

        B.  非规格化:exp=0  

        C.  无穷大:exp=255,尾数(frac)=0   

        D.  NaN:exp=255,frac!=0   

2.   什么是移码?   

    移码就是符号位取反的补码   

      例如:   

        补码:10000001 (-127=-128+1)   

        移码:00000001 (补码+最高位的原码数值128)   

        当然上例是最最普通的例子。   

        我们因此而得到的效果为: 

                            00000000=-128  

                            00000001=-127  

                                。。。。。。   

                            11111111=127(01111111(127)+10000000(128))   

    相对于原来的二进制表示而言,这里更加容易比较大小,这个很明显。   

    但是   

    为什么IEEE754不是加128,而是127?   

        最精辟的就是这里了,这个和我们1中讲述的4中状态有关   

            首先,我们先来按照上面的来计算一边   

                  -128+127=11111111=-128(10000000+01111111)   

                  -127+127=00000000=-127 

                            。。。。。。   

                    127+127=11111110=127  

  先来看11111111,按照128的算法,这个值应该是最大的,但是这里确实最小的,好吧,IEEE754  的目的达到了,这个值绝对不可取,因此,作为两个特殊状态,至于另外的00000000,原则上说这个值是合法的,但是这里令它表示非规格化,至于为什么,你们得问IEEE 组织了,但是好歹他也被赋予了合法的地位(笑),我们的确需要非规格化数,也只有它的形式最特殊了。 

———————————————————————————————————————————————————————

不知道对不对,希望大家斧正^_^

转载于:https://my.oschina.net/codesun/blog/79673

你可能感兴趣的文章
2019-4-23 plan
查看>>
固定弹层叉掉
查看>>
[编解码] 关于base64编码的原理及实现
查看>>
WinDbg配置和使用基础
查看>>
转:Object-Runtime的基本数据类型
查看>>
JMJS系统总结系列----Jquery分页扩展库(五)
查看>>
Excel技巧之——英文大小写转换(转)
查看>>
Google 翻译的妙用
查看>>
算法导论--python--插入排序
查看>>
Hydra用户手册
查看>>
常用的集合
查看>>
Unity3D工程源码目录
查看>>
杀死进程命令
查看>>
cookie 和session 的区别详解
查看>>
浮点数网络传输
查看>>
Mongodb对集合(表)和数据的CRUD操作
查看>>
面向对象类的解析
查看>>
tomcat如何修改发布目录
查看>>
CentOS 5.5 使用 EPEL 和 RPMForge 软件库
查看>>
Damien Katz弃Apache CouchDB,继以Couchbase Server
查看>>