• 分布检验使用 lillietest 函数
• 自相关使用xcorr函数
  c = xcorr(x,y) 返回矢量长度为$2*N-1$互相关函数序列，其中x和y的矢量长度均为N，如果x和y的长度不一样，则在短的序列后补零直到两者长度相等。
  c = xcorr(x) 为矢量x的自相关估计。
  c = xcorr(x,y,'option') 为有正规化选项的互相关计算；其中选项为"biased"为有偏的互相关函数估计；"unbiased"为无偏的互相关函数估计；"coeff"为0延时的正规化序列的自相关计算；"none"为原始的互相关计算。
• 使用corrcoef函数可以求两个序列的相关度
  corrcoef（x，y）表示序列x和序列y的相关系数，得到的结果是一个2*2矩阵，其中对角线上的元素分别表示x和y的自相关，非对角线上的元素分别表示x与y的相关系数和y与x的相关系数，两个是相等的。

问题的由来

为了提高生产力，特别搞了个双屏（笔记本 LVDS + VGA），但是最佳分辨率是1280x1024的VGA显示器在archlinux系统里面最高分辨率只有1024x768。导致的结果就是显示出来的图像和文字都怪怪的，跟笔记本电脑显示器上面的大小不一致，这样一来眼睛就会非常的疲劳。

一路折腾

由于在KDE下的各种设置都没效果，所以本着不搞定这个问题不睡觉了精神，熬夜无数去追寻答案，试图搞出一个解决方案来。一路折腾，折腾得到了一些解答：

VGA连接上笔记本之后，没有被显卡驱动正确识别，显卡只知道又有个显示器连接上来了，能传输显示的数据，但是不能传输控制数据（控制显示器黑屏，获取显示器EDID信息等）。所以结果就是显卡按照1024x768的默认安全的分辨率输出显示信号，而系统里面对于VGA的显示模式，也只有最高1024x768的模式，所以KDE里面的display设置也就只能设置成了1024x768.

路上研究了下EDID，然后沿着「显卡驱动」「Xorg」「KDE」的途径一个一个“排查”。

路上先研究了下archlinux系统Xorg下面的ati显卡驱动，闭源私有驱动已经不支持笔记本上若干年前的老显卡了，而开源显卡驱动是支持的，而且archlinux上面还说了开源显卡对多屏(multihead)的支持更好。所以结果就是显卡驱动这方面不能干什么。

路上又跑去看Xorg的相干内容，发现「可以在KMS或者Xorg.conf文件里面增加自定义的EDID文件」，于是跑去了windows系统搞了个VGA的EDID信息。先试了下KMS里面添加EDID文件，结果没有反应。然后又试试添加了xorg.conf文件里面，试了几次，有的没有反应，有的直接不能进入X界面（KDE当然不能启动了。。）

最后路上去搞了搞KDE系统本身，倒是发现了display存储的显示配置信息（./KDE4/share/config/krandr)。不过发现修改这个文件也不起作用。

柳暗花明又一村 发现xrandr的强大

路上在各处追寻问题的时候，发现原来xrandr可以直接定义显示器的显示模式，然后试了试，感觉非常棒！
比如这篇文章就说了，如何在Linux下设置屏幕分辨率。简单讲步骤有这些：

1. 使用cvt命令生成VGA最佳分辨率的显示模式（1280x1024）

   $cvt 1280 1024
   输出：
   \# 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz
   Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync
   ’modeline‘这行就是我们下面要用到的显示模式 "1280x1024_60.00" 是显示模式的名字，下面我们可以重命名

2. 给系统添加1280x1024的模式

   #xrandr --newmode "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync

3. 将这个模式添加到VGA显示器的显示模式中，这样VGA就可以使用这个显示模式来显示内容了。首先使用

   xrandr

   命令获取VGA显示器在系统中的名称，路上的VGA显示的名称是VGA-0。然后执行：

   xrandr --addmode VGA1 "1280x1024"

