狗狗的日记本本

路上偶遇，可惜不是个小萝莉~~~~要不然这张照片就完美了。

化雪后初晴，公司路旁的小吃店的员工们堆得小雪人，很有爱。

可惜脏了点儿，发现黑白后舒服多了，于是就按辛德勒处理了~~~~

重新来，把2003年没干完的活儿干完！！！

现在有了GOOGLE CODE和GOOGLE的翻译者工具，加上自己的英语6级都过了，木啥好怕的了。

在GOOGLE CODE上开一个项目，把这篇又臭又长的东西翻译完。

DJGPP FAQ IN CHINESE

2003年时候翻译的FAQ列表，今天有个搞DOS 32位开发老男人弄到我QQ来问我，我挺开心的。6年前自己翻译的一篇小东西，竟然对别人的工作有帮助。

重拾了当年在DELL机器上装LINUX装DJGPP，装WIN3.1，玩GCC的欢乐感觉。

决定没事情了，陆续把DJGPP这个项目的文件翻译补完。

2003年那年最欢乐的事情是，有个大学教授发文过来问我怎么用DJGPP交叉编译，实际上我直到2006年才懂得什么叫做CROSS BUILD~~~哈哈。当时觉得自己特牛X的感觉~~

不过是6年前而已，却好像是上个世纪的事情了~~~~

前一篇文章有很多错误，所以更正一下。

如果是基于用户的协同过滤，使用勾股定律的那种空间距离算法。

THE ART OF THE START     INFORMATION RULES

BOB 8 7

SARAH 6 9

计算得BOB和SARAH的近似度为：根号下，|8-6|平方+|7-9|平方，得2.83.

这是基于用户的协同过滤的基础算法，也就是说，即使BOB给THE ART OF THE START打了2分，协同过滤也会把同样打了两分的人挑出来的，毕竟他和BOB之间更为臭味相投。同样地讨厌THE ART OF THE START这本书，都给了差评。（从几何距离上来说，差评用户和差评用户之间的距离较近）

基于用户的协同过滤从算法上就已经考虑了差评用户之间的臭味相投。

但还是因为上一篇所说的问题，协同过滤的计算量太大，尤其是基于用户的协同过滤。10万用户和10万本书的计算量是150亿次。在SCOTT WHEELER的文章中引用了术语：“维度之咒”，很形象地描述了这个算法的瓶颈。所以商业应用的协同过滤都需要海量的分布式计算。

文章最后提出了机遇【有向图】的更易于理解的一种实时算法，这种算法无需离线计算，按原文的说法，是一个冷门儿的推荐算法。

===============================

PS:

1、SCOTCHI.NET

2、DIRECTEDEDGE.COM

没有机会进入豆瓣，但起码有机会去看Mahout的推荐算法。NETFLIX的推荐算法已经是神经网络算法了，复杂让人难以理解。

实际上亚马逊的算法也不难理解，简单地说还是相似度算法。业界常用的算法有

1、基于用户的邻近度比较

2、基于物品的邻近度比较

最基本的数学算法其实就是余弦。和搜索引擎算相似度实际上很类似~~算法本身不难理解，但难点在于运算量巨大。所以MAHOUT这个系统大量的问题在于解决分布式计算，计算本身并不复杂，恐怖的地方在于计算量，连贝叶斯都不需要。

10万本书和10万用户的计算量就过亿了。所以都是这种计算都是离线运算，排出距离（最近的距离，或者说是逆序）前十的用户是很简单的事情，而排出距离最远的前十用户并不增加什么计算量。如果计算后的值储存的好，得到两种迥异的结果就仅仅是查表而已。

MAHOUT还使用了K邻近算法，那部分我一直没有去摸索。就不表了

====================

PS:关键是豆瓣的算法是什么，只有豆瓣的人才知道。

如果有兴趣的话，推荐程序员最近一期上有一篇译文，专门讲解推荐算法，当然作者自己还发明了一种基于【有向图】的算法。