无用功

今天晚上看到某条关于新浪微博调整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的临界点.

所以,回头看的话.
其实说了一堆废话.

毕竟,推送到不反感的用户,维护/鼓励用户的读写活跃度这些都算是直觉上就能想到的东西.

说到底不过是在自我强调一些东西而已.

夸夸其谈

昨天还是前天,手上的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身上,也是没什么大问题的.

所以,就这点来说,原创者到底是原创者.

理解和接受别人的想法,可能要么是天赋问题,要么是努力的问题.
而创造出新想法,那就真的是天赋问题了.

而且更重要的是,一个东西内里所隐含的真正逻辑可能只有自己知道.
尤其,如果一个东西重要的其实并不是结果,而是得出这个结果的过程.

就像你拼命地烧钱补贴抢占市场,以为模式的终极模式是革命是垄断是定价权.
而这个模式真正重要的地方可能在你根本想不到看不到的地方.

随机应变

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

最近又用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一些.

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

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

所谓随机应变.

才华横溢

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方面的超前设计.

虽然很多都被后来者居上.
但是能有那么多次,而又好不顾忌地放手浪费掉.

大概就是所谓的才华横溢了.

所谓事实

考虑一个简单的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个体无关的函数.

也就是说,即使能够预知未来,但也无法确切地改变什么.

所谓事实.