Chinaunix首页 | 论坛 | 博客
  • 博客访问: 66775
  • 博文数量: 36
  • 博客积分: 2510
  • 博客等级: 少校
  • 技术积分: 410
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-04 12:39
文章分类

全部博文(36)

文章存档

2010年(1)

2009年(35)

我的朋友
最近访客

分类: LINUX

2009-12-11 18:59:33

我这两天总有一种想法,这种想法基本可以总结为这样的结论:我们所作的一切事情,就是为了发现问题,或者更清晰的说,为了

定义问题。因为问题一旦被定义,就意味着其解决方法已经非常清晰。我们不能解决问题的根本原因在于我们对问题认识的还不够

深入,我们还不知道问题是什么。

今天本来在看《你的灯亮着吗》,对里面提出的几个问题颇有感触,想到了一个问题:软件为什么会有bug?
wiki上对software bug给了一些解释

但是这不能满足我的需求,那么,为什么软件会有bug呢?
这个问题应该是谁的问题?
1. 程序员
2. 开发经理
3. 需求定义制定者
4. 公司领导
5. 客户
6. 没有为什么,就是有bug

这是程序员的责任吗?人的认识总是有限的,我们不能等待对这个深入研究之后再动手,而是边做边发现问题,然后解决问题。也

就是说,在做之前,我们是不知道问题的,所以,出现bug其实是发现问题的一个基本方法。而在做之前,程序员是不知道这些问题

的。
是开发经理的责任吗?开发经理虽然有经验,有技术,但是并不是所有的业务情况都了如指掌,世界在变化,他之前的经验可能无

法用在这个项目上面,或者某些变化的地方没有考虑到,直到问题显现。也就是,他也没有办法去定义那些隐含的问题。
后面的类似,没有人知道问题会以什么样的形式出现,也没有人能明确定义项目可能出现的种种问题,所以,犯错是必然的,犯错

是发现问题的一个十分重要的方法。至此,我们不能做过多的要求了。


在《你的灯亮着吗》这本书里面,颇有一些非常有警示意义的言辞
1. 问题永远不会被明确定义,也不会被解决完毕,一个问题的解决必然带来另外的问题,我们要清楚问题是什么,而不是解决所有

问题,这似乎是bug mannagement的精髓。
2. 弄清楚问题的根源。
3. 这是谁的问题,不要试图解决不是你的问题。
4. 要让问题解决这感受问题所在,比如你要让老板知道你对薪水不满。


在看software bug的过程中,正好看到了关于arithmetic sub/overflow的问题,跟前段时间的实践结合起来,正好记录一下。


,这个里面提供了加减乘除的时候,检测sub/overflow的方法。
其中的这三项原则还是有些作用的
   1. Cast the numbers to a bigger integer type, then do the addition there, and check if the result is in the

right range.
   2. Do the addition normally, then check the result (e.g. if (a+23<23) overflow).
   3. Check before adding whether the number you add can fit (requires knowledge of the maximum value for that data

type)
关键不是如何做,而是决定是否要做,这很重要。方法总是很多的,关键是问题需要解决吗?问题有没有被定义错误?我们需要处

理这种溢出吗?
abs也会有风险,比如对于abs(0xffffffff)=0xffffffff,因为abs做的是取反加一,由于溢出,则正好回归本身。就出错了。


还有就是小数相乘的时候,可以是用log来避免精度损失,比如
a*b = exp(log(a)+log(b)),但是log和pow都是耗时的操作,所以我们可以使用
frexp进行拆解,将小数拆成significant和exponent两个部分,然后使用ldexp来合并,速度大概是log和exp的三倍左右

,这里也有讨论,可以使用更多的

方法,比如GMP库,比如专用的CPU等
阅读(508) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~