前言

  浮点数因为它的独特的表示方法，造成了比整数表示复杂的多的情况。而在程序中却不得不经常跟浮点数打交道。最近在看《深入理解计算机系统》，于是就想把与浮点数相关的东西整理出来，方便以后翻阅。

前言

  Marshmallow，也就是Android6现在对于我们来说也是古老的东西了，所以在编译就会遇到各种版本问题。于是就想写篇文章，把遇到的坑记录下来。

前言

  前不久准备写一个关于文本处理的小程序，需要高效地对文本进行读取。于是就归纳了一下常见的文件读取方法，并测试了各自的时间，也阅读了相关的一些源码，希望能说清楚测试结果背后的道理，在以后用到相关操作时，能选取最佳的方法。为了减少一些无关的干扰，我们把源码里的一些检验参数等的代码省略，有些代码进行了简化。

这篇博客的由来（瞎扯）

  我在学习机器学习的时候，发现网上很少有对XGBoost原理探究的文章。而XGBoost用途是很广泛的。据kaggle在2015年的统计，在29只冠军队中，有17只用的是XGBoost，其中有8只只用了XGBoost。于是只能自己在网上找资料，幸而XGBoost的作者陈天奇在arixv上发布了一篇关于XGBoost的论文，于是就有了这篇博客。这篇博客首先将回顾监督学习，给出它的通用的优化函数。然后介绍回归树，它是XGBoost里的得到的最终模型的基本组成单元，许多棵回归树组成的回归森林就是XGBoost最终的学习模型。进而为了构造回归树，介绍了gradient tree boosting。从而引出了两种算法，一种是用于单线程的贪婪算法，一种是可以并行的近似算法，并作了结果的对比，显示出近似算法比较高的精确性。最后将介绍XGBoost的用法。

问题简述

  欧几里得旅行商问题是对平面上给定的n个点确定一条连接各点的最短闭合旅程的问题。下图a给出了一个7个点问题的解。这个问题的一般形式是NP完全的，故其解需要多于多项式的时间。

  J.L.Bentley建议通过只考虑双调旅程来简化问题，这种旅程即为从最左点开始，严格地从左到右直至最右点，然后严格得从右至左直至出发点。下图b显示了同样的7个点问题的最短双调路线。在这种情况下，多项式时间是可能的。

  描述一个确定最优双调路线的$O(n^2)$时间的算法。可以假设任何两点的$x$坐标都不相同。

摘要

  很多的推荐系统使用协同过滤技（CF）术向用户推荐相关事物，该技术是基于用户之前的浏览历史，购买记录或评价。大部分协同过滤技术主要解决两个主要问题。这两个主要问题就是用户资料的可扩展性和稀疏性。本文，我们将会描述加权正则化交替最小二乘法（Alternating-Least-Squares with Weighted-$\lambda$-Regularization，ALS-WR）。它是我们为Netflix Prize(一个大规模协同过滤挑战)设计的并行算法。我们在linux集群中使用并行Matlab作为实验平台。我们将进行实验得出一个结论：ALS-WR的性能会伴随着特征值数量和ALS迭代的增加而增加。ALS-WR应用多达1000个隐藏特征的NetFlix数据集，可得到一个0.8985的RMSE分数，这个得分是基于单纯方法获得的最好的得分。结合其他并行版本的方法，我们获得了比Netflix自身的CineMatch推荐系统高出5.91%的性能。我们的方法是简单的，对于很大的数据集的缩放也是表现很好的。

引言

  对于网络接入费用，现今存在着两种比较普遍的收费模式，一种是统一费率（也就是所谓的包月制，每月$g$元，不限时间和流量）。一种是基于使用量，一般表现为基本费用加步进费用（也就是熟悉的手机上网套餐，每月固定$g$元，可以得到$q_0$的流量或者是时间，超出$q_0$的每个单位收费$p$元，比如若按流量收费就每$MB$需要$p$元）。

  因此本文将会对这两种网络接入收费模式进行分析讨论，比较他们两个的特征，并且站在社会福利的角度说明它们对网络资源的浪费，然后阐明基于使用量进行收费的优势不在于收费系统本身而是在于网络资源的不足。也就是说在社会福利的角度上来说，如果通信技术的发展能提供无限的的网络资源，那么还是统一费率优势大。后面也站在其他角度，对它们两者进行了比较分析。最后对步进费率的步进长度的选择给出一定的理由。

搜索引擎架构

  在进入PageRank之前，我们先看一下一个典型的搜索引擎架构是长啥样的。下图是98年google创始人拉里●佩奇提出的原始的google的架构。

  一个典型的retrofit+Rxjava的网络请求如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Subscription subscription = videoChartService.login(newBody)
                .observeOn(AndroidSchedulers.mainThread())
                .subscribeOn(application.defaultSubscribeScheduler())
                .subscribe(new Subscriber<LoginResponse>() {
                    @Override
                    public void onCompleted() {
                    }
                    @Override
                    public void onError(Throwable error) {
                    }
                    @Override
                    public void onNext(LoginResponse loginResponse) {
                    }
                });

  我们知道如果成功我们可以从onNext里的Response里面来取出返回来的body。但是如果失败了，如何取出返回来的body呢？？

依赖注入的概念以及作用

  依赖注入的概念不是Java所独有的。但这篇文章将从Java的角度来学讨论依赖注入。其实依赖注入不过是控制反转的一种实现方式而已（另外一种是依赖查找）。别看控制反转这个词语很高大上，其实这只是许多轻量级的容器在连接各个模块所采取的一个普遍的模式。它其实就是实现了控制权的转移，把控制权从程序代码本身移交到外部容器而已。