怪事，Stringgrid中的数值显示问题 ( 积分: 100 )

我在ACCESS的数据库中有两个表，其中分别都有单精度格式的字段，我在两个窗口上用Stringgrid显示字段中的数据：
stringgrid1.Cells[13,2]:=adodataset1.fieldbyname('NAME').AsString ;
可奇怪的是，同样是0.78的数值，在一个表格里正常的显示为0.78，而在另一个里面显示成 0.77999997138977 ，为什么？百思不得其解啊。显示不正常的那个表格我用了ONDRAWCELL事件：
procedure TfUserInput.StringGrid1DrawCell(Sender: TObject; ACol,
ARow: Integer; Rect: TRect; State: TGridDrawState);
begin
//浅蓝色为当前选择的行
if (acol=0) or (arow=0) then
exit;
if arow=nowrow then
self.StringGrid1.Canvas.Brush.Color :=clSkyBlue;
self.StringGrid1.Canvas.FillRect(rect);
self.StringGrid1.Canvas.TextOut(rect.Left ,rect.Top ,stringgrid1.Cells[acol,arow] );
end;
别的两个窗口代码几乎完全一样，可是为什么显示不同？？？

不管它，自己格式化一下。

我从EXCEL中OLE方式读取，好像没有问题。

是浮点运算的问题。

用格式化倒可以解决。
可是为啥会这样呢，精度问题？ 高手帮解释下

Delphi系统精度处理的问题,与Canvas.TextOut()无关。
一般可做格式化处理，如:
stringgrid1.Cells[13,2]:= Format('%12.2f',[adodataset1.fieldbyname('NAME').Asfloat]);

是数据精度的问题，是计算机数据类型本身的原因，和Delphi等各种IDE无关。
通常情况下，你试试用双精度表示。如果还不行，就格式化一下。

2年多前，在用ACCESS VBA时我遇到过这样的问题，为何金额界面上看是120.35，从另外一个途径看，变成了120.34，少了一分。当时数据精度用的是单精度，改成双精度就行了。

如果你要了解深入的原因，可以看下面的文章，文章中有些内容以ACCESS VBA为背景，仅共参考，也希望大家指正。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
单精度和双精度数值类型最早出现在C语言中（比较通用的语言里面），在C语言中单精度类型称为浮点类型（Float），顾名思义是通过浮动小数点来实现数据的存储。这两个数据类型最早是为了科学计算而产生的，他能够给科学计算提供足够高的精度来存储对于精度要求比较高的数值。但是与此同时，他也完全符合科学计算中对于数值的观念：

当我们比较两个棍子的长度的时候，一种方法是并排放着比较一下，一种方法是分别量出长度。但是事实上世界上并不存在两根完全一样长的棍子，我们测量的长度精度受到人类目测能力和测量工具精度的限制。从这个意义上来说，判断两根棍子是否一样长丝毫没有意义，因为结果一定是False，但是我们可以比较他们两个哪个更长或者更短。这个例子很好地概括了单精度/双精度数值类型的设计初衷和存在意义。

基于上述认识，单精度/双精度数值类型从一开始设计的时候，就不是一个准确的数值类型，他只保证在他这个数值类型的精度之内是准确的，精度之外则不保证，比方说，一个数值5.1，很可能存储在单精度/双精度数值中的实际值是5.100000000001或者5.09999999999999。导致这个现象的原因我们可以通过两种方式来解释：

简单的解释方法：

你可以尝试在任何一个控件的属性面板中，设定他的宽度为：3.2CM，当你输入完毕后，你会发现值自动变成了3.199cm，无论你怎么改，你都无法输入3.200CM，因为实际上在电脑中存储的并不是CM为单位的数值，而是“缇”为单位的数值，而“缇”和CM之间的比值，是个很难被除尽的数，因此你输入完毕后，电脑自动转换成了最接近的“缇”值，然后再转换成厘米显示到属性面板上，这一乘一除，两次四舍五入，误差就出来了。单精度/双精度也是类似的原理，其实在二进制存储的时候，单精度/双精度都采用了类似相近分数的方法，而这样的存储是不可能做到准确的。

