c语言中的四舍五入问题，这是一个有趣的东西，准确的来说，c语言中的确是有四舍五入这个系统，但在实际应用中则会出问题，如下：
#include
int main()
{
float x1=329.835,x2=529.835;
printf("%.2f %.2f",x1,x2);
return 0;
}
显然若是按照四舍五入，输出的结果应该是329.84与529.84.
但结果却是这样的，一个没保留，一个却保留了，难道这是随机的？其实不然.
众所周知计算机中的所有数据都是以2进制的形式进行储存的，故对于电脑而言不可能完全精确地表示十进制中小数点后三位的数，其真正的储存形式如下
所以对于计算机而言，329.835是以329.8349999...795来储存的,而529.835是以529.835000...364来储存的.
显然，这就可以解释c语言在拥有四舍五入系统的前提下，在某些情况中仍然无法得到准确的四舍五入后的数字！
故对于需要四舍五入的情况，我们往往采用另一种形式进行四舍五入。
首先我们知道，对于十进制小数.5类型数（如0.5,11.5,18.5）即小数部分可以以2的负一次方来表示的数，这时计算机是可以“完美”的储存这个十进制小数字，而对于.6，.7，.8，.9与.4，.3，.1，.2，这类数字，计算机虽然无法“完美”的储存这些数字，但从上面两张图可以看出，计算机储存的结果十分相近，误差几乎为零，在这样的情况下，我们就可以运用所谓的“+0.5的取整法”
所谓加0.5的取整法就是运用在c语言中浮点型数强制转化为整形数时只会其保留整数，而不会进行四舍五入的计数法则，如下
所以对于保留整数的小数来说，我们只需在其原来的基础上+0.5后再进行强制类型转换，就可以达到不会出错的四舍五入
如：
（%.0f只是为去掉多余的0）
以此为基础，我们就可以进行其他小数点后n位数的保留.
如对上面329.835保留两位小数
我们则可将其先乘以100转化为32983.5后再重复上面的+0.5的取整法，转化完后再/100.0即可；
但事实却是这样的：
可以看见x1还是未进行准确的四舍五入
但当我们输入直接329.835时，如下
这时程序却进行了正确四舍五入，这就很奇怪了。
由于博主现才刚进大一，知识层面还有很多欠缺，无法肯定地解释这个问题，但根据现象还是能进行相应的推测：
由上结果可以知道对于c语言来说，在上面的情况中，x1*100与329.835*100在实质上是不同的，博主推测这时由于329.835在c语言中的对应的数据是329.8349999...795，故x1=329.835的实质是将329.8349999...795传入了x1所占的内存中去，故其乘以100当然是以329.8349999...795的形式乘以了100，这样的得到的结果是32983.49999...795这样+0.5后仍然无法进1，故此时强制类型转后还是32983，当然得到结果也只会是329.83
而对于329.835*100的情况，我推测c语言中是将先329.835这个数据以类似于字符的形式（或者说编号）储存在内存中，c语言提前将每个字符或者编号对应了某个数字（如上面的329.8349999...795），此时将其乘以100，是先将329.835这个字符的小数点后移两位，得到字符‘32983.5’后，再去内存中找‘32983.5’这个字符所对应的数值，而32983.5所对应的数字正好就是32983.5，故这样输出的结果就是正确的。
当然以上都是推测，没有任何严谨的依据，但对于此时的博主本人来说，也已经算是一个颇有趣味的探究了。
抛开上面的，对于这种麻烦的情况，还是有办法解决的，通过对数据的尝试与观察，我们还是可以发现大多数小数虽无法“完美的储存”，但其误差几乎为零，如1.6是1.60000...089,12.6是12.59999...964，故我们只需将+0.5取整法，改为0.5001（或者中间更多0）取整法即可，这样就可以抵消掉0.099999...微小误差而带来的错误。
