今天没有及时更新技术博客，但是游戏博客却更新了，emmmmmm
因为这道题有点tmd难啊，虽然难度已经写了很难，但是初看上去其实没那么复杂，只要逐步构建合并的新数组，就可以得到中间值嘛，但是题意要求了时间复杂度。这就尴尬了，笨方法是不行的啦（其实本来也不会用那么蠢得方法）。于是我就从昨天下午开始研究我很新奇的一个想法，一直研究到今天下午，我单方面的觉得这个方案应该是失败的。但没关系我们从中可以总结出一个新的方案。先来贴原题
我一开始的思路是，中位数，归根结底就是排序好的数组的某一个位置的数，是很好找到的，但是能不能不创建第三个数组就查找到这个组合后的中位数呢，我开始的尝试是这样的，我们最笨的方法肯定是从左向右构建新数组，直到我们找到中位数哪个位置，停止。但我们如果从中间开始找呢，假设中位数在x位，我们对比两个数组的中位数，然后将其中一个数组的中位数插入到另一个数组中，这样我们就从中间合并了两个数组，但有同学就说了，我们只合并了一位而已啊，是的我们只合并了一个数字，但我们可以根据这个合并成功的数字的位置去向x位推进，这样肯定比从左边构建要少（至少也要少一位）。
但这个方案我前面也说了，有问题，当我codeing到中后阶段的时候我发现，他的分支太多了，我是用的方式是先选中两个数组的中位数，然后移动位置，直到确定一个数在另一数组的插入位置（代码表示就是这个数大于左侧，小于右侧），然后判断插入位置和x位的方向和距离，进行较短的构建，然而我开始写判断情况的时候我发现，比如 [1] [2,3,4,5] 当你比较完所有的数字 你发现1就是最小的，或者[1234][5] 这个测试用例5就是最大的，这个逻辑对很多特殊情况支持的都不好，时间都会很长，进过一下午的死钻，我决定使用一个新的方案，将我今天的想法先放下，先用二分查找确定一个插入位置，然后老老实实构建，但今天这个方案我做完这道题一定要回来验证他到底是否可行，如果他可行的话，我觉得在大部分情况下，都会比其他算法速度更快。
那好啦未完待续我明天尝试新想法
day2传送门：http://cheert.com/index.php/BlogDetails/index/id/130
day3传送门：http://cheert.com/index.php/BlogDetails/index/id/131