关于Softmax的一些想法

考虑softmax = e^{x_k} / \sum e^{x_i} .

如果令y=e^x的话,则是一个较为一般的形式:
softmax = y / \sum y_i.

更一般的,假设y>0的话,则其实是一个类似percentage的东西.

比如y是一个投资份额/资金比例,那么\sum y就是每个个体的资本之和.
也就是总资本.

所以本质上来说,这种情况下更类似于一种dimension contribution的衡量方式.

那么,如果 考虑下数据分布呢?

一个极端的情况就是y=y_c,也就是所有y具有同一个值.
也就是说每个dimension的contribution区分度不会太大.

宽松一点来说,如果 y的variance的不大的话.
那么softmax的值也不会有太大的偏差.

再考虑一种情况.
即对于y来说,存在两个value group,y_a和y_b.
且y_a << y_b,或者宽松一点,y_a < y_b. 如果整体\sum y比较大,或者dimension比较多. 那么即使是y_b/ \sum y 的值可能也不会比 y_a/ \sum y的值来地更显著. 但从数据分布的人工直觉上来说,y_a和y_b的 contribution应该是存在有区分度的. 所以,单从这个角度来说,softmax对于高维度的feature vector来说,可能并不是一个很好的选择. 或者从某个层面上来说,更适合于一组互斥的feature set或者说classification/category. 如果去掉y>0的约束呢?

如果允许y<=0的话,那么直觉上就不太能将之于contribution做关联/联想了. 考虑坐下变化. softmax=y / \sum y_i ->
softmax = (y/n) / mean(y)

对于给定的数据来说,n和mean(y)可以认为是一个常量.
那么这样的话,softmax实际上就是一个对于feature y的scalar function.

反过来说,对于每个特定的 feature set的 单个feature来说.
这个 scalar是在某种程度上encdoe/ embeded了n和mean(n)这个样本相关的信息的.

所以,从这个角度考虑的话,softmax更像是一种 relative measure.
而且是针对每个独立的feautre set的一种某种程度上来说是标准的映射/转换过程.

但,这种映射在不同的feature set/ vector之间是不是有可比性呢?

因为维度n是固定相同的.
所以,实际上就两张情况.

mean(y)相同或相近的情况自然不用说了.

考虑mean(y)差异比较大的情况.

假设mean_a(y) << mean_b(y). 那么,对于给定的y其对应的softmax的值对应的relative position就会有比较大的偏差了. 从直觉上来说,虽然可能再这些值当中存在着某种程度的structure/level. 但由于数值上的区分度差异或者说classification的需要. 这些差异信息就可能被从计量的层面上被抹掉. 所以,从信息完整程度上来说,softmax也不太适合这种差异比较大的情况. 当然,这个可能可以通过具体地再套一层 normalize function. 或者再加一层network layer去 project到更高的维度再做softmax. 但考虑y>0的情况的话,可能也不是一个好的解决方法.

某种程度上来说,就像softmax名字所说的,着重点在max,注意点在soft.
也就是针对某个单一 dominated的 feature的产生作用.

所以从这个角度考虑的话,也不是说DNN和NN有多大的本质区别.
可能只是一些数据分布差异所带来的工程化处理/解决方案/方式/方法而已.

随机应变

也许有时候得承认,一个人用地最多的语言多多少少会影响到对其他语言的看法.
毕竟,每门语言都有自己独有的模式.

最近又用NodeJS写了点东西.

选它的理由很直接.

因为是想用SVG画点简单的图形做logo/icon之类的.
所以最直接的思路就是打开Chrome console里直接SVG的JavaScript API画.
简单封一下就是命令式的作图工具了.

虽然说,解决这个问题的方法很多.
比如SAI/PS什么的,花样还多些.
或者退一万步来说,也有现成的SVG library或者现成Pixlr App,也不用自己手工写.

但想想,可能只是简单画线而已了.
所以大概不用上这么些重量级的东西.
而且自己写的,多少可控些.

说到底,可能还是某种NIH Syndrome的表现吧.

于是,既然前面所见部分都是Javascript了,那么后面存储转换什么的,也就直接NodeJS了.

虽然原则上来说,处理小事情个人还是偏向python的.
但对于这可能最多几百行的东西来说,异构的技术栈可能没那么必要.

而且有一点是,至少从Http模块来说,NodeJS可以直接上手.
python内置的那个,多少还得做点事情.