4. 最后在KDE里面设置或者直接使用xrandr设置VGA显示器的显示模式

待解决的问题

但是，xrandr只能存在本次X session下，不会保存在系统中。所以重启之后...回到解放前..

解决方法上篇文章也说了，可以添加自启动脚本。但是在KDE下面添加的时候要注意的是，如果用KDE自带autostart添加，一点要选择在KDE启动之前执行（pre-KDE）。按照这种方法，成功为VGA添加了1280x1024的模式。但是上面提到的KDE配置信息不认，最后的结果就是恢复到了KDE桌面显示的安全模式（双屏输出，LVDS克隆VGA显示内容）。然后只能手动的在KDE设置下面更改分辨率和显示模式（这时候又1280x1024的选项）

所以最后的问题是：如何让xrandr的信息被保存下来并正确配置KDE。
上面的问题实际将xrandr配置信息直接写到自启动脚本去，然后让KDE去调用这个脚本就行。虽然这样显示器会出现闪烁，但是总比每次手动修改容易！

archlinux下（其实也不是archlinux的错，而是KDE之类的错，其实也不是KDE的错，是xorg的错。。。总之这个路上下回分析好了。。。）中文输入法一直都是一个蛋疼的问题，路上之前装的IBUS经过官方的配置指引配置之后，尚属还能用。但最近升级系统后，输入法框框不见了。。。表现出来是可以输入中文，但是不见输入法面板。我们姑且称之为IBUS的黑灯瞎火模式。

为了解决黑灯瞎火模式，有位具有非常探索精神的仁兄在2014.09月实践了安装和配置IBUS，同时也解决了黑灯瞎火模式，下面是他两篇博文的链接：

链接1: 安装IBUS
链接2: 解决IBUS的黑灯瞎火模式

他大致的思路就是在安装时在/etc/profile添加：

export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus

在~/.config/autostart文件夹里建立一个ibus.desktop文件并chmod 755 ibus.desktop，文件内容为：

[Desktop Entry]
Exec=ibus-daemon -xdr --panel=/usr/lib/ibus/ibus-ui-gtk3
GenericName=IBus
Name[zh_CN]=IBus
Name=IBus
Name[en_US]=IBus
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=
X-KDE-SubstituteUID=false
X-KDE-Username=

注意上面第二行 --panel=/usr/lib/ibus/ibus-ui-gtk3 是他解决黑灯瞎火的终极办法。这个语句的意思是指定IBUS输入法面板为/usr/lib/ibus/ibus-ui-gtk3，否则输入法面板将会变成kimpanel-ibus-panel，而后者很可能是黑灯瞎火模式的操控者。

不过好消息是，这个黑灯瞎火的漏洞应该会很快解决，因为有人3.4.2015在github上提交了bug和fix：
Re: IBus 1.5.10: new indicator does not show icons of some engines

而坏消息是：LibreOffice不能正常调用iBus，只能通过从终端使用命令行的形式启动后才可以正常输入。。

最近windows下面的svchost.exe因为windows update的关系在内存方面兴风做浪，一开机就吃掉了1GB内存。令人抓狂，禁用了windows update服务之后还是觉得这个系统越来越不舒服。想想最近这段时间使用windows也仅仅是上网、收发邮件、coding/matlab之类的活，对文档的编辑也仅仅限于word之类，游戏什么都基本没有碰，所以好吧，我还是切换回archlinux吧。

目前想到的是，code用eclipse代替好了（php、android都可以嘛）、office自然libre-office啦，其他使用svn之类的同步windows和archlinux下面的代码，文档就直接挂载windows分区好了。

不过archlinux由于经常不升级，所以升级老是出现问题，现在apper已经不能用了，只能吃豆人一下。

资源：

1. Archlinux 删除无用包 pacman -Rns $(pacman -Qdtq)

路上在网上瞎逛，忽然见得此文，特转载过来（如有版权问题请原创联系路上）

注：此文转载自此仁兄(2012.05)

