原帖由
hax 于 2009-9-22 14:01 发表
QUOTE:
原帖由 css8 于 2009-9-22 11:49 发表
本书有错误码？
有，hax帮助指出了，其中几个确实存在错误，在此再次表示感谢。
但是，如hax所言，错误随处皆是吗？
这个就未必了，hax的言论未免让人感觉危言耸听。
我统计了hax指出的所谓31处错误，真 ...
请你查阅一下《JavaScript高级程序设计》第2章，如果你没有书，告诉我，我复印给你看看。
我本来不想再来跟你说什么。不过你还要强词夺理，我就奉陪一下。
看看原文：
The interesting thing about this form of floating-point literal is that it is actually stored as a string until
it’s needed for calculation.
（这一段是斜体，也就是作者作为轶闻说来听听）
我先姑且不论Zakas说的对不对（因为literal是否是保存到计算时再处理，还是预先就处理掉了，其实是由引擎决定的，而且我断言，现在的主要引擎肯定是预处理时都处理掉了，有看过spidermonkey,javascriptcore,v8源码的同志请验证一下），就算我推断错误，他说的没错，但人家讲的是literal啊。literal是什么你搞得清楚不？
请读wikipedia:
http://en.wikipedia.org/wiki/Literal_%28computer_science%29
看不懂英文，可看我这篇（放心，免费滴，也无搭售什么求职秘笈）：
http://hax.javaeye.com/blog/160003
如果说Zakas的说法还是有点容易引起歧义，但是人家马上在同一页的下方特别用不同背景色且粗体标出：
Floating-point values are stored in a 64-bit IEEE 754 format, meaning that decimal
values can have up to 17 decimal places. After that, the values are truncated, resulting
in small mathematical errors.
好吧，我猜想可怜的css8也许是看了错误的译本导致犯下这样低级错误。
可是我找到译本（
http://book.csdn.net/bookfiles/110/1001103362.shtml）一看，人家明明翻的是：
浮点字面量的有趣之处在于，用它进行计算前，真正存储的是字符串。
这句话虽然翻译的不太好，但是至少没把Zakas的意思弄错。
所以，结论只能是：css8自己的问题。
css8本来只是自己一个人犯错，你虚心求教一下，这里的所有人都会为你解答，没有人会笑话你。然而你现在要写书去以讹传讹，散播低级错误，别人指出了，你还要百般抵赖，甚至反戈一击，我看你好容易积攒下的人品估计这次要毁于一旦了。不过这是你自找的。
说我百般抵赖也好，说我人品不好也罢。说得不对的为什么不让争辩，我前面已经声明了个人立场：hax指出的几个错误，我可以接受，但是，凭什么说我要接受你的所有无理指责，这是什么世道，51js不是黑帮，为什么还要指责无辜劝和的版主。
咱们先搁置人身攻击，放下个人成见，就技术问题进行论坛。真理是越辩越明的，凭什么说争辩人，就是人品不好。
下面想与hax辩论的技术问题是：
浮点数的存储问题。（请你不要笑话，也不要过于自大）
第一，关于浮点数的存储理论，大家可以看看这两份参考文献，你也可以检索一下或百度一下。
基于IEEE 754的浮点数存储格式分析研究
http://blog.csdn.net/xautfengzi/archive/2008/08/07/2783192.aspx
基于IEEE 754的浮点数存储格式分析研究（摘自朱老师博客）
http://yerkdger.bokee.com/5644225.html
第二，关于浮点数的存储位置问题。
浮点数在c语言中是以ieee格式存储的，一个浮点数占用四个字节，例如，浮点数34.526存为（160，26，10，66）这四个数。要
将一个浮点数存入
eeprom，实际上就是要存这四个数。那么如何在程序中得到一个浮点数的组成数呢？
浮点数在存储时，是存储连续的字节中的，只要设法找到存储位置，就可以得到这些数了。可以定义一个void的指针，将此指针指向需要存储的浮点数，然后将此指针强制转化为char 型，这样，利用指针就可以得到组成该浮点数的各个字节的值了。具体程序如下：
#define uchar unsigned char#define uint unsigned intvoid ftoc(void)
{ float a;
uchar i,*px
uchar x[4]; /*定义字符数组，准备存储浮点数的四个字节*、
void *pf;
px=x; /*px指针指向数组x*/
pf=&a; /*void 型指针指向浮点数首地址*/
a=34.526;
for(i=0;i<4;i++)
{ *(px+i)=*((char *)pf+i); /*强制void 型指针转成char型,因为*/
} /*void型指针不能运算*/
}
如果已将数存入eeprom，要将其取出合并，方法也是一样，可参考下面的程序。
#define uchar unsigned char#define uint unsigned int
void ctof(void)
{ float a;
uchar i,*px
uchar x[4]={56,180,150,73};
void *pf;
px=x;
pf=&a;
for(i=0;i<4;i++)
{ *((char *)pf+i)=*(px+i);
}
}
（上面描述引自：
http://topic.csdn.net/t/20050718/09/4150744.html）
第三，在JavaScript中，浮点数的存储处理。
在JavaScript中，浮点数与字符串一样被存储在堆栈区域。eeprom表示的意思就是一种可读写的存储器。
而字符串与浮点数都被存储在堆栈区。本质上，它们是相同，通过变量引用，引入计算。
第四，关于《JavaScript高级程序设计》中的描述“浮点字面量的有趣之处在于，用它进行计算前，真正存储的是字符串。”，也是可以理解的，并非hax所言，这个结论靠不住。
我先姑且不论Zakas说的对不对（因为literal是否是保存到计算时再处理，还是预先就处理掉了，其实是由引擎决定的，而且我断言，现在的主要引擎肯定是预处理时都处理掉了，有看过spidermonkey,javascriptcore,v8源码的同志请验证一下），就算我推断错误，他说的没错，但人家讲的是literal啊。literal是什么你搞得清楚不？
仔细分析hax的观点，其有两个支撑基点：
1，认为字面量（literal）在预处理时已经计算。
2，引擎的解析方式决定了字面量的存储方式。
这种观点存在的问题：
1，不管字面量在什么时候处理，它都是要存储的，请问它的存储位置在哪儿？
2，不同的JavaScript引擎，其解析机制肯定不同，无可争辩，但是它们都遵循IEEE标准，这个事毋庸置疑的。
第五，根据hax的观点，字面量与浮点数是两个概念，不是一码事。
是的，字面量与浮点数是两个概念。但是它们也仅是概念上区分，本质上都是对数据的描述。
以上是我的个人观点，也可能存在认识上的错误，或者推理上的逻辑错误，或者曲解了hax的意思。但是，这些都不要紧，争论的本质是要证明真理，不管谁对谁错，先请个别人不要到处扣帽子，以人品论事儿。
[
本帖最后由 css8 于 2009-9-22 23:52 编辑 ]