事情到这里其实都还是意料之中的.

直到开始考虑SVG转PNG的时候,大概问题就来了.

首先考虑的自然是imagemagick去做转换.

估计着NodeJS的流行度,找个binding库应该不难.

然而看了Google Search头几条的基本都不维护了.
而且稍微翻了下实现,都是直接spawn一个命令行convert出去的.

当初考虑用binding库的时候就是不想这么做的.
而且,如果接受spawn的话,自己spawn就行了,何必再带一个第三方库.

于是想想,这些项目被主动abandon倒说明作者还是有点良心的.
免得别人写个hello world还得带上一堆三方库.

不过native的binding也还是有的.

问题在于,NodeJS的许多库,它存在不代表可用.

由于node版本的关系,目前node-imagemagick-native master的版本对4.0.0这个版本的node是不行的.
大概是依赖的nan库还没跟进上.

说到底就是v8的某些接口改了,上游没跟进,于是下游自然也没办法.

暂时妥协,nvm换低版本的node.

本以为就此结束了.

然后事实是始终无法svg to png.
直接异常,还不带堆栈.

至少看看怎么改对应实现一步步debug看下什么问题.

所幸的一点是这项目的gyp配置写得还不错,build没问题.
于是把吞掉的异常重新抛出来看了下.

大致是SVG本身算是XML文本,跟其他通常意义的image格式的一个明显差别是没有明显的meta信息.
尤其是图片规格/大小.

这个虽然说可以在XML里作为属性附上,但毕竟不是必选项目.
而且要一个图片处理库去处理XML,换自己也懒得去管.

所以,问题是convert的时候需要提供一下SVG的size.

然后回头看了下node-imagemagick-native,根本就没考虑这种情况.
于是proposal了个pull request加个参数解决.

但即使接受也不知何年何月的事情.
况且还有node版本的问题待解决.
加上看了下node的native module也不难的样子.

于是去翻了下gyp的文档.

看完之后的一个想法是.
这不清不楚的居然是官方文档.

不过gyp本来就是一个特定项目的build tool.
自己人自己知道怎么用,文档不是太重要.
被node拿去用,只能说node社区就是这样的性格/风气.

依照的有限的文档写配置,build.
结果确实什么都没发生.

对比了下generate出来的makefile和node-imagemagick-native的区别,发觉是cflags/ldflags没生效.

照文档的说法改了几种方式依然.
于是只能Google下有没类似案例再不行就只能看实现了.

所幸这个问题还算常见.
原因只是在OSX上,gyp是用另外的xcode相关的参数在generate的时候代替标准的clfags/ldfags配置.

于是只能再次感叹,gyp果然是一个自己人给自己人玩的东西.

不过一个意外收获倒是直接了解了gyp的大致parse过程.
也算是聊胜于无的收获.

解决完这个想着,该没什么其他问题了吧.

然而很快地build发觉居然还是symbol not found.

重新看了下generate的makefile发觉看起来不至于.

Google之后到了node-imagemagick-native的某个issue下面.

里面解释了说brew的magick++ build的时候link的是libc++.
而node link的是libstdc++.
于是感谢C++的mangling,symbol not found也就难怪了.

解决途径只能是告诉xcode,这里用的libc++,并且得指定targeting的OS是OS X 10.7以上.

然而,事情还是没完.

不过剩下的都是magick++的API设计问题了.
或者说SVG这种无相对有效meta信息的格式带来的问题.

所以convert的只能是empty image,然后设置完必要的size之后再read,然后write出去.
不然一般的话,应该可以直接构造image然后write.

不过这种超出写作时的设计范畴的事情,也只能这么解决.
毕竟,要单独弄一套API出来,可能更不好看.

不过最终还是convert完成了.

虽然说,自从之前被grunt打击过之后,对NodeJS的印象其实不太好了.
这次的一些问题更觉得node可能不太适合一些严肃的地方.

至于C++的部分嘛.
至少以后提到说over engineering的时候,大概有除了Java之外的候选了.

晚上重新review了下SVG的部分.

估计以后会再用到的时候会选path而不是polygon做代表了.

毕竟来说,path确实更general一些.

想想,不考虑曲线的话,可能也够了.

不过真有重新用的一天的话,大概会重写相当部分吧.
毕竟,到时可能思路和思考方式又不一样了.

所谓随机应变.