技术手记

压缩 VirtualBox 下安装 Linux 的 .vdi 虚拟硬盘文件

Posted on by snoopy

之前虚拟机里装过一个 Ubuntu, 闲的蛋疼还装了 KDE 等一陀东西, 后来不想玩了折腾把不用的删掉 (主要是 KDE 及其相关, 还有升级内核留下的一堆 linux-image)

删除 KDE 我用的是 http://www.cnblogs.com/wangvsa/archive/2012/07/22/2603626.html 这个帖里提到的方法, 直接复制命令删除就行了, 不过粗看了一眼这一把应该也删掉了不少其他的依赖, 算了, 有要用到的时候再 apt-get install 好了, 另外也有类似 http://os.51cto.com/art/201001/176255.htm 这个帖里提到的用 apt-get --purge remove 移除某个核心库的方法, 但我没试.

删除多余 linux-image 用的是 http://blog.csdn.net/c9h8o4/article/details/6647220 这个帖里提到的方法, 简单实用. 用 dpkg --get-selections | grep linux-image 找到现在安装了哪些版本, 接着用 uname -a 看当前版本, 再通过 apt-get remove 的方式把不用的移除.

把多余的东西删掉后发现虚拟机对应的 .vdi 虚拟硬盘文件还是很大, 查了下说是在允许容量范围内, 动态扩展的 .vdi 容量会一直扩大而不会缩小, 必须手工做压缩. 搜了一堆方法后发现 http://www.kilobug.com/archives/624 这里说的最简单, 用了一下确实, 从之前的 14.1G 压缩到 5.67G (删了一陀东西也有帮助), 简单复述一遍:

1. 在虚拟机里把没用的磁盘空间置零 (这一步耗时比较长, 且没提示. 另外如果有权限问题记得前面加 sudo)

dd if=/dev/zero of=/zero.tmp
rm -f /zep.tmp

2. 关闭虚拟机

3. 执行压缩命令 (宿主机是 Win 或 Linux 都自行找 VboxManager 的路径)

VboxManager modifyhd /PATH_TO_VDI/name.vdi --compact

在搜索过程中发现其他几个看起来靠谱的链接, 记录供他人参考:
虚拟机是 Windows: http://city5.com/space/reannounce.asp?spaceid=344&announceid=517778
Linux 的复杂折腾法: http://cypromet.site90.net/blog/?p=41

读书笔记: 探索推荐引擎内部的秘密

Posted on by snoopy

看到别人推荐的, 在 IBM 发布的几篇推荐引擎的介绍, 不少干货, 先记录下

探索推荐引擎内部的秘密，第 1 部分: 推荐引擎初探
http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html?ca=drs-

探索推荐引擎内部的秘密，第 2 部分: 深入推荐引擎相关算法 – 协同过滤
http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy2/index.html?ca=drs-

探索推荐引擎内部的秘密，第 3 部分: 深入推荐引擎相关算法 – 聚类
http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy3/index.html?ca=drs-

// 现在写 blog 越来越不勤快了, 最近重看了一遍 Python 的官方文档, 又查漏补缺了好多点, 但是没做笔记, 怕是又会忘, 除了零散乱看还是要勤写, 自己重述一遍才算把看过的东西好好理解了, 之前写机器学习的东西又挖坑没填

为什么通过前端 .js 记用户日志会丢数据

Posted on by snoopy

在这个数据驱动的时代, 做什么事情没有数据光凭感觉是不可能了, 今年夏天开始接手新鲜事的策略, 先推日志的丰富化和标准化, 关于点击日志, 解决方法无外乎这么三种:

1. 在点击 url 串上带上丰富信息, 然后在后续处理的前端 (比如 nginx 或 apache) 上打印请求日志, 把请求日志汇总过滤得到想要的
2. 做点击跳转, 用户点击后先跳到自己服务器上, 然后由自己的服务器做重定向, 并记录这一次请求
3. 前端 JavaScript 监控用户鼠标行为, 并及时上报到服务器

这三种方法也分别有各自的优缺点, 当时分析的是

