看到屠呦呦获得诺奖的消息,然后扫到有中医研究院字样,第一反应大概就是又要有场关于中西医的论战了吧.
而事实证明,自己想地还是不够周到的.
这个事情能牵着到的话题除了中西医,还有体制学术,以及医疗之外的文革问题.
这种事情,换做几年前,也可能会选个阵营战个不亦乐乎.
现在大概已经没有那种欲望了吧.
所谓兼听则明.
存在就是合理.
凡事都有正确的一面.
就中医来说呢,为人诟病的一点就是缺乏现代医学的检验程序.
没有"科学"的置信度.
这个中立点说,中医毕竟不是精确计量的现代生化学科.
究其成因和历史时期来说,把它列入经验学科也有点勉强.
尤其一些经典/药方的编撰带有比较强烈的个人选择倾向,缺乏普适性.
但抛开这些,以纯理论框架看待的话,也不是完全不能自圆其说.
就中草药的使用/熬制而言,从某种程度上来说也可以认为是某种萃取制剂过程.
只不过没有精确的元素计量的一种近似提取罢了.
跟现代的制造工艺,思路上来说并没有太大的差异性.
就治疗效果而言.
现代医药起左右的方式大抵应该是要么直接的生化侵蚀作用,要么就是诱导性的自体应激/免疫治疗.
两者都是基于精确计量的方程式工程.
中医的用药行诊从抽象概念上来说,也是归类到这两方面的.
尤其被攻击的草药毒性这点.
兼有两者的作用.
当然,思路一致不代表就是差不多正确.
中医跟现代格格不如的一个地方在于其建立的理论基础.
气血加上阴阳无形这类神化宗教性质的系统概念.
但是如果换一个角度看,结合其时代特征的话,也不是不能理解.
毕竟至少它尝试建立一个统一的理论框架来解释一些因果关系.
至于这个框架正确不正确,那就是时代局限性的问题了.
就像量子理论发展的波函数.
在经典框架里无法解释的东西引入概率函数,能够解决一些问题/自洽,就说明至少正确了一部分.
尽管可能实际的因果关系并不是这样.
比如可能波函数的概率性质其实是缺少了某种高纬度的描述变量,才使得在目前已知的低纬度上出现概率性现象.
考虑实际是y=f(h)+g(x)形式的描述在目前的理论维度下变成了y=g(x;p)的描述.
f(h)的高维信息被投影成低维度的一个观测概率了.
或者像随机一些变量做feature vector去神经网络去CNN图像识别,那可能也有60-70%的"正确"率.
毕竟本身就是个基于"经验"的一个巨型encoder.
你也不能说它不科学.
毕竟这不是精确计量的范畴.
所以说中医那套玄学理论完全没有价值,也不一定.
至少它尝试自洽地解释一些问题.
而如果它"自洽"到一定程度,能给出人一个新维度的想法应用到其他理论框架火提供思路,也不是不可能.
当然,这也并不是说会接受诸如能治不孕不育/癌症等的说法的.
毕竟复杂病理放在那里,也不是一两个固定"方程"能解决的事情.
但对于其他一些常见小伤痛倒是不置可否.
因为想想,也不是不可能的事情.
本质上来说,就是没有找到跟自己现有认知产生明显冲突和矛盾/否定地方.
反过来说,会"据理力争"的大概都是跟其理念有所冲突的部分了.
这些围观下,吸收值得吸收的东西也不错.
毕竟,大抵每个人都有自己成套的系统体系/世界观.
至于完善不完善,正确不正确,其实是没有事实上的评价的.
就每个人而言,自己所做的都是某种程度上正确的,有对应世界观和知识储备支持的.
对与错的界限其实并不明显.
也可能不是一成不变的.
就像体制问题.
本身就是个围城问题.
只不过身处所在,有些表现会额外关心和瞩目罢了.
如果以在其位谋其政的角度思考,可能也并不能做出更高明的决策.
尤其有时候,信息可能更不透明.
加上现代社会,信息的泛滥程度,通常需要有自己的筛选过滤鉴别方式.
就像诸如近期的日本讹人事件,以及之前种种的社会热点反转再反转的事情.
很多事情依靠的还是自己对各个部分的判断推理组合.
至于如何"判断"本身就是个因人而已的问题.
就像有人觉得微博上加V是种可信度保证.
但本质上只是对身份的一个认证而已.
言论如何是另一回事.
有时候甚至是一种筛选信号.
毕竟,把微博当作一个正常的信息渠道工具的,其实并不在意自己对他人来说是谁.
而是他人对于自己来说是什么消息渠道性质.
毕竟大多数人还是默默的消费者.
能够有能力有力量输出信息的,也不是一个认证能保证的.
某种程度上来说也是不需要.
就像和菜头.
从下午南派三叔被攻击开始到现在就做了一场很好的媒体行为艺术.
有时候挺钦佩他的洞察力和人品的.
无条件/奋不顾身支持朋友也不是今天这么一次了.
尤其有时候,在道德上并不占有优势甚至劣势的情况也能挺身而出.
而平时对粉丝的各种看似尖酸刻薄的调戏,对对方来说其实算是种另类的教育/劝戒.
对大众来说也是种调笑之余的反思.
毕竟来说,如果要说心灵鸡汤的话,很早之前的槽边往事应该是没人比得过他的.
现在这种混乱邪恶的姿态,也算是某种超越性的怜悯姿态吧.
毕竟,对于不是玻璃心的,自然也就无所谓形态.
而对于玻璃心,最好的方法就是及早打破,及早恢复.
这种应该就算是所谓的睿智吧.
不是独善其身的独立思考.
而是致力于让其他人也学会独立思考的努力吧.
2015-10-05
2015-10-01
由盲人的交互障碍谈起
翻到篇Facebook的论文,谈的盲人在社交网络体验的一个survey.
尤其侧重的在照片相关的这个点上面.
想想也确实,现在很多的App关注点都在于照片或者视频等.
尤其以Instagram这种形式的社交内容.
相对于听力障碍的人来说,视力障碍在这方面的局限性/缺陷可能更为明显.
诚如文中提都的一个观点.
视觉障碍只能依靠screen reading,在检索效率和友好度方面总是有所欠缺的.
加上现在的电子设备还是flat screen,很难提供诸如盲文之类的辅助消费方式.
如果再考虑下听力视觉双障碍的群体的话,这方面的问题就更严重一些了.
毕竟,就目前来说,除去听视觉方面的内容,互联网这个second reality就没什么实感了.
那么,能够提供除此之外的第三类接触方式么.
并且,这种方式是可以适用于移动等手持设备上的?
套用五感的说法.
视觉,听觉,嗅觉,味觉,触觉.
前两者是功能性障碍.
中间的两个则本身主观因素影响较多,且层次感不算特别分明,也不太适合用于信息载体.
剩下一个触觉.
广义上来说,人跟外界的交互也不过是一些生物电子反馈而已.
所以,原则上来说,能直接transcript成人体能识别的信号的话,也就没有这些功能性障碍病理表现了.
除非是涉及都大脑的某些先天性处理缺陷问题.
但原则上来说,也是有办法解决的.
前提是能弄清楚工作机制,然后模拟代替,做inception.
狭义上来说,触觉的范围可以约束到一些具体的肢体触碰反馈上面.
一个例子就是震动反馈.
尤其在手机的设计上,震动很早就存在作为静音时对来电提醒的一种反馈设计.
如果抽象点考虑的话,这种交互传递的就是一个二元的信号了.
理论上来说,跟构成现代计算基础的电子特质无异.
所以原则上来说,各种现存的对信息的encode方式都可以通过震动状态来传递.
但现实的约束在于人的解码能力以及更主要的传播速率限制.
考虑一个更近代一点的编码方式morse code这种现实应用的无线传播形式.
无线电时期的繁荣,至少说明了这种传导方式的实用性和有效程度.
应用在手机上的话,也已算是一种替代读屏的方案.
只不过曲线和实用性是另外一个问题.
这里是以吸收信息的角度看待的.
换个角度,如果是一个Morse code的方式,对手持设备就行交互呢?
也就是说用震动对手机传递信息/指令呢?
想想,早几年的摇一摇也算是这方面的尝试.
不过传递的信息只是一个特例形式的on口令.
后来的Moto X和Nexus 6的Ambient display某种程度上来说,也是这种形式.
本质上来说,是向手机传递的一种物理变化构成的反馈机制.
具体到上面的几个例子的话,差不多都是来自于位置变化.
尽管在敏感度和变化尺度什么有所不同.
另一个例子是照相.
尽管这个application的反馈来源实际上是镜头.
但如果假设是通过手机的sensor计算位置变化做出的处理的话.
其实就是Oculus Rift类的VR应用了.
如果考虑zoom in/out的操作的话,那么跟微软的Hololens/SurroundWeb的在交互上也可以有一些相似性.
在这种条件下,相当于透过手机屏幕,操作另一个世界的"实际物理设备".
或者中二点的说法,手机屏幕投影了一个异世界.
通过对屏幕的touch和这个"window"的位置变化,去实际操作和影响对界的一些设备.
游戏化地来说,Ingress就是这个方向的.
只不过只限于把故事背景设定了一下而已.
游戏的实际方式依然是基于实际地理的.
这个当然是可能有当初的一些其他商业化和数据需求的考虑.
但本质上来说,是可以构建一个等比现实大小的游戏空间出来提供交互的.
就像后续作品Pokemon Go目前给人的想象空间一样.
或者做成一些解密游戏也是思路很直接的.
如果把这种交互方式嫁接到现有的一些游戏机制上呢?
考虑消除类.
消除游戏的本质是用某种search algorithm去solve/optimize某种形式的objective function.
同时adversary则是introduce进来的某种类random variable的error term.
比如传统的三消或者trees或者祖玛都是一种search matching的过程.
俄罗斯方块某种程度上也是search matching,只不过对于的variable是shape而已.
把手机位置的变化作为一种search function来看待的话.
它带来的一些变化量有哪些呢?
一个直接的因素自然是其自身位置变量.
如果考虑屏幕反馈的是类似相机这种projected informa的话,那么可以认为是project context的变化.
那么这种直觉上的屏幕关注区域的变化就是这个search function的一般过程.
依然把matching作为objective function的话,error term应该如何设计呢?
color/shape match的过程,实际上就是从一个project context/screen到另一个context/screen的过程.
如果每一个screen都是静态的,那么这个search algorithm就是deterministic的.
deterministic的话,一个突破点可能就在于混淆性.
犹如拼图.
可以是形状的相似度.
也可以是如纯色拼图这类.
本质上是降低区别程度/减少可供区分的变量.
non-deterministic的话,可以考虑是因素就多谢了.
就shape match来说,可以是shape本身是变化的.
这个变化的含义可能是随时间,或者是本身是个moving object,或者复杂些的需要满足前置收集/match条件的transform.
color match的思路类似.
还有一种是time limited game的思路.
也就是通常的限时任务.
推而广之的话,就是某种外在资源的限制因素.
比如在context/screen switch的时候,并不能显示某些区域等.
而是需要满足某些条件,如移动模式/路径/速率等.
类似war frog的概念.
当然,这种交互方式虽然说能够把可交互领域不止一个维度地扩展.
但相对的,一个局限性就是依赖于物理位置的变化,也就是对现实空间有些要求.
而且在同等交互概念项目,视觉VR的路线可能对这方面的约束更少一些.
毕竟,这种情况下的投影区域/入口不依赖于手机位置,而在于穿戴的设备.
再者,像黑客帝国的脑后插管的Matrix方式可能更环保和空间利用上更高效.
尤其考虑到原则上来说,是可以每个人活在自己世界的.
尤其侧重的在照片相关的这个点上面.
想想也确实,现在很多的App关注点都在于照片或者视频等.
尤其以Instagram这种形式的社交内容.
相对于听力障碍的人来说,视力障碍在这方面的局限性/缺陷可能更为明显.
诚如文中提都的一个观点.
视觉障碍只能依靠screen reading,在检索效率和友好度方面总是有所欠缺的.
加上现在的电子设备还是flat screen,很难提供诸如盲文之类的辅助消费方式.
如果再考虑下听力视觉双障碍的群体的话,这方面的问题就更严重一些了.
毕竟,就目前来说,除去听视觉方面的内容,互联网这个second reality就没什么实感了.
那么,能够提供除此之外的第三类接触方式么.
并且,这种方式是可以适用于移动等手持设备上的?
套用五感的说法.
视觉,听觉,嗅觉,味觉,触觉.
前两者是功能性障碍.
中间的两个则本身主观因素影响较多,且层次感不算特别分明,也不太适合用于信息载体.
剩下一个触觉.
广义上来说,人跟外界的交互也不过是一些生物电子反馈而已.
所以,原则上来说,能直接transcript成人体能识别的信号的话,也就没有这些功能性障碍病理表现了.
除非是涉及都大脑的某些先天性处理缺陷问题.
但原则上来说,也是有办法解决的.
前提是能弄清楚工作机制,然后模拟代替,做inception.
狭义上来说,触觉的范围可以约束到一些具体的肢体触碰反馈上面.
一个例子就是震动反馈.
尤其在手机的设计上,震动很早就存在作为静音时对来电提醒的一种反馈设计.
如果抽象点考虑的话,这种交互传递的就是一个二元的信号了.
理论上来说,跟构成现代计算基础的电子特质无异.
所以原则上来说,各种现存的对信息的encode方式都可以通过震动状态来传递.
但现实的约束在于人的解码能力以及更主要的传播速率限制.
考虑一个更近代一点的编码方式morse code这种现实应用的无线传播形式.
无线电时期的繁荣,至少说明了这种传导方式的实用性和有效程度.
应用在手机上的话,也已算是一种替代读屏的方案.
只不过曲线和实用性是另外一个问题.
这里是以吸收信息的角度看待的.
换个角度,如果是一个Morse code的方式,对手持设备就行交互呢?
也就是说用震动对手机传递信息/指令呢?
想想,早几年的摇一摇也算是这方面的尝试.
不过传递的信息只是一个特例形式的on口令.
后来的Moto X和Nexus 6的Ambient display某种程度上来说,也是这种形式.
本质上来说,是向手机传递的一种物理变化构成的反馈机制.
具体到上面的几个例子的话,差不多都是来自于位置变化.
尽管在敏感度和变化尺度什么有所不同.
另一个例子是照相.
尽管这个application的反馈来源实际上是镜头.
但如果假设是通过手机的sensor计算位置变化做出的处理的话.
其实就是Oculus Rift类的VR应用了.
如果考虑zoom in/out的操作的话,那么跟微软的Hololens/SurroundWeb的在交互上也可以有一些相似性.
在这种条件下,相当于透过手机屏幕,操作另一个世界的"实际物理设备".
或者中二点的说法,手机屏幕投影了一个异世界.
通过对屏幕的touch和这个"window"的位置变化,去实际操作和影响对界的一些设备.
游戏化地来说,Ingress就是这个方向的.
只不过只限于把故事背景设定了一下而已.
游戏的实际方式依然是基于实际地理的.
这个当然是可能有当初的一些其他商业化和数据需求的考虑.
但本质上来说,是可以构建一个等比现实大小的游戏空间出来提供交互的.
就像后续作品Pokemon Go目前给人的想象空间一样.
或者做成一些解密游戏也是思路很直接的.
如果把这种交互方式嫁接到现有的一些游戏机制上呢?
考虑消除类.
消除游戏的本质是用某种search algorithm去solve/optimize某种形式的objective function.
同时adversary则是introduce进来的某种类random variable的error term.
比如传统的三消或者trees或者祖玛都是一种search matching的过程.
俄罗斯方块某种程度上也是search matching,只不过对于的variable是shape而已.
把手机位置的变化作为一种search function来看待的话.
它带来的一些变化量有哪些呢?
一个直接的因素自然是其自身位置变量.
如果考虑屏幕反馈的是类似相机这种projected informa的话,那么可以认为是project context的变化.
那么这种直觉上的屏幕关注区域的变化就是这个search function的一般过程.
依然把matching作为objective function的话,error term应该如何设计呢?
color/shape match的过程,实际上就是从一个project context/screen到另一个context/screen的过程.
如果每一个screen都是静态的,那么这个search algorithm就是deterministic的.
deterministic的话,一个突破点可能就在于混淆性.
犹如拼图.
可以是形状的相似度.
也可以是如纯色拼图这类.
本质上是降低区别程度/减少可供区分的变量.
non-deterministic的话,可以考虑是因素就多谢了.
就shape match来说,可以是shape本身是变化的.
这个变化的含义可能是随时间,或者是本身是个moving object,或者复杂些的需要满足前置收集/match条件的transform.
color match的思路类似.
还有一种是time limited game的思路.
也就是通常的限时任务.
推而广之的话,就是某种外在资源的限制因素.
比如在context/screen switch的时候,并不能显示某些区域等.
而是需要满足某些条件,如移动模式/路径/速率等.
类似war frog的概念.
当然,这种交互方式虽然说能够把可交互领域不止一个维度地扩展.
但相对的,一个局限性就是依赖于物理位置的变化,也就是对现实空间有些要求.
而且在同等交互概念项目,视觉VR的路线可能对这方面的约束更少一些.
毕竟,这种情况下的投影区域/入口不依赖于手机位置,而在于穿戴的设备.
再者,像黑客帝国的脑后插管的Matrix方式可能更环保和空间利用上更高效.
尤其考虑到原则上来说,是可以每个人活在自己世界的.
2015-09-25
无用功
今天晚上看到某条关于新浪微博调整timeline显示算法的消息.
大致意思是04年底的一个改动,对一些高频发布和所定义的低互动内容做"降权"处理.
同时对广告渠道的这里消息做豁免.
对商业渠道做保留处理,这也不是不能理解.
毕竟需要一种盈利模式.
而且就赚钱能力来说,不得不承认新浪微博比先驱Twitter更早实现.
后者现在有许多功能其实也是在借鉴微博的做法.
毕竟,做这种公共消息平台,始终是很难脱离用流量变现的.
只是对用户自己timeline的干涉,这点倒是颇有中华民族的传统美德/家长精神.
事实上,这种看上去是"为你好"的做法,对于国内公司来说,算是某种定势思维吧.
之前的微博自己的智能排序,以及BAT的种种默认开启的做法.
一个算是载入失策的典型应该算是著名的"艰难的决定"吧.
中性地来说,操纵用户的timeline,服务方不明说的话,大概多数人也不会有什么发觉.
毕竟,虽然说timeline的成分构成是自己筛选出来的,但是具体产生了什么其实自己也是不知道的.
这便是这种公共场合性质平台的一个特点.
消息的消费其实是个体自己筛选编辑的一个合集/结果.
里面构成的偏好,其实来源可以很复杂.
有些是资讯类,有些是说话方式,有些是个人关系,有些是其他一些兴趣点之类的.
这几个基本点原则上也是个概论兴致,实际上是可以继续细分下去的.
但如果想通过做feature然后做推荐的话,估计效果并不会太好.
因为从结果上来说,拟合的也只是当前follow状态的一个近似快照.
按照这个结果去寻找匹配的话,谈不上有很强的依据性.
第一是因为这个结果是一个time vary的过程.
某个feature的有效作用可能只在某个时间段或者某些时间段有效.
当然,把每个feature做time serial方向的predict,然后用在分别每个时间段的predicated value做feature vector重新做拟合的话,可能更符合直觉.
但计算量是一方面,实际有效性又是另一方面了.
第二个原因则是个人的偏好其实也是个time vary的过程.
虽然可以再在一个predict,然后跟上面的结果再一起做regression.
但是明显的,这里有太多的predication了.
说没有误差,或者说不影响"准确性"之类的,实在很难令人信服.
所以,通过推荐来扩充网络的健壮性并不见得是一个好方法.
而且从发展历程来看的话,个人的timeline其实多多少少还是靠自身去发掘维护的.
因为毕竟是公共空间,而且早起的模式是更aggressive的转发而没有steady的评论.
这点跟微信这类封闭空间是有先天优势的.
微信一个值得称道的点就在于早期理念的封闭性.
依靠某种程度上的口口相传建立的network.
某种程度上来说,这是一个值得记录的关于口碑传播的大规模社科实验.
结果也可能很明显.
口碑传播确实具有相对的高质量预告以及忠诚度.
但是同时反映了"口碑"供给和发放的有限性.
毕竟,某个领域的周知品牌也就那么几个.
所以从传播效果上来说,其实是一个固定配给的市场.
或者从消费角度来说,是需求固定的一条供需曲线.
而且一个明显的缺点在于,品牌的传播性是的dominated tipping point可能更靠左.
因为这种封闭环境的口口相传很难有足够的突破性去推翻原有的口碑.
一是前辈有着先发优势,覆盖面不是一个层级的问题.
二是传播毕竟是一个存在延时和损耗递减的过程,能存活多久本身就是个问题.
当然,这不是封闭空间独有的问题.
开放空间也有.
只不过开放空间的消息暴露度基本是100%.
个体有动机的化,筛选优化剔除的难度相对低很多.
简单说,就是区别在于消息多元化的程度不同.
消息结构单一或者不够多样的话,纠偏的能力就较弱.
但同时也因为纠偏能力偏弱,传播速度和接受程度可能比多元结构的更快.
毕竟一个闭合圈子的话,某种程度上来说思维结构和接受方式存在一定程度的相似性.
消息处理和消化成本会低很多.
多元结构需要各种预判和处理,相对来说,对消费的门槛和需求复杂度要高些.
不过不管是哪种结构,基于的一般逻辑都是消费者自身的一个筛选再组织过程.
区别只不过是候选的来源问题.
所以,本质上来说,这些流量平台的立足点首先是消费者对消息的主动接受过程.
虽然表现形式上来说可能是一种推送过程.
但实际上,还是基于用户的一个预先选择.
因此,对于用户这个node来说,network flow的驱动方式其实是来自这些node的pull过程.
考虑这么一个network或者说graph.
用户作为subscriber,s-node.
流量的变现提供方,或者说广告主,或者营销实施方作为publisher,p-node.
那么,在这么个一个graph里,实际上就可以划分为两个sub-graph.
分别由s-node和p-node构成的s-graph和p-graph.
于是,该如何定义这个graph的network flow的cash模型呢.
或者说,怎么评估这些网络所能带来的变现能力呢?
考虑,对于network里的某个节点,初始有一定的energy.
然后pull的过程其实是从其他节点slice/aggregate energy.
即energy_x(t+1) = absorb( \sum_{i=neighbour(x)} slice(energy_i(t))) )
也就说t+1时间的节点energy是吸收/pull的t时间的周边节点的energy构成的.
即从following的node里吸收信息,然后再消化之后,供其他节点消费.
这里犹豫的一点是absorb function要不要是守恒的.
如果不守恒的话,也就是整个network的energy可能是可变的.
而且具体到个体node的话,还有个问题是energy到0之后,是否要从network里移除,还是继续保留甚至允许非实数的参与.
守恒的话,直觉上模型/论述起来可能要简单一些.
因为如果把energy替换为cash的话,就是相对简单的零和市场.
不然的话就是一个动态变化的市场.
所以先考虑一下守恒的情况.
如果不区分s-graph和p-graph的话,那么对于graph的network flow来说,不过是energy/cash的互相自然周转而已.
考虑区分的情况的话,把"流量变现"行为定义为一种对flow做routing的行为的话.
那么,实际上就相当于吧neighbour函数返回的neighbours做了更改.
也就是说,实际上是更改了网路的连接结构/状态.
付费的p-nodes实际上是往原有的s-graph里添加新的节点,并改变原有的s-graph的结构变成一个新的graph.
而新加的p-node的作用实际上就是往外emit energy.
那么如果absorb是守恒的,而且考虑p-node的目的只是emit完所有的energy然后退出.
也就是说,纯粹的推广传播之后就消失.
则留在network里的energy就会越来越多.
而这些energy的多寡并不在开始的pull模型里参与任何作用.
也就是说,理论上并没有囊括对现有网络结构变化的影响描述.
考虑absorb是一个非守恒的过程.
对于纯粹的s-graph来说,非守恒就因为这整体network的energy可能衰减到0.
那么,对于平台方来说,一个动力或者说objective就是尽可能地维持或者maximize整体network的energy/cash.
考虑一个特例的简化情况.
也就是,在没有p-node参与的情况下,整体s-graph的energy是恒定/稳态的.
而p-node的加入,则是跟特定的s-graph子集产生连接.
即:
energy_x(t+1) = absorb( \sum_{i=neighbour(x)} slice(energy_i(t)))) + absorb_p(slice(pnode)).
即每个被连接的s-node的energy状态改变的absorb function被加入了一个absorb_p项.
那么,对于原有的objective就相当于maximize各个\sum absorb_p了.
也就是对与付费传播选定的advertise target,其影响不能使得network的整体energy有所衰减.
而如果\sum absorb_p >0的话,那么这一部分的energy就可以当作是平台的盈利来源/cash.
于是,如何定性absorb_p呢?
假设p-node向外emit的energy都是equal quantities的.
那么,实际上absorb_p的性质就相当于对energy的接受/转化程度如何.
也就是说,在这种稳态假设的前提下,广告推送的目标应该是对广告不反感,不会降低自身energy的目标群体.
理论上来说,给定一定的emit量,并不一定总能找到足够的positive的s-nodes去absorb这些energy.
现实一点的情况是,这个candidate的sub s-graph可能存在一些s-node的absorb_p的值是negative的.
但总体来说,还是一样的objective function.
考虑给s-graph的energy稳态做个限定区分的话.
即,如果某个s-node的energy低于/高于一个值的话,那么就不会再往外emit energy.
换句话说,就是s-node不会从低energy的s-node上面absorb.
于是,在理论上就存在某个energy级别并且低connectivity的s-node变成一个黑洞.
从而实际上地减少了整个network的effective energy/flow.
对于s-node在某个值不往外pull的情况,其实原则上是reduce到不emit的情况的.
因为不pull不代表不存在network flow.
只要不到emit的临界点.
所以,回头看的话.
其实说了一堆废话.
毕竟,推送到不反感的用户,维护/鼓励用户的读写活跃度这些都算是直觉上就能想到的东西.
说到底不过是在自我强调一些东西而已.
大致意思是04年底的一个改动,对一些高频发布和所定义的低互动内容做"降权"处理.
同时对广告渠道的这里消息做豁免.
对商业渠道做保留处理,这也不是不能理解.
毕竟需要一种盈利模式.
而且就赚钱能力来说,不得不承认新浪微博比先驱Twitter更早实现.
后者现在有许多功能其实也是在借鉴微博的做法.
毕竟,做这种公共消息平台,始终是很难脱离用流量变现的.
只是对用户自己timeline的干涉,这点倒是颇有中华民族的传统美德/家长精神.
事实上,这种看上去是"为你好"的做法,对于国内公司来说,算是某种定势思维吧.
之前的微博自己的智能排序,以及BAT的种种默认开启的做法.
一个算是载入失策的典型应该算是著名的"艰难的决定"吧.
中性地来说,操纵用户的timeline,服务方不明说的话,大概多数人也不会有什么发觉.
毕竟,虽然说timeline的成分构成是自己筛选出来的,但是具体产生了什么其实自己也是不知道的.
这便是这种公共场合性质平台的一个特点.
消息的消费其实是个体自己筛选编辑的一个合集/结果.
里面构成的偏好,其实来源可以很复杂.
有些是资讯类,有些是说话方式,有些是个人关系,有些是其他一些兴趣点之类的.
这几个基本点原则上也是个概论兴致,实际上是可以继续细分下去的.
但如果想通过做feature然后做推荐的话,估计效果并不会太好.
因为从结果上来说,拟合的也只是当前follow状态的一个近似快照.
按照这个结果去寻找匹配的话,谈不上有很强的依据性.
第一是因为这个结果是一个time vary的过程.
某个feature的有效作用可能只在某个时间段或者某些时间段有效.
当然,把每个feature做time serial方向的predict,然后用在分别每个时间段的predicated value做feature vector重新做拟合的话,可能更符合直觉.
但计算量是一方面,实际有效性又是另一方面了.
第二个原因则是个人的偏好其实也是个time vary的过程.
虽然可以再在一个predict,然后跟上面的结果再一起做regression.
但是明显的,这里有太多的predication了.
说没有误差,或者说不影响"准确性"之类的,实在很难令人信服.
所以,通过推荐来扩充网络的健壮性并不见得是一个好方法.
而且从发展历程来看的话,个人的timeline其实多多少少还是靠自身去发掘维护的.
因为毕竟是公共空间,而且早起的模式是更aggressive的转发而没有steady的评论.
这点跟微信这类封闭空间是有先天优势的.
微信一个值得称道的点就在于早期理念的封闭性.
依靠某种程度上的口口相传建立的network.
某种程度上来说,这是一个值得记录的关于口碑传播的大规模社科实验.
结果也可能很明显.
口碑传播确实具有相对的高质量预告以及忠诚度.
但是同时反映了"口碑"供给和发放的有限性.
毕竟,某个领域的周知品牌也就那么几个.
所以从传播效果上来说,其实是一个固定配给的市场.
或者从消费角度来说,是需求固定的一条供需曲线.
而且一个明显的缺点在于,品牌的传播性是的dominated tipping point可能更靠左.
因为这种封闭环境的口口相传很难有足够的突破性去推翻原有的口碑.
一是前辈有着先发优势,覆盖面不是一个层级的问题.
二是传播毕竟是一个存在延时和损耗递减的过程,能存活多久本身就是个问题.
当然,这不是封闭空间独有的问题.
开放空间也有.
只不过开放空间的消息暴露度基本是100%.
个体有动机的化,筛选优化剔除的难度相对低很多.
简单说,就是区别在于消息多元化的程度不同.
消息结构单一或者不够多样的话,纠偏的能力就较弱.
但同时也因为纠偏能力偏弱,传播速度和接受程度可能比多元结构的更快.
毕竟一个闭合圈子的话,某种程度上来说思维结构和接受方式存在一定程度的相似性.
消息处理和消化成本会低很多.
多元结构需要各种预判和处理,相对来说,对消费的门槛和需求复杂度要高些.
不过不管是哪种结构,基于的一般逻辑都是消费者自身的一个筛选再组织过程.
区别只不过是候选的来源问题.
所以,本质上来说,这些流量平台的立足点首先是消费者对消息的主动接受过程.
虽然表现形式上来说可能是一种推送过程.
但实际上,还是基于用户的一个预先选择.
因此,对于用户这个node来说,network flow的驱动方式其实是来自这些node的pull过程.
考虑这么一个network或者说graph.
用户作为subscriber,s-node.
流量的变现提供方,或者说广告主,或者营销实施方作为publisher,p-node.
那么,在这么个一个graph里,实际上就可以划分为两个sub-graph.
分别由s-node和p-node构成的s-graph和p-graph.
于是,该如何定义这个graph的network flow的cash模型呢.
或者说,怎么评估这些网络所能带来的变现能力呢?
考虑,对于network里的某个节点,初始有一定的energy.
然后pull的过程其实是从其他节点slice/aggregate energy.
即energy_x(t+1) = absorb( \sum_{i=neighbour(x)} slice(energy_i(t))) )
也就说t+1时间的节点energy是吸收/pull的t时间的周边节点的energy构成的.
即从following的node里吸收信息,然后再消化之后,供其他节点消费.
这里犹豫的一点是absorb function要不要是守恒的.
如果不守恒的话,也就是整个network的energy可能是可变的.
而且具体到个体node的话,还有个问题是energy到0之后,是否要从network里移除,还是继续保留甚至允许非实数的参与.
守恒的话,直觉上模型/论述起来可能要简单一些.
因为如果把energy替换为cash的话,就是相对简单的零和市场.
不然的话就是一个动态变化的市场.
所以先考虑一下守恒的情况.
如果不区分s-graph和p-graph的话,那么对于graph的network flow来说,不过是energy/cash的互相自然周转而已.
考虑区分的情况的话,把"流量变现"行为定义为一种对flow做routing的行为的话.
那么,实际上就相当于吧neighbour函数返回的neighbours做了更改.
也就是说,实际上是更改了网路的连接结构/状态.
付费的p-nodes实际上是往原有的s-graph里添加新的节点,并改变原有的s-graph的结构变成一个新的graph.
而新加的p-node的作用实际上就是往外emit energy.
那么如果absorb是守恒的,而且考虑p-node的目的只是emit完所有的energy然后退出.
也就是说,纯粹的推广传播之后就消失.
则留在network里的energy就会越来越多.
而这些energy的多寡并不在开始的pull模型里参与任何作用.
也就是说,理论上并没有囊括对现有网络结构变化的影响描述.
考虑absorb是一个非守恒的过程.
对于纯粹的s-graph来说,非守恒就因为这整体network的energy可能衰减到0.
那么,对于平台方来说,一个动力或者说objective就是尽可能地维持或者maximize整体network的energy/cash.
考虑一个特例的简化情况.
也就是,在没有p-node参与的情况下,整体s-graph的energy是恒定/稳态的.
而p-node的加入,则是跟特定的s-graph子集产生连接.
即:
energy_x(t+1) = absorb( \sum_{i=neighbour(x)} slice(energy_i(t)))) + absorb_p(slice(pnode)).
即每个被连接的s-node的energy状态改变的absorb function被加入了一个absorb_p项.
那么,对于原有的objective就相当于maximize各个\sum absorb_p了.
也就是对与付费传播选定的advertise target,其影响不能使得network的整体energy有所衰减.
而如果\sum absorb_p >0的话,那么这一部分的energy就可以当作是平台的盈利来源/cash.
于是,如何定性absorb_p呢?
假设p-node向外emit的energy都是equal quantities的.
那么,实际上absorb_p的性质就相当于对energy的接受/转化程度如何.
也就是说,在这种稳态假设的前提下,广告推送的目标应该是对广告不反感,不会降低自身energy的目标群体.
理论上来说,给定一定的emit量,并不一定总能找到足够的positive的s-nodes去absorb这些energy.
现实一点的情况是,这个candidate的sub s-graph可能存在一些s-node的absorb_p的值是negative的.
但总体来说,还是一样的objective function.
考虑给s-graph的energy稳态做个限定区分的话.
即,如果某个s-node的energy低于/高于一个值的话,那么就不会再往外emit energy.
换句话说,就是s-node不会从低energy的s-node上面absorb.
于是,在理论上就存在某个energy级别并且低connectivity的s-node变成一个黑洞.
从而实际上地减少了整个network的effective energy/flow.
对于s-node在某个值不往外pull的情况,其实原则上是reduce到不emit的情况的.
因为不pull不代表不存在network flow.
只要不到emit的临界点.
所以,回头看的话.
其实说了一堆废话.
毕竟,推送到不反感的用户,维护/鼓励用户的读写活跃度这些都算是直觉上就能想到的东西.
说到底不过是在自我强调一些东西而已.
2015-09-18
夸夸其谈
昨天还是前天,手上的Nexus 6收到了例行的OTA.
完了之后,发现除了是个security update之外,还多了Android Pay.
说起来,Android Pay算是Google第二次做支付相关的了吧.
之前的是Wallet+Checkout的组合,现在Checkout没了,变成了Android Pay而已.
有趣的是,Checkout原来是一个可线上线下的解决方案.
不过相对来说偏向线上.
毕竟原型对手是Paypal这类为在线商家支付提供的解决方案.
现在的Android Pay则是针对线下的一个支付场景.
大概的思路应该是线上没有先手优势,线下大家起跑线都差不多吧.
而且手上有Android这个移动基础设施,多多少少有点先天优势.
原则上来说算是一个关于card的管理应用工具.
毕竟除了信用卡银行卡之外,各种会员卡礼品卡之类的也可以应用.
这点不由得让人想起Coin.
就个人来说,还是比较偏向于Coin这种实体卡形式的.
手机虽然说作为现代接入终端,计算能力和便携性都没什么问题.
但其多功能多角色的职能,可以说既是优点也是缺点.
一个简单的场景就是打电话的时候支付.
所以,终究来说,有些功能还是需要从手机上面decouple出来的.
就像现代的PC和video game console的关系一样.
通用和专用多少是有差别的.
而且就Coin独立存在的形式来说,至少免除了跟其他App混杂在一个运行环境的问题.
这点对于涉及钱的地方还是比较敏感的.
所谓环境越复杂,结果就越难以保证.
不过就Coin的具体产品形态来说,之于Android Pay还是有些局限的.
毕竟,后者能轻松扩展到其他领域的卡片.
虽然说这点局限性在于磁条和IC卡的技术代沟.
当然,除了这点Coin说到底还是一个开创者.
除了集成卡片这个思路之外,加入卡片的方式也较Android Pay更Google一些.
只要照片就能辅助完成.
而Android Pay还得自己填.
尤其是涉及gift card之类的.
开始以为是依靠Google的图像识别技术去匹配可能的候选.
后来看FAQ倒是取巧地扫条码.
这点多多少少有点失落.
到底看上去不太符合"人类希望"的风格.
不过像Android Pay这种东西,很难说不会走Checkout的失败老路.
从支付的角度来说,并没有带来太多的革新和令人眼前一亮的地方.
唯一的unify card的概念还是源自于Coin.
便捷程度上也很难跟其他可能的产品做出太大的区分度.
唯一可能让人放心的就是Google的技术能力至少能保证一定的安全性和隐私习惯的问题.
所以,本质上来说,这并不是一个能让人眼前一亮或者说有所启发的东西.
这大概就是创新的艰难之处.
尤其是基于一个follow别人思路的东西.
加上Android Pay的价值只是为Wallet的数据做桥梁的.
本身战略意义不及后者.
就算是要Cash Flow的数据,也不一定需要Wallet和Android Pay的存在.
有只是说更光明正大和方便精确一些而已.
虽然说对Google来说应该还是会有些底线的.
不像某些国内公司,拿了Android的各种权限,通过诸如读银行淘宝等短信收集消费行为数据.
Google的风格大概回事劝诱其他人通过它自己的支付接口或者给追踪SDK里加针对性的方法诱导第三方过渡数据.
所谓don't be evil的真谛.
说白了,就是为了一些数据而已.
毕竟这几年来稍微有点新意的模式都是基于数据做优化的.
像Uber和Airhub之类的,本质上来说也是基于结构化做的一种效率方面的social optimization.
不过相对来说,Uber在这方面可能藏着一些更深入的思路.
当你去看Uber的时候,会觉得不就是一个利用闲散时间和闲散社会资源做整合优化的一个东西么.
就跟它的follower lyft/滴滴/快滴之类的一样.
但看它经常做的另一件事其实是线下的一些cross promotion的活动.
看起来就像是跟某个品牌一起做的一个营销活动而已.
然而,如果换个思路,把Uber看作一种推广/推送渠道的话,可能就是另一种场景.
从这个角度看的话,其实Uber不仅在提高社会效率上面做了优化.
而且在此基础上创造除了新的广告和推广价值.
如果把车流和人流同比为线上流量的话,那么cross promotion的意义就相当于流量经过各个站点是展示的广告位.
Uber则是代替Google做这个广告位的publisher.
所以,某种程度上来说Uber是在起一种线下的定向导流的价值再创造活动.
某种程度上来说,把Uber比作线下的Google也不为过.
因为本质上来说,出行这一点代表的是线下的一种流量.
而Google在网上所做的一切也是基于对流量的操控提取做到的.
现阶段的Uber可能还只是浅层的商家活动.
但本质上来说Uber是可以对这种流量做manipulate的.
就像Uber Pool.
虽然依然个是social optimization的问题.
但是技术上说是做到了merge network flow的.
而支持这个的必然是关于network flow的各种pattern的数据.
这个数据就好比网站的PV/UV,还是全时的数据.
如果再把每个地点看作一个URL/Web Site的话,做个pagerank也是不难的.
而且如果考虑时间分布,做个分时变化的dynamic pagerank也是可以的.
这个往大了说,可以优化交通.
毕竟现在的Uber的schedule分配应该是不会look forward的.
而且有时也无法look forward.
但如果有了一定关于路线的概率分布数据,那么区域性的资源优化利用和预规划也理论上是可行的.
这是从Uber的全局出发的角度.
而对于每一个地点这种线下website来说,也可以有一个时段性的refer和bounce数据.
更乐观点的是refer和bounce数据是可以撮合到一起的.
这点对地点商家来说,至少可以做一些跨区域的上下游的促销行为支持.
对于商业中心规划来说,也可以根据link in/out来做一些选址方面的优化.
如果把同样的思路apply到indoor navigation的话,对于一个特定的商业中心来说,就有可能优化一下商铺的分布.
或者商场的一些机构性调整.
当然,这种调整是一种相对于游客/顾客来说被动的调整.
顾客主动的调整的话,可以是商家/商场针对流量概率的一些预判做的动态活动引导.
至于目的是疏导流量还是提高转化,就看具体需求做不同的规划的问题了.
像参考Ingress和即将有的Pokemon Go.
在不考虑使用群大小的前提下,是很容易引导流量产生变化的.
所以对于Uber来说,它对这个领域social optimization的理解可能比其他人更深入细化一点.
一旦上升到抽象的network flow的问题,它的愿景可能就更广大一些.
简单想下,直接把Google在web方面的所作所为和各种优化apply到Uber身上,也是没什么大问题的.
所以,就这点来说,原创者到底是原创者.
理解和接受别人的想法,可能要么是天赋问题,要么是努力的问题.
而创造出新想法,那就真的是天赋问题了.
而且更重要的是,一个东西内里所隐含的真正逻辑可能只有自己知道.
尤其,如果一个东西重要的其实并不是结果,而是得出这个结果的过程.
就像你拼命地烧钱补贴抢占市场,以为模式的终极模式是革命是垄断是定价权.
而这个模式真正重要的地方可能在你根本想不到看不到的地方.
完了之后,发现除了是个security update之外,还多了Android Pay.
说起来,Android Pay算是Google第二次做支付相关的了吧.
之前的是Wallet+Checkout的组合,现在Checkout没了,变成了Android Pay而已.
有趣的是,Checkout原来是一个可线上线下的解决方案.
不过相对来说偏向线上.
毕竟原型对手是Paypal这类为在线商家支付提供的解决方案.
现在的Android Pay则是针对线下的一个支付场景.
大概的思路应该是线上没有先手优势,线下大家起跑线都差不多吧.
而且手上有Android这个移动基础设施,多多少少有点先天优势.
原则上来说算是一个关于card的管理应用工具.
毕竟除了信用卡银行卡之外,各种会员卡礼品卡之类的也可以应用.
这点不由得让人想起Coin.
就个人来说,还是比较偏向于Coin这种实体卡形式的.
手机虽然说作为现代接入终端,计算能力和便携性都没什么问题.
但其多功能多角色的职能,可以说既是优点也是缺点.
一个简单的场景就是打电话的时候支付.
所以,终究来说,有些功能还是需要从手机上面decouple出来的.
就像现代的PC和video game console的关系一样.
通用和专用多少是有差别的.
而且就Coin独立存在的形式来说,至少免除了跟其他App混杂在一个运行环境的问题.
这点对于涉及钱的地方还是比较敏感的.
所谓环境越复杂,结果就越难以保证.
不过就Coin的具体产品形态来说,之于Android Pay还是有些局限的.
毕竟,后者能轻松扩展到其他领域的卡片.
虽然说这点局限性在于磁条和IC卡的技术代沟.
当然,除了这点Coin说到底还是一个开创者.
除了集成卡片这个思路之外,加入卡片的方式也较Android Pay更Google一些.
只要照片就能辅助完成.
而Android Pay还得自己填.
尤其是涉及gift card之类的.
开始以为是依靠Google的图像识别技术去匹配可能的候选.
后来看FAQ倒是取巧地扫条码.
这点多多少少有点失落.
到底看上去不太符合"人类希望"的风格.
不过像Android Pay这种东西,很难说不会走Checkout的失败老路.
从支付的角度来说,并没有带来太多的革新和令人眼前一亮的地方.
唯一的unify card的概念还是源自于Coin.
便捷程度上也很难跟其他可能的产品做出太大的区分度.
唯一可能让人放心的就是Google的技术能力至少能保证一定的安全性和隐私习惯的问题.
所以,本质上来说,这并不是一个能让人眼前一亮或者说有所启发的东西.
这大概就是创新的艰难之处.
尤其是基于一个follow别人思路的东西.
加上Android Pay的价值只是为Wallet的数据做桥梁的.
本身战略意义不及后者.
就算是要Cash Flow的数据,也不一定需要Wallet和Android Pay的存在.
有只是说更光明正大和方便精确一些而已.
虽然说对Google来说应该还是会有些底线的.
不像某些国内公司,拿了Android的各种权限,通过诸如读银行淘宝等短信收集消费行为数据.
Google的风格大概回事劝诱其他人通过它自己的支付接口或者给追踪SDK里加针对性的方法诱导第三方过渡数据.
所谓don't be evil的真谛.
说白了,就是为了一些数据而已.
毕竟这几年来稍微有点新意的模式都是基于数据做优化的.
像Uber和Airhub之类的,本质上来说也是基于结构化做的一种效率方面的social optimization.
不过相对来说,Uber在这方面可能藏着一些更深入的思路.
当你去看Uber的时候,会觉得不就是一个利用闲散时间和闲散社会资源做整合优化的一个东西么.
就跟它的follower lyft/滴滴/快滴之类的一样.
但看它经常做的另一件事其实是线下的一些cross promotion的活动.
看起来就像是跟某个品牌一起做的一个营销活动而已.
然而,如果换个思路,把Uber看作一种推广/推送渠道的话,可能就是另一种场景.
从这个角度看的话,其实Uber不仅在提高社会效率上面做了优化.
而且在此基础上创造除了新的广告和推广价值.
如果把车流和人流同比为线上流量的话,那么cross promotion的意义就相当于流量经过各个站点是展示的广告位.
Uber则是代替Google做这个广告位的publisher.
所以,某种程度上来说Uber是在起一种线下的定向导流的价值再创造活动.
某种程度上来说,把Uber比作线下的Google也不为过.
因为本质上来说,出行这一点代表的是线下的一种流量.
而Google在网上所做的一切也是基于对流量的操控提取做到的.
现阶段的Uber可能还只是浅层的商家活动.
但本质上来说Uber是可以对这种流量做manipulate的.
就像Uber Pool.
虽然依然个是social optimization的问题.
但是技术上说是做到了merge network flow的.
而支持这个的必然是关于network flow的各种pattern的数据.
这个数据就好比网站的PV/UV,还是全时的数据.
如果再把每个地点看作一个URL/Web Site的话,做个pagerank也是不难的.
而且如果考虑时间分布,做个分时变化的dynamic pagerank也是可以的.
这个往大了说,可以优化交通.
毕竟现在的Uber的schedule分配应该是不会look forward的.
而且有时也无法look forward.
但如果有了一定关于路线的概率分布数据,那么区域性的资源优化利用和预规划也理论上是可行的.
这是从Uber的全局出发的角度.
而对于每一个地点这种线下website来说,也可以有一个时段性的refer和bounce数据.
更乐观点的是refer和bounce数据是可以撮合到一起的.
这点对地点商家来说,至少可以做一些跨区域的上下游的促销行为支持.
对于商业中心规划来说,也可以根据link in/out来做一些选址方面的优化.
如果把同样的思路apply到indoor navigation的话,对于一个特定的商业中心来说,就有可能优化一下商铺的分布.
或者商场的一些机构性调整.
当然,这种调整是一种相对于游客/顾客来说被动的调整.
顾客主动的调整的话,可以是商家/商场针对流量概率的一些预判做的动态活动引导.
至于目的是疏导流量还是提高转化,就看具体需求做不同的规划的问题了.
像参考Ingress和即将有的Pokemon Go.
在不考虑使用群大小的前提下,是很容易引导流量产生变化的.
所以对于Uber来说,它对这个领域social optimization的理解可能比其他人更深入细化一点.
一旦上升到抽象的network flow的问题,它的愿景可能就更广大一些.
简单想下,直接把Google在web方面的所作所为和各种优化apply到Uber身上,也是没什么大问题的.
所以,就这点来说,原创者到底是原创者.
理解和接受别人的想法,可能要么是天赋问题,要么是努力的问题.
而创造出新想法,那就真的是天赋问题了.
而且更重要的是,一个东西内里所隐含的真正逻辑可能只有自己知道.
尤其,如果一个东西重要的其实并不是结果,而是得出这个结果的过程.
就像你拼命地烧钱补贴抢占市场,以为模式的终极模式是革命是垄断是定价权.
而这个模式真正重要的地方可能在你根本想不到看不到的地方.
2015-09-17
随机应变
也许有时候得承认,一个人用地最多的语言多多少少会影响到对其他语言的看法.
毕竟,每门语言都有自己独有的模式.
最近又用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一些.
想想,不考虑曲线的话,可能也够了.
不过真有重新用的一天的话,大概会重写相当部分吧.
毕竟,到时可能思路和思考方式又不一样了.
所谓随机应变.
毕竟,每门语言都有自己独有的模式.
最近又用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一些.
想想,不考虑曲线的话,可能也够了.
不过真有重新用的一天的话,大概会重写相当部分吧.
毕竟,到时可能思路和思考方式又不一样了.
所谓随机应变.
2015-09-11
才华横溢
Apple发布会里有一个比较有趣的就是iPad Pro.
从命名上看,应该是从属于iPad的产品线/品牌之下的.
但从尺寸和配套外设Smart Keyboard来看的话,其实是类似与Surface的定位.
而Surface的定位,本身就是从pad向laptop进一步迁移的结果.
即使更偏向于轻娱乐的笔记本.
本质上来说,Surface应该还是属于笔记本的.
那么,按照这个逻辑的话,iPad Pro就应该是归属Mac的产品线/品牌的.
没有的原因大概是因为之前有了一个比较失败的Macbook路线的创立.
Macbook不如Surface的原因大概还是因为它采用了已有的笔记本设计.
即一体化.
这样就结果上来说,并没有减少笔记本对于娱乐需求的便携负担.
所以某种程度上来说,Surface目前的结构是结果上来说比较折中的且被认可的一种方式.
那么,为什么不是像iWatch一样另立一个路线呢?
考虑iPad自2014年以来各个季度的销量数据,实际上是逐步下滑的.
从2014年的大概季度13k的销量到现在不到12k的销量.
即使是在有新品release的季度,也存在的总量上的下滑.
所以,如果从考虑废弃iPad品牌的角度来说的话,与其另立一个品牌不如升级下,继续沿用iPad的称呼.
而且,从iPad的早期定位来说,就是介于手机和笔记本之间的一个路线.
原则上来说,也就是.
iPhone作为mobile的代表.
iPad作为轻娱乐的代表.
Mac系列作为办公的代表.
这样路线就差不多清晰回归了.
然后考虑Pencil和iPhone的3D touch.
这个本质上来说,是对交互从纯平面的横向领域到纵深方向的一个期望吧.
毕竟,现有的touch交互都是平面的.
而二维平面能提供的区别模式也基本上挖掘完了.
swipe,press,drag & drop.
所以,现在的UI布局方式大都还是平面展开的.
除了Google的Material Design在交互方面有向纵深领域拓展的倾向.
一个明显的例子就是UI component惯用的Hero transition.
这个在web开发层面上看,是基于single page app做的一个交互切换策略.
而且从技术上来说,基本是resize的一些layout的transform/reflow.
但从实际引导效果来说,提供的是一种back/front的用户focus提示.
也就是某种程度的在平面做交互层次化的尝试.
而Pencil和3D touch则是直接提供给了用户一种突破深平面的交互方式.
虽然现有的宣传视频里多是一些popup tooltip类的应用.
但从结果上来说,还是给了一个明确的希望交互往纵深方向发展的尝试倾向.
不过这种压感方式的引导可能更容易让人把思维固定在垂直方向的velocity的一些应用上.
比如zoom in/out的加速浏览.
以及可能的把内容组织从列表改为cascade layout card之类的方式的导航等.
结果自然就是垂直方向的UI结构变得繁琐复杂.
所以,就垂直方向的交互来说,还是不太喜欢这种简单粗暴的拓展方式.
毕竟,多数touch screen的应用场景都是在一个主要的active view上面.
过多的纵深上面的安排,其实并没有提供太多的交互便利.
而且很容易把能够结构化/树状的交互层次变为凌乱的graph.
另一点就是,基于velocity的想法可能并不比现有的解决方式更优.
考虑Android切换task的UI交互.
所以就偏好而言,还是比较倾向于material design的paper/ink思路.
之前考虑过的一种形式是Hero transition的每个card其实是可以作为depth entry.
变为active的时候flip到背面又是一个新的canvas.
这样从UI层次上来说,还是一个树形结构,而且能够每个交互过程都是有一定延续的.
从风格切换上来说,也可以逐步替换掉色调之类的做渐适应.
本质上还是有一点single page app的思路在的.
实际上,现在的windows的平板模式或者说Metro的card的交互大致上也是这样.
不过怎么说微软呢.
虽然经常很多想法走在时代的前沿,但是拿出来的产品和成果却没能让人惊艳到.
Surface可以说是重新发明了平板.
但是估计如果这种类型成功了,功劳还是归到Apple头上.
Metro UI当时给了人灵光一闪的感觉.
只不过从结果上来说,Google借鉴地更好,因为本来就是偏向简洁风格的.
而偏向拟物的Apple最终也接受了这种风格.
某种程度上来说,也是微软改变了一个行业的思维.
更早点的则是智能家居/电器的概念.
可能2000年或者2004年就已经有prototype了,而当时智能手机可能还是一个高端的东西.
还有各种OS方面language方面的超前设计.
虽然很多都被后来者居上.
但是能有那么多次,而又好不顾忌地放手浪费掉.
大概就是所谓的才华横溢了.
从命名上看,应该是从属于iPad的产品线/品牌之下的.
但从尺寸和配套外设Smart Keyboard来看的话,其实是类似与Surface的定位.
而Surface的定位,本身就是从pad向laptop进一步迁移的结果.
即使更偏向于轻娱乐的笔记本.
本质上来说,Surface应该还是属于笔记本的.
那么,按照这个逻辑的话,iPad Pro就应该是归属Mac的产品线/品牌的.
没有的原因大概是因为之前有了一个比较失败的Macbook路线的创立.
Macbook不如Surface的原因大概还是因为它采用了已有的笔记本设计.
即一体化.
这样就结果上来说,并没有减少笔记本对于娱乐需求的便携负担.
所以某种程度上来说,Surface目前的结构是结果上来说比较折中的且被认可的一种方式.
那么,为什么不是像iWatch一样另立一个路线呢?
考虑iPad自2014年以来各个季度的销量数据,实际上是逐步下滑的.
从2014年的大概季度13k的销量到现在不到12k的销量.
即使是在有新品release的季度,也存在的总量上的下滑.
所以,如果从考虑废弃iPad品牌的角度来说的话,与其另立一个品牌不如升级下,继续沿用iPad的称呼.
而且,从iPad的早期定位来说,就是介于手机和笔记本之间的一个路线.
原则上来说,也就是.
iPhone作为mobile的代表.
iPad作为轻娱乐的代表.
Mac系列作为办公的代表.
这样路线就差不多清晰回归了.
然后考虑Pencil和iPhone的3D touch.
这个本质上来说,是对交互从纯平面的横向领域到纵深方向的一个期望吧.
毕竟,现有的touch交互都是平面的.
而二维平面能提供的区别模式也基本上挖掘完了.
swipe,press,drag & drop.
所以,现在的UI布局方式大都还是平面展开的.
除了Google的Material Design在交互方面有向纵深领域拓展的倾向.
一个明显的例子就是UI component惯用的Hero transition.
这个在web开发层面上看,是基于single page app做的一个交互切换策略.
而且从技术上来说,基本是resize的一些layout的transform/reflow.
但从实际引导效果来说,提供的是一种back/front的用户focus提示.
也就是某种程度的在平面做交互层次化的尝试.
而Pencil和3D touch则是直接提供给了用户一种突破深平面的交互方式.
虽然现有的宣传视频里多是一些popup tooltip类的应用.
但从结果上来说,还是给了一个明确的希望交互往纵深方向发展的尝试倾向.
不过这种压感方式的引导可能更容易让人把思维固定在垂直方向的velocity的一些应用上.
比如zoom in/out的加速浏览.
以及可能的把内容组织从列表改为cascade layout card之类的方式的导航等.
结果自然就是垂直方向的UI结构变得繁琐复杂.
所以,就垂直方向的交互来说,还是不太喜欢这种简单粗暴的拓展方式.
毕竟,多数touch screen的应用场景都是在一个主要的active view上面.
过多的纵深上面的安排,其实并没有提供太多的交互便利.
而且很容易把能够结构化/树状的交互层次变为凌乱的graph.
另一点就是,基于velocity的想法可能并不比现有的解决方式更优.
考虑Android切换task的UI交互.
所以就偏好而言,还是比较倾向于material design的paper/ink思路.
之前考虑过的一种形式是Hero transition的每个card其实是可以作为depth entry.
变为active的时候flip到背面又是一个新的canvas.
这样从UI层次上来说,还是一个树形结构,而且能够每个交互过程都是有一定延续的.
从风格切换上来说,也可以逐步替换掉色调之类的做渐适应.
本质上还是有一点single page app的思路在的.
实际上,现在的windows的平板模式或者说Metro的card的交互大致上也是这样.
不过怎么说微软呢.
虽然经常很多想法走在时代的前沿,但是拿出来的产品和成果却没能让人惊艳到.
Surface可以说是重新发明了平板.
但是估计如果这种类型成功了,功劳还是归到Apple头上.
Metro UI当时给了人灵光一闪的感觉.
只不过从结果上来说,Google借鉴地更好,因为本来就是偏向简洁风格的.
而偏向拟物的Apple最终也接受了这种风格.
某种程度上来说,也是微软改变了一个行业的思维.
更早点的则是智能家居/电器的概念.
可能2000年或者2004年就已经有prototype了,而当时智能手机可能还是一个高端的东西.
还有各种OS方面language方面的超前设计.
虽然很多都被后来者居上.
但是能有那么多次,而又好不顾忌地放手浪费掉.
大概就是所谓的才华横溢了.
2015-09-04
所谓事实
考虑一个简单的ROI形式,即:
return = f(investment).
对于一个人的主观决策,也即就是其expected return则是:
E(return) = f(investment).
考虑到之前提过的实际过程中,人决策过程中irrational/overconfident的量化形式,那么实际上应该是:
E(return) = f(investment) + g(bias)
也就是说,实际上,人做一个事情或一个决定的时候,对结果的期望是一个加上个人偏好的修正结果.
而实际的一个事情的结果往往是个人投入加上其余环境影响的一个综合结果.
即:
Fact(return) = f(investment) + H(environment).
那么,通常说一个事情不如预期的话,实际上是指:
delta(return) = E(return) - Fact(return)
也即
delta(return) = g(bias) - H(environment).
现在考虑一个问题.
如果一个人能够forecast所有事情,那么能否让预期结果和实际结果一致.
也即让delta(return) = 0呢?
考虑delta(return) = 0
->
g(bias) - H(environment) = 0
如果把环境因素简化为一个多人参与的同质描述的函数.
即,
H(environment) = \sum h(f_i(investment) + g_i(bias)) 的形式.
也即是说,把环境因素考虑为其他人决策的一个实际结果的某种加权形式.
则有
g(bias) = \sum h(f_i(investment) + g_i(bias))
这个意思就是为了使得个人决策结果与预期一致,或者说使得forecast的偏差为零的话.
决策的代价的依据是其他人的预期结果.
通俗地说就是在realize objective的时候,通过协调其他人的给定的已知的决策依据做调整.
也就是所谓的顺势而为.
这里对其他人的expected return是没有做任何限定的.
也即是其预期可以是任何形式.
考虑其他人决策的目的也是minimize delta(return).
因为delta(return) = g(bias) - H(environment).
对于单个个体来说,minimize的objective function是一个跟自身投入(investment)无关的一个函数.
而个体的delta(return) = 0 也就因为着对任意一个个体i,
g_i(bias) - H_i(environment) = 0
也即
g_i(bias) = H_i(environment).
则
H(environment) = \sum h(f_i(investment) + g_i(bias))
->
H(environment) = \sum h(f_i(investment) +H_i(environment))
由于
Fact(return) = f(investment) + H(environment).
->
f_i(investment) = Fact_i(return) - H_i(environment)
于是
H(environment) = \sum h(Fact_i(return) - H_i(environment) +H_i(environment))
->
H(environment) = \sum h(Fact_i(return))
也即
g(bias) = \sum h(Fact_i(return))
也就是说在一个人要使得自己的做法完全符合预期的调整函数是一个跟其他人的实现有关的一个函数.
这里隐含的一个条件是其他人的实现跟预期也是一致的.
即delta_i(return) = 0.
也即Fact_i(return) = E_i(return).
所以,实际上这个bias function其实是跟其他人的预期有关的一个函数
g(bias) = \sum h(Fact_i(return)) = \sum h(E_i(return))
重新rewrite一下ROI函数的话,就有
E(return) = f(investment) + g(bias)
->
E(return) = f(investment) + \sum h(E_i(return))
另外,
Fact(return) = f(investment) + H(environment)
->
Fact(return) = f(investment) + \sum h(Fact_i(return))
则
delta(return) = E(return) - Fact(return)
->
delta(return) = (f(investment) + \sum h(E_i(return))) - (f(investment) + \sum h(Fact_i(return)))
->
delta(return) = \sum (h(E_i(return)) - h(Fact_i(return)))
也就是说,个体决策的结果偏差是一个跟其他人的预期E_i和实际结果Fact_i有关的一个函数.
也就是形式上的
delta(return) = F(E_i,Fact_i).
那么问题就来了.
最初的假设是一个人可以forecast所有事情.
也就是说,对于某个时间点,Fact_i是通过forecast已知确定的.
而同时,E_i这个跟各个单独个体相关的预期函数可能不知道.
但基于个人预期是确定的这一假设,其值应该是固定的.
那么,也就是说
delta(return) = F(E_i,Fact_i)
在forecast的时候是已经确定了的.
换个角度来说,就是即使能够forecast,那么也无法改变什么.
因为delta(return)是一个跟自身无关的函数.
也就是说,即使你全知全能,但也无法改变什么.
当然,这里基于的一个假设是E_i是确定不变的.
或者说一个与forecast的个体无关的函数.
所以,如果E_i是一个跟forecast个体有关的函数呢?
重新考虑
delta(return) = F(E_i,Fact_i).
对于一个特定的forecast,Fact_i可以认为是一个常数项.
把它eliminate掉,就有:
delta(return) = G(E_i)
如果E_i是一个与forecast个体的某要素x有关的函数的话.
则有
delta(return) = G(E_i) = G(y(x)) = Y(x)
也就是说,如果一个人在能forecast所有事情的前提下,并且能够依此满足自己的任何需求的话.
那么,对于这个人,存在一个要素x,使得这个要素x能够影响其他人的先期预期.
使得通过其他人先期预期的调整,造成环境因素的contribution的变化,以转化为bias function的效用.
然而,如果这个成立的话.
那么就说明两点,
一是其他人的预期/决策模型/模式的改变不会改变任何forecast的事实,也就是说其他人的"主观能动性"是零.
二是做forecast的个体,可以在不改变其他结果的情况下,通过某种要素x实现对个人愿望结果的偏差操纵.
而这两点是互相矛盾的.
在基于个体都是平等的前提下.
当然如果这个个体是一个系统外的超越性存在的话,就另当别论了.
既然这两点是矛盾的.
那么对于给定的描述:
"如果一个人在能forecast所有事情的前提下,并且能够依此满足自己的任何需求的话.那么,对于这个人,存在一个要素x,使得这个要素x能够影响其他人的先期预期."
就是不存在逻辑关联性的.
也就是说,对于命题:
存在一个要素x,这个要素满足能够影响别人的先期预期.
是不成立的.
也即
delta(return) = Y(x)
是并不reasonable的.
所以结论回退到:
delta(return) = F(E_i,Fact_i)
即,即使能够forecast所有事情的发生,那么也无法操作自己的期望结果与实际事实的偏差.
即使E_i是一个random variable,但也是一个与forecast个体无关的函数.
也就是说,即使能够预知未来,但也无法确切地改变什么.
所谓事实.
return = f(investment).
对于一个人的主观决策,也即就是其expected return则是:
E(return) = f(investment).
考虑到之前提过的实际过程中,人决策过程中irrational/overconfident的量化形式,那么实际上应该是:
E(return) = f(investment) + g(bias)
也就是说,实际上,人做一个事情或一个决定的时候,对结果的期望是一个加上个人偏好的修正结果.
而实际的一个事情的结果往往是个人投入加上其余环境影响的一个综合结果.
即:
Fact(return) = f(investment) + H(environment).
那么,通常说一个事情不如预期的话,实际上是指:
delta(return) = E(return) - Fact(return)
也即
delta(return) = g(bias) - H(environment).
现在考虑一个问题.
如果一个人能够forecast所有事情,那么能否让预期结果和实际结果一致.
也即让delta(return) = 0呢?
考虑delta(return) = 0
->
g(bias) - H(environment) = 0
如果把环境因素简化为一个多人参与的同质描述的函数.
即,
H(environment) = \sum h(f_i(investment) + g_i(bias)) 的形式.
也即是说,把环境因素考虑为其他人决策的一个实际结果的某种加权形式.
则有
g(bias) = \sum h(f_i(investment) + g_i(bias))
这个意思就是为了使得个人决策结果与预期一致,或者说使得forecast的偏差为零的话.
决策的代价的依据是其他人的预期结果.
通俗地说就是在realize objective的时候,通过协调其他人的给定的已知的决策依据做调整.
也就是所谓的顺势而为.
这里对其他人的expected return是没有做任何限定的.
也即是其预期可以是任何形式.
考虑其他人决策的目的也是minimize delta(return).
因为delta(return) = g(bias) - H(environment).
对于单个个体来说,minimize的objective function是一个跟自身投入(investment)无关的一个函数.
而个体的delta(return) = 0 也就因为着对任意一个个体i,
g_i(bias) - H_i(environment) = 0
也即
g_i(bias) = H_i(environment).
则
H(environment) = \sum h(f_i(investment) + g_i(bias))
->
H(environment) = \sum h(f_i(investment) +H_i(environment))
由于
Fact(return) = f(investment) + H(environment).
->
f_i(investment) = Fact_i(return) - H_i(environment)
于是
H(environment) = \sum h(Fact_i(return) - H_i(environment) +H_i(environment))
->
H(environment) = \sum h(Fact_i(return))
也即
g(bias) = \sum h(Fact_i(return))
也就是说在一个人要使得自己的做法完全符合预期的调整函数是一个跟其他人的实现有关的一个函数.
这里隐含的一个条件是其他人的实现跟预期也是一致的.
即delta_i(return) = 0.
也即Fact_i(return) = E_i(return).
所以,实际上这个bias function其实是跟其他人的预期有关的一个函数
g(bias) = \sum h(Fact_i(return)) = \sum h(E_i(return))
重新rewrite一下ROI函数的话,就有
E(return) = f(investment) + g(bias)
->
E(return) = f(investment) + \sum h(E_i(return))
另外,
Fact(return) = f(investment) + H(environment)
->
Fact(return) = f(investment) + \sum h(Fact_i(return))
则
delta(return) = E(return) - Fact(return)
->
delta(return) = (f(investment) + \sum h(E_i(return))) - (f(investment) + \sum h(Fact_i(return)))
->
delta(return) = \sum (h(E_i(return)) - h(Fact_i(return)))
也就是说,个体决策的结果偏差是一个跟其他人的预期E_i和实际结果Fact_i有关的一个函数.
也就是形式上的
delta(return) = F(E_i,Fact_i).
那么问题就来了.
最初的假设是一个人可以forecast所有事情.
也就是说,对于某个时间点,Fact_i是通过forecast已知确定的.
而同时,E_i这个跟各个单独个体相关的预期函数可能不知道.
但基于个人预期是确定的这一假设,其值应该是固定的.
那么,也就是说
delta(return) = F(E_i,Fact_i)
在forecast的时候是已经确定了的.
换个角度来说,就是即使能够forecast,那么也无法改变什么.
因为delta(return)是一个跟自身无关的函数.
也就是说,即使你全知全能,但也无法改变什么.
当然,这里基于的一个假设是E_i是确定不变的.
或者说一个与forecast的个体无关的函数.
所以,如果E_i是一个跟forecast个体有关的函数呢?
重新考虑
delta(return) = F(E_i,Fact_i).
对于一个特定的forecast,Fact_i可以认为是一个常数项.
把它eliminate掉,就有:
delta(return) = G(E_i)
如果E_i是一个与forecast个体的某要素x有关的函数的话.
则有
delta(return) = G(E_i) = G(y(x)) = Y(x)
也就是说,如果一个人在能forecast所有事情的前提下,并且能够依此满足自己的任何需求的话.
那么,对于这个人,存在一个要素x,使得这个要素x能够影响其他人的先期预期.
使得通过其他人先期预期的调整,造成环境因素的contribution的变化,以转化为bias function的效用.
然而,如果这个成立的话.
那么就说明两点,
一是其他人的预期/决策模型/模式的改变不会改变任何forecast的事实,也就是说其他人的"主观能动性"是零.
二是做forecast的个体,可以在不改变其他结果的情况下,通过某种要素x实现对个人愿望结果的偏差操纵.
而这两点是互相矛盾的.
在基于个体都是平等的前提下.
当然如果这个个体是一个系统外的超越性存在的话,就另当别论了.
既然这两点是矛盾的.
那么对于给定的描述:
"如果一个人在能forecast所有事情的前提下,并且能够依此满足自己的任何需求的话.那么,对于这个人,存在一个要素x,使得这个要素x能够影响其他人的先期预期."
就是不存在逻辑关联性的.
也就是说,对于命题:
存在一个要素x,这个要素满足能够影响别人的先期预期.
是不成立的.
也即
delta(return) = Y(x)
是并不reasonable的.
所以结论回退到:
delta(return) = F(E_i,Fact_i)
即,即使能够forecast所有事情的发生,那么也无法操作自己的期望结果与实际事实的偏差.
即使E_i是一个random variable,但也是一个与forecast个体无关的函数.
也就是说,即使能够预知未来,但也无法确切地改变什么.
所谓事实.
订阅:
博文 (Atom)
牛来餐馆
看了欢迎来龙餐馆. 总的来说,作为一个院线电影,成品多少是有点不太匹配的. 看起来更多像是一部网络大电影. 尤其涉及到一些大场面特效的时候,可以看得出服化道的降本增效. 剧本层面有一些比较有意思或者说闪光点. 就是试图用一个餐馆或者厨师来串起一个比较宏大的叙事题材. 这个可以说是...
-
最近写一个AgentCLI原型玩具的时候,发现一些比较有意思的点. 因为主要是照着DeepSeek API来写的. 所以基本上也可以说是OpenAI Chat Completion API的一些点. 不过,可能有些是DeepSeek特有的. 一个是请求的stop list. 大致...
-
从未对雪有过什么幻想. 于是,当这雪终究下下来了,也没什么特别的兴奋. 只是,由于是南方人,也就姑且好奇了一番. 望了望着属于别处的风景. 也许是因为昨晚下过雨,也或许是本来就会如此. 冰混着点积水,倒是怀念起阳光灿烂的日子了. 面对着这未知的...
-
去看了长安的荔枝. 前半段还可以,尤其像荔枝林里不知道是笑还是哭的几个镜头表演算是相当出色了. 结合人物背景的那种对目标的绝望与对当下人际环境的希望的交叉矛盾心理. 后半段就有些过滤潦草了. 如果说整片是对于一骑红尘妃子笑,无人知是荔枝来的解构的话. 带入民生潦倒涂炭这点是没问题...