深入的解释方法：

让我们来看看我们存储到数字介质中的单精度/双精度值到底是怎么样的，我们使用如下代码对单精度类型进行一个解剖：



Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)





Public Sub floatTest()
Dim dblVar As Single


dblVar = 5.731 / 8
dblOutput dblVar

dblVar = dblVar * 2
dblOutput dblVar

dblVar = dblVar * 2
dblOutput dblVar

dblVar = dblVar * 2
dblOutput dblVar

dblVar = dblVar * 2
dblOutput dblVar

dblVar = dblVar * 2
dblOutput dblVar

End Sub

Public Sub dblOutput(ByVal dblVar As Single)
Dim bytVar(3) As Byte
Dim i As Integer, j As Integer
Dim strVar As String

CopyMemory ByVal VarPtr(bytVar(0)), ByVal VarPtr(dblVar), 4
strVar = dblVar & ": "
For i = 3 To 0 Step -1
For j = 7 To 0 Step -1
strVar = strVar & (bytVar(i) And 2 ^ j) / 2 ^ j
Next j
strVar = strVar & " "
Next i
Debug.Print strVar

End Sub


运行后我们得到输出结果（输出格式为高位左，低位右）：




.716375: 00111111 00110111 01100100 01011010
1.43275: 00111111 10110111 01100100 01011010
2.86550: 01000000 00110111 01100100 01011010
5.73100: 01000000 10110111 01100100 01011010
11.4620: 01000001 00110111 01100100 01011010
22.9240: 01000001 10110111 01100100 01011010


这里，我们把单精度类型转化成了二进制数据输出，这里我们看到，虽然这六个数字完全不同，但是他们的二进制存储惊人地相似，我们看到红色标记部分，每次都是加1，事实上，单精度数据类型使用从高位开始第1位作为正负标记位（绿色），第2位到第9位，是一个跨字节的有符号字节类型数据，这个数值决定了小数点移动的方向和位数（红色），第10位到32位保存一个整数（蓝色）在存储过程中，电脑首先把输入的值不断移位（乘除2）直到这个数的整数部分占用了全部24位的整数位，然后把移动的位数写入浮点部分（红色），而移位后的结果写入整数部分（蓝色和绿色），小数部分则舍弃。求值的时候则是反向过程，先根据正负位和整数位求值，然后根据红色部分的整数来进行移位（乘除2的次方），最终才是我们得到的单精度数值。双精度数值也是同样原理，只是位数更多而已。


通过解剖单精度数值的二进制存储格式，我们可以清楚看到，实际上单精度/双精度的存储，都要通过乘法和除法，其中必有舍入，如果恰好你的数值在除法中被舍入了，那么你赋的初值就很可能与你最终存储的值不完全相同，其中的微小差异，并不与单精度/双精度的设计目标相违背。

当我们在数据库中或者VBA代码中使用一个单精度/双精度数值的时候，也许你从界面上看不到区别，但是在实际的存储中，这个差别却真真切切地就在那里，当你对其进行相等比较的时候，系统只是简单地作二进制的比较，界面上无法体现的微小差异，在二进制比较面前却无处遁形，于是，你的等于比较返回了一个意料之外的False。

结束语

通过本文，我们介绍了单精度/双精度数据类型的实质以及其特点（优点和缺点），通过比较和解剖我们了解到单精度/双精度实际上存储的是一个近似值，浮点的特性决定了他可以存储非常小的数，也可以存储极大的数，他的数据精度并不是一个绝对值，而是存储值的百分比，如果你存储10的100次方，误差就可能是10的80次方，如果你存储10的-100次方，误差就可能是10的-120次方。因此单精度/双精度数据类型不能进行相等的比较（或数据库关联）。

如果你需要进行等值比较或关联，那么有以下几种方案：

1、使用专为准确度而设计的货币类型。
2、使用整数类型存储，代码中移位。
3、某些特定情况下可以用文字存储。

估计有两个方面的差异：一个是显示时格式不同。另一个是从数据库取数据时有做运算或转换。请楼主检查一下。

感谢 delphi的回答