1. 这个必须要保证点击后还是跳到自己的服务器上, 否则跳出去的点击无法跟踪. 不太可能丢日志, 只是过滤会多道工序. 目测 Facebook 曾经是这样干的
2. 绝对完整的记录. 不过需要新增服务器响应跳转请求, 并且如果跳转服务挂了会让用户压根到不了 url 指向的地方. 目前所有的广告服务都是这样 (而且点击串加密), Google 的网页搜索很早就是这样, 百度跟 360 干上后也换成了这种. 根据度厂员工在新浪微博上跟别人的讨论, 即使是百度网页搜索那么大的量, 算上灾备最多 50 台跳转服务器可以搞定 (根据公开资料, 百度每天网页搜索量在十亿这个量级, 按搜索引擎页面点击率 30% 算, 每天至少三亿次点击跳转请求)
3. 可记录的东西非常多, 不仅仅是点击, 而且还有一些页面上的其他 js 行为 (如悬浮, js 展开元素等), 但是会丢 15%~20% 的数据. 跟 360 干架前百度的网页搜索用的这种方式, 刚看了下 FB 也是这种了

其他的优缺点都比较容易明白, 但是 js 模式会丢 15%~20% 的数据这个非常难理解, 之前我只听到 20% 这个比例, 但是没人告诉我为什么, 昨天跟死猫君说日志的时候他也提到他们那边用 js 记的日志也有 15% 的丢失率, 但是他也只是听说这个比例而不明白原理.

今天跟前端同学讨论, 终于搞懂了为什么是这样. 后端的思维是每发生一次事件就打一条日志, 所以极难发生日志丢失的问题. 而前端不能每发生一次事件就向服务器发请求打一次日志, 这样会带来很大的网络开销并拖慢用户的浏览器, 所以前端都是把要纪录的行为在用户端先缓存, 等积累够若干条或过了若干秒后才向服务器汇总上报, 如果在这个上报条件触发前浏览器崩溃掉, 那日志就没了, 或者用户关掉浏览器也会丢掉这部分数据 (据说有一些方式可以响应关闭事件并上报日志, 但具体方式不了解, 另外前端同学反馈 IE6 下丢数据现象更严重). 所以丢数据这事其实是用户流畅度体验和数据完备性的一个平衡, 如果让用户卡一点那丢失比例就低一点. 另外接 js 汇报日志的服务器压力也是一个要考虑的点, 因为如果真用 js 汇报, 那一定就不止点击这点数据了, 鼠标滚轮, 悬停等事件显然是能有都有, 服务器不一定扛的过来.

机器学习手记系列 3: 线性回归和最小二乘法

Posted on by snoopy

好几个月没再继续, 挖坑不填是不对的, 还是继续写手记.

线性回归

线性回归一般用来学习一维自变量和一维因变量之间的线性关系. 如果存在一维自变量 x, 同时还有一维因变量 y = f(x), 如果有一堆对不同 x 下 y 的观测值, 即 的观测对, 且如果 x, y 之间存在较明显的线性关系, 可以用 f(x) = a*x + b 这样的方程表示, 则可以用线性回归的方法学习出 a 和 b 的值, 同时估计这个拟合方法的误差 r.

扩展一下, 线性回归也可以指 y = a1*x1 + a2*x2 + ... + ak*xk + b 这样多维自变量和一维因变量之间的线性关系 (多项式里自变量的最高幂次都是 1), 同样也可以用回归的方式学出来里面不同的系数和常数项的值. 只有一维自变量的称之为一元线性回归, 否则是多元线性回归.

判断线性回归好坏, 一般就用平方误差和来描述, 其表达为 (f(x1)-y1)2 + (f(x2)-y2)2 + ... + (f(xk)-yk)2), 此值如果为 0 则说明自变量和因变量存在完全的线性关系, 否则是近似线性, 越小近似的越好. 这个东西看着有没有一点面熟? 其实就是机器学习手记系列 2: 离线效果评估里最后提到的 MSE 的非平均版本.

解方程法

假如输入样本存在绝对的线性关系, 即最后的误差为 0, 则问题变为解二元一次方程 (一元线性回归里的系数加常数) 或 N+1 元一次方程 (多元线性回归里 N 个自变量的系数加常数). 这没什么好说的, 直接对原输入直接求解就行了, 类似计算方法这样的课本上有的是解法, 做梯度下降或牛顿法乃至矩阵分解都可以解.

梯度下降法

考虑到绝大部分情况下不存在绝对的线性关系, 则问题可以变成怎么求平方误差和的最小值点. 如果是一元线性回归, 目标函数变为 g(a, b) = (f(x1)-y1)2 + (f(x2)-y2)2 + ... + (f(xk)-yk)2