1. 为Activity声明系统配置变更事件
   系统配置变更事件是指转屏，区域语言发生变化，屏幕尺寸发生变化等等，如果Activity没有声明处理这些事件，发生事件时，系统会把Activity杀掉然后重启，并尝试恢复状态，Activity有机会通过onSaveInstanceState()保存一些基本数据到Bundle中，然后此Bundle会在Activity的onCreate()中传递过去。虽然这貌似正常，但是这会引发问题，因为很多其他的东西比如Dialog等是要依赖于具体Activity实例的。所以这种系统默认行为通常都不是我们想要的。
   为了避免这些系统默认行为，就需要为Activity声明这些配置，如下二个是每个Activity必须声明的：

   \<activity android:configChanges="orientation|keyboardHidden">

   几乎所有的Activity都要声明如上，为什么Android不把它们变成Default的呢?

2. 尽量使用Android的API
   这好像是废话，在Android上面开发不用Android API用什么？因为Android几乎支持Java SE所有的API，所以有很多地方Android API与Java SE的API会有重复的地方，比如说对于文件的操作最好使用Android里面Context封装的API，而不要直接使用File对象：

   Context.openFileOutput(String); // no File file = new File(String)

   原因就是API里面会考虑到Android平台本身的特性；再如，少用Thread，而多使用AsyncTask等。

3. 要考虑到Activity和进程被杀掉的情况
   如了通常情况退出Activity外，还有Activity因其他原因被杀的情况，比如系统内存过低，系统配置变更，有异常等等，要考虑和测试这种情况，特别是Activity处理重要的数据时，做好的数据的保存。
4. 小心多语言
   有些语言真的很啰嗦，中文或英文很简短就能表达的事情到了其他语言就变的死长死长的，所以如果是wrap_content就可能把其他控制挤出可视范围； 如果是指定长度就可能显示不全。也要注意特殊语言比如那些从右向左读的语言。
5. 不要用四大组件去实现接口
   一是组件的对象都比较大，实现接口比较浪费，而且让代码更不易读和理解； 另外更重要的是导致多方引用，可能会引发内存泄露。
6. 用getApplication()来取Context当参数
   对于需要使用Context对象作为参数的函数，要使用getApplication()获取Context对象当参数，而不要使用this，除非你需要特定的组件实例！getApplication()返回的Context是属于Application的，它会在整个应用的生命周期内存在，远大于某个组件的生命周期，所以即使某个引用长期持有Context对象也不会引发内存泄露。
7. 主线程只做UI控制和Frameworks回调相关的事。附属线程只做费时的后台操作。交互只通过Handler。这样就可以避免大量的线程问题。
8. Frameworks的回调不要做太多事情仅做必要的初始化，其他不是很重要的事情可以放到其他线程中去做，或者用Handler Schedule到稍后再做。
9. 要考虑多分辨率
   至少为hdpi, mdpi, ldpi准备图片和布局。元素的单位也尽可能的使用dip而不要用px。
10. 利用Android手机的硬键
    几乎所有的Android手机都有BACK和MENU，它们的作用是返回和弹出菜单，所以就不要再在UI中设计返回按扭和菜单按扭。很多优秀的应用如随手记和微信都有返回键，他们之所以有是因为他们都是从iOS上移植过来的，为了保存体验的一致，所以也有了返回和菜单。但这不够Android化，一个纯正的Android是没有必须重复硬键的功能的。

微评：实际上此文还远远不够，其实这种“注意事项”问题，正是《代码大全》、《程序员修炼之道》、《程序设计实践》、《编程诛讥》之类的优秀书籍所针对和试图解决的问题。如果说编程本身是器，那么如何更好的编程则是道，对于道的探讨，已经是一个非常高的级别的。年轻的时候，总想抛去器直接学道，但是形如空中楼阁没有基础显然不会安稳，所以回过头看，任何道的学习，都是在器的充分掌握之后，慢慢由内自然滋生或者由外点拨出来的。这个过程，路上称之为悟。