Frank Dai

恩，好，分布式调度系统，分布式文件系统，等，都是学术界研究了多年的东西，有一些成熟的开源项目或论文了，可以选择一个好的去实现。 例如， - 分布式调度系统有 [Sparrow](https://github.com/radlab/sparrow) - 分布式文件系统，就更多了，Linux上的Ceph, Lustre；OpenStack 里的Swift；Hadoop上的HDFS - NoSQL数据库，耳熟能详的有redis, MongoDb, Cassandra等 可以重新实现轮子，但是不可以重新发明轮子 :)

恩，你说的有道理，2相比3，完全没优势，不过我的意思也不是方案2，不是完整实现Spark，而是实现它论文里的RDD，这个是Spark的核心，比MapReduce 抽象程度高，表达力更强，性能也高。 我的重点关注的问题是，编程接口，即抽象工具。裸用MPI, socket之类的API来写分布式算法，太麻烦太容易出错了。就像设计一门新语言一样，编程范式是最重要的，性能什么的可以慢慢优化。 做一个分布式算法，我所了解的编程接口有： 1. MPI，这种方法比较底层，编程繁琐，类似于C语言至于Java语言。目前有人提出了MPI的改进版，把接口变得更易用了，[MPI-D](://datampi.org/)，但是抽象程度依然不高。国内的公司例如百度，目前基本还是用MPI，因为他们人多，可以慢慢写。Google估计是在用MapReduce的下一代吧 2. Map-Reduce，比较成熟的实现是Hadoop。这个抽象工具比较不错，Mahout基于Hadoop实现了一些算法，但是，已经证明有些机器学习算法不适合用Map-Reduce来表达，Mahout 0.9相比0.8，就少了几个算法，官方的说法是用mapreduce无法写出高性能的实现，就去掉了，见首页原文： > As the project moves towards a 1.0 release, the community is working to clean up and/or remove parts of...

我在知乎上开了一个讨论贴子，[写分布式机器学习算法，哪种编程接口比较好？](http://www.zhihu.com/question/22544716)

Hi 非常感谢， 格式方面，你增加了三道题，但是没有与本书集成，是独立的一个pdf，你能否再组织一下，集成到书中的某一章节？ 内容方面，等我有空看一下这三道题是否经典。

感谢找茬，要多多找茬，我有时间会仔细看一下:)

这个技巧是跟编译器相关的，因为C++标准没有规定负数除法，所以不同的编译器是不同的 现代的gcc , vc的等编译器尽可能与主流保持一致，所以我的这个技巧已经过时了 On Friday, August 8, 2014, yinwuzhe [email protected] wrote: > 作者你好，我刚刚看这本书，对于第一章说的一点有点怀疑 > “判断一个整数是否是为奇数，用 x % 2 != 0，不要用 x % 2 == 1，因为 x 可能是 > 负数。”...

感谢，我抽时间看看。

好，我待会儿看一下:)

Reading line by line is very important, for example, `flate2` can read `.gz` files line by line: ```rust let f_in = std::fs::File::open("sample.txt.xz").unwrap(); let d = flate2::read::GzDecoder::new(f_in); let mut buf_reader =...

Do you homework, ```python ticker = yf.Ticker('AAPL220520C00055000') hist = ticker.history(peroid='max') ```