我们的目标就是让这个目标函数值最小, 选定一组 的初始值, 然后求其梯度方向, 每次前进一个小步长, 再求梯度前进, 直到目标函数值不再下降, 说明我们已经走到了一个极值点附近, 终止迭代. 对一元线性回归, 梯度方向是对函数求偏导得到的向量方向.

另外需要注意的是, 梯度下降不一定能找到最优解, 可能会在某个局部最优解那陷进去就出不来了.

这部分更详细的推导请见参考资料里 “机器学习中的数学(1)” 一篇, 里面的公式和图做的很赞, 思路也比我清晰.

牛顿法

梯度下降一般遇到的问题迭代步长不好选, 选太小到极值点太慢, 搞太大又会在极值点附近时因为步长太大跳过去了.

牛顿法最大的贡献就是同时给出了梯度方向和迭代步长, 几乎是一步到位的求解. 方法同解方程一样, 对新的损失目标函数求解, 只是一次解可能还不够好, 需要多做几次迭代. 一般梯度下降可能需要上千轮的迭代, 而牛顿法几次迭代就能到极值点了.

最小二乘法

伟大的高斯同学提出并证明了最小二乘法是最好解答, 证明过程略… 直接看维基或百度百科上的原文吧 (数学不好伤不起).

应用

虽然这个方法看起来很简单粗暴, 但是很多时候变化确实就是线性的. 比如在很多论文和工业实践中, 大家认为同等质量的广告或搜索结果, 放在从上到下不同的位置上, 其点击率和位置的关系符合线性关系, 即 ctr(rank) = a*rank + b.

在六月的一次随笔杂记里, 提到了这样的问题:

如下式子里不同的阿拉伯数字只是一个符号, 实际表示的可能是其他数字
967621 = 3
797321 = 1
378581 = 4
422151 = 0
535951 = 1
335771 = 0

根据上述式子, 判断下式等于?
565441 = ?

假设每个式子最后做的都是加法, 并把字符 0~9 映射到 x0~x9, 则统计不同字母出现的次数就可以列线性返程, 可以将第一个式子表示为

x0*0 + x1*1 + x2*1 + x3*0 + x4*0 + x5*0 + x6*2 + x7*1 + x8*0 + x9*1 = 3

其他类推. 对这堆式子求解就可以得到不同数字对应的真实数值, 可以得到 565441 = 1. // 具体代码和方法下次给出

参考资料

* Wiki Least squares: http://en.wikipedia.org/wiki/Least_squares
* Wiki Mean Squared Error: http://en.wikipedia.org/wiki/Mean_squared_error
* 中文维基 最小二乘法: http://zh.wikipedia.org/wiki/%E6%9C%80%E5%B0%8F%E4%BA%8C%E4%B9%98%E6%B3%95
* 百度百科 线性回归: http://baike.baidu.com/view/449540.htm
* 百度百科 最小二乘法: http://baike.baidu.com/view/139822.htm
* 人人上的日志 幼儿园的题目和机器学习的关系: http://blog.renren.com/share/30314/13432269197
* 机器学习中的数学(1): http://www.cnblogs.com/LeftNotEasy/archive/2010/12/05/mathmatic_in_machine_learning_1_regression_and_gradient_descent.html

// 本文开写于 9.24, 拖到 10.26 才马马虎虎完成, 最后那个题的解也没写, 各种错乱后续再修改或补充吧

Win7 图标异常解决

Posted on by snoopy

上周某次有程序运行到一半挂了, 强制退出终止进程后屏幕颜色异常, 继续杀 explorer 并重启后恢复正常, 但是有程序图标挂了, 类似这样:

(图片来自百度知道, 后续答案也来自百度知道: http://zhidao.baidu.com/question/197765345.html)

百思不得其解, 最后在上面那个知道问答的非最佳答案里找到解决方法:

0. 先关掉其他的东西避免误伤
1. 打开一个命令行窗口
2. 在任务管理器里杀掉 explorer 进程
3. 在命令行里干掉 iconcache.db
* 注: cd 的 /d 参数可以改变驱动器, del 的 /a 参数可删除隐藏文件
cd /d %userprofile%AppDataLocal
del IconCache.db /a
exit

4. 重启 explorer 进程, 恢复正常

无聊理工男在面对浪漫时干的二逼事

Posted on by snoopy

今天在 http://zhoucaiqi.com/emlog/guoke-website.html 上看到对一个网站的介绍:

这网站的域名相当伤感，内容也很伤感。
整个网站只有一张静态网页。这网页只有一张孤单的图片，以及冷寂的一两句话。

里面说的是这个 http://www.guoke.com/ 网站, 点过去看了下, 确实很孤单落寞的感觉.

前面是浪漫, 下面是无聊理工干的二逼事.

先是 NetMD 同学说多好的域名, 果壳没买下来, 然后死猫同学矫情了下后说这些历史图是怎么截到的, 接着我无聊去看了下 whois 的记录, 找到如下信息:

Domain name: guoke.com

Administrative Contact:
Hu Yanlin
Hu Yanlin (admin@doeasy.com)
+86.1068469837
Fax: +86.1068467228
2-1-2105, No.27 Zengguang Road
Haidian Dist.
Beijing, CN 100048
CN

继续看 doeasy.com 这是个什么网, 发现是域名贩子, 立马觉得 guoke.com 是不是也是域名贩子弄的, 然后一开始那个文章只是在给这个域名做推广. 不过要真是域名贩子, 能做到这样也挺不错了, 又仔细看了下一开始那个帖, 发现是在 Twitter 上 fo 的一个深圳的 IT 工作者的个人博客, 应该是真的默默关注了这么久, 还是一个温暖的故事吧.

事情还没完, 关于 guoke.com 拥有者的地址, 好奇看了下是海淀区, 那个 Zengguang Road 是个什么地方呢? 用拼音打了下居然第一反应是 增广路, 这… 我好像图论学的也没有那么好吧, 再找了下是 增光路, 死猫君表示难怪这么熟, 原来就在他现在住的地方旁边.

无聊理工 + 2B 完毕, 随手一记.

2012全球架构师峰会参会简记

Posted on by snoopy

8.10 ~ 8.12 在深圳参加全球架构师峰会 (http://www.archsummit.com/), 回来也十来天了, 先把回来后记在 evernote 里的简记发下, 详细的后面跟着幻灯片展开下

杂
公司定的机票时间都太晚了, 走的时候上飞机没晚点, 起飞晚了一个多小时, 到深圳都晚上十一点, 到酒店也半夜一点
住的略偏, 在小梅沙, 这酒店算一般水平吧, 可以理解成规模大点的农家乐
吃的凑合, 会务的自助餐还是挺不错的, 就是人太多, 要么早点要么晚点, 不然排队排死人. 茶点我就第一天提前去偷吃了点, 剩下的都懒得排队了
会场是万科的总部, 很多地方设计的很精妙, 但是大梅沙离市区还是太远太远了

会
组织的还是挺不错的, 就是有时候几个分会场都想去, 无法分身
同声传译很赞, 也没有很外行翻出莫名其妙的句子来, 前面坚持听了几场英文的, 最后一场借了个传译器果然还是听中文要顺畅很多
腾讯是主赞助商, 发的东西很多, 公仔和衣服没抽到和领到, 其他的资料倒是都拿点, 腾讯在这方面的宣传做的挺好, 给的东西也比较下血本
其他有很多硬件 (比如 SanDisk 的企业用 SSD) 或平台型 (比如云存储) 的赞助商, 我不懂, 就随便看了看展台. 倒是有很多开发平台的赞助商, 比如天翼, 还有海豚浏览器也是赞助商, 我还没怎么弄明白开发平台这个生态圈怎么玩, 果然落伍了

学
大会场的几个 topic, Pinterest 那个没赶上, 老外吐槽中国网络状况倒是吐的挺狠也挺实在的, 包括多网不通, 还有 GFW, 只是八线机房是个什么情况, 电信/联通/移动/教育网/还有四个有啥?
搜索那个 session 讲的都比较虚, 扯了些概念, 搜狗的提出抓别人的搜索结果 (参考资料: 孟学一有关暗网数据挖掘的书), 一淘讲了些干货, 不过总感觉也没啥特别的, 是因为别的人都没做过或看过这么大的搜索引擎, 所以觉得有很爽的干货么?
大数据那个 session 干货比较多, EMC 上来介绍了一些基于 Hadoop 或 Map/Reduce 的框架, 都很赞, Yahoo 的 Nova 自动化调度数据和任务也做的很好, LinkedIn 对数据的处理方式也非常值得参考, Pinterest 最后讲那个数据库分片, 真的是把简单做到极致, 能不复杂绝不复杂, 能用钱搞定的事情没必要省那几台服务器钱结果把系统搞的巨麻烦

下
Day1
All: http://vdisk.weibo.com/s/ajLUe

Day2
上午: http://vdisk.weibo.com/s/au-u-
下午主会场 (海量数据): http://vdisk.weibo.com/s/av8ue
下午分会场 1 (移动互联网): http://vdisk.weibo.com/s/aveIJ
下午分会场 2 (安全): http://vdisk.weibo.com/s/av5bn

Day3
All: http://vdisk.weibo.com/s/aAaQ3/1345032030

Chrome 多用户分别建快捷方式

Posted on by snoopy

Chrome 从今年年初开始在 Dev 版支持多帐号, 当时用的很爽. 最近 Dev 版解析 .js 老出错, 导致无法正常上人人和看视频, 严重影响工作和娱乐, 响应大家号召改回 stable, 结果发现多帐号是支持的, 但是怎么也找不到如何建特定帐号的快捷方式, 网络上搜的方法都只对老版本的 dev 分支有效.

今天找了另一台机器, 上面有多用户且分开建了快捷方式的 Chrome Dev, 看了下快捷方式, 把快捷方式的目标改为下面这样就行了 (红色是要添加的)

C:\Users\snoopy\AppData\Local\Google\Chrome\Application\chrome.exe –profile-directory=”Default”
C:\Users\snoopy\AppData\Local\Google\Chrome\Application\chrome.exe –profile-directory=”Profile 1″

读完了数学之美

Posted on by snoopy

正如上一篇日志中提到的, 最近买了吴军博士的数学之美并利用晚上的时间在看. 粗粗的过了一遍, 把以前很多没明白的东西给理顺了下, 具体的一些数学推导没来得及去验证. 书的后半部分感觉比较凌乱和随意, 不过还是值得购买去支持的, 如果大家都不买书, 那以后也会越来越难读到经典之作.

读的过程中用手机简单记了些简单的笔记, 现在回头想想, 再过一下:

方法论

1. 做事要简洁高效: 简单粗暴的方法, 只要是对的那就应该这么做, 与其花非常大的代价弄一个貌似完美的系统, 最后还不一定能保证结果, 还不如花很短的时间去做一个能达到 90% 性能的可用系统, 并用若干个 90% 性能的系统组合起来达到完美效果. 这一点也是我非常认可和坚持的, 在团队里也需要贯彻下去.

2. 凡事都需要可解释: 做策略做算法, 一定要对每个 case 给出合理的解释, 这样才能知道怎么去改进. 吴军在书里举的例子是说搜索, 一开始要用简单高效的系统和特征来保证鲁棒性和可调试性, 其实在计算广告和推荐系统里也是一样, 只是我们现在总会一上来就弄很多复杂的上去, 导致很难调试和追查, 最后就一把烂账怎么也算不清. 这点上自己一直做的不好, 要好好注意.

3. 真理应该拥有简单漂亮的描述: 自然真理的本质描述往往是很简单的很漂亮的, 如果搞的太复杂, 就不太对头, 多半是方向都错了. 书里的例子是说描述太阳系的行星运动, 地心说的模型需要用 40 层圆周修正, 日心说则可以降低到 8-10 个圆周修正, 但最后的真理却是一个椭圆方程就完美解释.

具体案例

1. 新闻/文本分类中的加权. 在做余弦相似度计算时, 需要考虑位置加权, 词性加权等影响. 对于位置加权, 一般的思路都是对树形结构做加权, 比如普通文章的标题/摘要等, 网页则一般是 HTML 语法树的加权, 实际上 Google 在很早之前就开始模拟网页渲染, 做物理位置的加权, 而这一套网页渲染的技术, 用来开发 Chrome 不是正好? 而且随着 Chrome 的市场占有率上升, 也可以逼迫高质量网站的网页代码会更标准, 至少是可以兼容 Chrome 的标准, 这样 Google 可以获得更准确的页面渲染效果并用于权重计算, 现在很多别的公司也开始关注浏览器, 但是不知道有没有想到这一层用法. 词性加权这又回到 NLP 的基础建设上, 果然做互联网, 要做精做深, NLP 是个绕不开的大坑, 就算数学模型如此优雅和有用, 但还是需要有基础数据才能去计算.

2. Logistic Regression 在工业界的广泛应用. 自己好像在生产环境中就用过这一种模型, 接触过线性回归和 Naive Bayes, 但是都没能去深入理解, 其他 boosting 和 SVM 等方法, 每次都是听了个大概, 一直没空去试. 根据自己的经验, 以及吴军的说法, LR 最大的优点是线性叠加, 皮实耐操以及水平扩展性好, 这几个都挺符合方法论的. 不过在点击率非常低的环境下, 要用好 LR 确实很难, 吴军说的是特征权重在 [-6, +6] 区间才有意义, 按 Sigmod 变换函数 1/(1+exp(-z)) 计算, -6 对应的也不过是 0.247%, 这个点击率在搜索广告以外的很多地方还是挺难达到的, 加上位置, beta0 等修正后可以让值很接近, 但是精度又受很大影响, 之前想过把某个小区间做放大处理, 但是一直没想清楚到底要怎么扩, 怎么能维持相对关系并可以还原, 求指点.

随笔杂记

Posted on by snoopy

有一些比较糙的想法, 没有成型, 随便记录下

大公司病和用户基因

主要内容来自新浪微博 @纯银V 的博文 腾讯抄你怎么办. 里面有挺多非常值得参考的观点, 吐槽大公司的各种弊端让人看的非常爽, 强烈推荐.

其中有一段在说 “用户基因”, 大意是在网易里想做一个摄影社区, 为了利用好网易庞大的已有用户量, 任意往里倒资源, 就会让用户群鱼龙混杂, 最后完全做不下去, 还不如一直走兴趣相投的精英版路线. 这样的例子比比皆是, 比如百度知道和知乎, 就是完全不一样的定位和用户群, 哪怕一开始都想定位于精品问答, 而知道绝对还是会发展成大众化问答且质量参次不齐. 其实这应该也是百度一直比较难做出什么精品产品而非大众产品的原因, 偏偏百度做大众产品成功运气的成分更大点 (比如知道和贴吧), 很多时候是想做精品产品而因为用户基因的关系而悲剧掉 (比如百科绝对没法像维基那样精品化, 只能是不那么严谨的大众科普加一些好玩搞笑). 从这个结论出发, 如果是在有很多用户基础的公司内做新产品, 路就两条, 一是做小众精品, 尽量不要用公司资源, 免得导入大量低质用户, 二是老老实实做平民产品, 利用已有用户资源且应对各种坑爹的奇葩. 是不是突然觉得有哪里不对? 如果走第一条路, 那为什么还在个大公司里做呢? 还不如直接出去创业, 反正做事都一样, 还免得大公司各种条条框框限制, 比如风车. 除非这个公司的已有用户也都是高质量用户, 如豆瓣的很多新产品.

回归模型和在线学习

一开始还是一个微博上的问题, 说幼儿园的题目大人不会解, 找了个样例是

967621 = 3
797321 = 1
378581 = 4
422151 = 0
535951 = 1
335771 = 0
565441 = ?

一般都是列方程求解, 但其实这也是个挺好的回归模型应用例子, 打算下次写机器学习手记的时候就写这个. 我人人上的好友写了一篇 幼儿园的题目和机器学习的关系, 我分享的链接后还跟别人讨论了下在线算法和离线算法的差异. 其中提到一些很有意思的观点, 就是 online 的更新算法会因为只在继续拟合新样本而不管原来样本的拟合, 会导致结果的抖动很大, 这是其在跟 batch 方法比较时的缺陷, 但换个角度看, 正因为 online 的方法没有受到历史数据的约束, 反倒可以更快的响应新数据的变化. 最后那个响应的问题, 也许可以在现在的工作中用起来, 最近就一直被新数据响应和数据短期内剧烈变化所困扰.

数学之美

吴军博士在浪潮之巅后的又一部经典之作, 把以前谷歌黑板报上的系列文章重新整理加补完, 前几天在京东上买了这本, 正在看, 强烈推荐.

希望读完后能有一些笔记性的东西出来, 这里先记一下. 第三章 2.2 节讲到对低频样本出现的潜在观测误差的处理, 用平滑或做折算的方式降低抖动可能, 这个想法也非常赞, 在最近的工作中应该也可以用起来, 实际上之前做过的某事情已经就在用类似的方法, 只不过思想和折算方法不太一样罢了.