税制相关

下雨没事,就简单画了下个税的一些曲线关系图.

本来预期会是一个带衰减抑制形态的曲线的.
类似sigmoid或者其他一些log/e指数形态.

但实际拉长之后还是一条相当平滑的直线.
即使考虑各个征收区段的不连续关系的话,总体还是很平滑的.

从图形上来说只是简单地把梯度降低了而已.
本质上还是一个准线性的关系.

然后是看了下收入没增长1%对应的实际增长会是多少.
拉下来的话,幅度不会超过千分之2,而且对于20w左右之后的,反而有一个比较明显的回升.

即超过20w之后,实际的每1%增长幅度更接近与1%.
这个应该说是跟设计初衷背离的.

因为个税的目的应该是一种类平均性策略.
保障社会总体的收入在一个可比的平坦区间内.

所以形态上来说,应该是收入越高,衰减越厉害.
一阶二阶应该都是有这种抑制作用.

马太效应的一个核心点就在于资源丰富程度造成的可用手段多寡的区别.
一个比较陡峭或者说跨度比较大的收入水平分布的话,就更容易造成可用工具的区分和隔离性.
从而进一步地巩固这种分布形态.

因为工具本身也是有一定供需关系的.

如果层级越多,每个阶层能变动的方式就越多.
而反过来,只要有任何一个上升变化途径阻塞或者出现供需矛盾的话.
整个层级流向就可能割裂了.

因此对于这个优化函数来说,目标应该是保障曲线分布的平坦性/flat.

另外一个是应税金额的抵扣项.

就个税来说五险一金是在抵扣项目当中的.
而五险一金的性质是一种公共保险/储蓄.
是一种某种形态的社会共同基金.

名义上来说,这个都是归属于个人财产收入的.

所以理论上来说,在重个税的前提下,通过这类公共基金提供的合法避税项目做一些定向诱导是可行的.

因为名义上来说,它能减少个人因为所得税而造成的税务支持.
只不过以另外一个明目存在在社会共同基金下面.

而这个共同基金不考虑实际政策和规约管束的话,形式上就是另外一种国家融资手段.
面向的是全体社会成员.

它跟直接税收的区别在于,税收是一种某种形态的服务管理支出.
而抵税项目更像是一种贴现借款.

不仅不是一种支出,而是一个有息投资.

实际中的问题一是回报率.
二是赎回限制.

一的本质还是因为的二的流动性约束.

二存在的原因应该是为了减少形成一种逃税通道.
所以需要有锁定期和赎回条件约束.

这个可能可以以罚息或者其他更直接的数值手段去规避掉这类规则漏洞.

然后剩下的就是基金本身的收益率市场竞争性了.

这么看的话,现代税收可能更像一种主动的价格歧视策略.
目的定位可能不是直接的无偿征收和统一管理分配.
而是一个市场化的投资投票方式.

通过给定的避税渠道间接选择社会分配发展方式的一种形式.

InvokeDynamic的一些问题

之前一个想法.

就是Java里实现类似go的interface的形式约束.
即可以后期规约出一个interface然后把一个object cast过去.
类似new Anycast().adopt(object).newInstance(Interface.class)的用法.

最简单的方式当然就是Invocationhandler的Proxy方式.

但这里有个问题就是interface的default method.

因为default method的作用可以是用来定义一个control flow template.
比如Stream API的collector.
通过暴露一些可实现的流程细节,在给定的流程框架内适应.

而proxy的实现实际上通过实现给定interface的所有方法做到的.
这也意味这default method被事实上override了.

这里有几种可能的方法.

一个就是实现一个带有default method的instance.
但由于实际上各个abstract method归属的this/method receiver不同.
所以实际上也并不能够达到目的.

另外一个思路是method handler.

因为invocation handler里给出了proxy object的instance.
所以在lookup能拿到method handler的前提下,就能bind到method receiver.

而这个的问题也就正在于lookup的限制性.
并不是像老一辈的reflection API一样是相对很随意的.

lookup对interface和method的访问性约束比其他要严格许多.
正如public要求或者同package之类的.

所以在proxy的框架内,实现还是有一定的局限性.

那么考虑绕过proxy,直接自己生成的方式.

操作bytecode的话就相对简单很多.
对于abstract的,直接stub就行.

而default method跳过便是.
因为本意就是要default.

既然动用到了生成字节码的方式的话,那么就还有另外一个思路.
就是stub的方式.

可以是走invoke dynamic.

这里有一个好处是bind method的时候,从API层面来说会简洁很多.
因为直接findVirtual就可以了.
而且不用为default method做特例处理.
因为default method也是可以直接bind到的.

唯一的问题是invoke dynamic的bootstrap method是没有instance上下文的.
也就是说没有this之类的概念.

理由要理解起来也很简单.

因为method handler更像是一个语言层面的code reference.
invoke dynamic做的是late binding就类似于把相关的代码实现剪切过来.

也就是类似运行时的instruction的copy & paste.

只是代码块的复制的话自然也就没什么this的概念.
因为从calling convention来说,method receiver是第一个push到栈上的参数.
是属于parameter的范畴.

并不在实际的代码逻辑内.

所以在bootstrap method里是找不到这些东西的.

一个折中的办法是通过static field去做dereference.

因为static field的访问是没有什么receiver的概念的.
也就是在bootstrap method里是有办法访问到的.

唯一要考虑的方式就是如何寻址的问题.

因为如果这个generated class是共享的,那么就需要在bootstrap method里找到一个唯一确定的"this"的方式.

比如,如果这个this的寻址是通过一个static map/set来实现的.
就需要保证任何时候这个map/set里只有一个唯一确定的元素.

也就是需要在外部this的注册以及bootstrap的调用的时候考虑锁相关的问题.

还有就是这个map/set里元素的引用处理问题.
因为如果不考虑的话,GC至少会有一个strong reference在这里.

所以这个可能是个比较复杂且不容易对的方案.

另外一个方式是generated class是实际上的singleton.
这样的话static field就是实际上的instance field.

既能够在bootstrap method里resolve.
也能把reference规约到instance本身的生命周期里去.

唯一的问题就是对于这类instance如果有比较多的需求的话.
对应的就会产生很多基本雷同的class.

所以invoke dynamic这系就有一个很微妙的设计上的冲突,或者说问题.

因为它基于的method handler/callsite的概念是相对于面向纯粹指令性的.
并没有太多的语言语法层面的约束定义.

用一个可能不太确切的词形容就是纯functional的,并不是OOP的.

当时要让它在语言或者说runtime层面能够跑起来的话,有必须是依赖classloader去define生效的.

当然,不是说method handler不能直接invoke.
而是method handler的构造离不开class.

就像很诡异的.
method handler对应的原则上来说是一段执行代码.
没有this,没有method receiver,只是纯粹的function.

但是你在语言侧面你又没办法把一段哪怕是static的code block或者method直接转换成method handler.
而还是需要通过lookup的方式去获取.

而lookup本身又非常地具有局限性.

一个比较实际的例子就是anonymous class.

因为anonymous class实际上是final类protected的access.
所以并不是能够随时随地自由地通过lookup转换成method handler.

就像自身的lambda机制.
实际上是通过在当场对每一lambda生成对应的相互独立的invoke dynamic bootstrap handler做到的.
而这,也恰恰就是为什么lambda没有"this"的原因.
因为从语法层面上来说,lambda跟形式类似的anonymous class实际上是完全不同的两个东西.

而且另外一点就是,method handler貌似是没有什么异常概念的.
这个也好理解,因为是code reference.

但是lambda却在语法层面保留了exception.

于是这里就有一个相对分裂的地方.
一方面因为实现的原因,没有this概念.本质上是完全不同的东西,只是具有类型使用形态.
另一方面为了保持折中形态的类似性,引入了从实现层面上来说完全没有意义的exception声明的语法一致性约束.

仿佛就是一种应该保留的没有保留,而不应该保留的偏偏保留了下来的感觉.

所以有时候感觉这是一个很别扭的实现.

一个试图表征纯粹指令集合的东西,却摆脱不了class的约束.
一个本来就是把method receiver当作参数传递的实现,却在callsite里抹掉了痕迹.
一个明明为了实现简明抹去了exception的method handler,却在lambda的语法层面做了保留.

在加上lookup本身的各种限制.
感觉鸡肋了很多.

或者说,给人的感觉是一个比较糟糕的补丁方式.

物美价廉与流量为王

考虑物美价廉这个词.

在理想情况下,这个反映的应该是一个均衡点.
也就是边际为零的情况.

那么这里有两种情况.
一种是价格price P的margin为零.
另一种则是数量unit U的margin为零.

当然,确切地说是两种margin处于动态零的情况.
但至少说构成因素里存在着这两种情况.

考虑P为零但情况.
也就是价格的提高无法在造成额外的收益增长.

定义收入Revenue R=P*U - Cost.
即总体销售去掉支出成本的部分.

而cost可以拆解为per unit的成本.
所以有
Revenue=(Price-Cost)*Unit.

考虑供需曲线.
销量即使需求供给Supply满足需求Demand的部分

在S D 即U=min(S,D)

即有
Revenue=(Price-Cost)*min(Supply,Demand).

考虑供应曲线Supply.
某种程度上来说跟Revenue是有反身性的.

即随着R的增加,Supply是呈增长趋势.

也就是说,它可能或使得min(S,D)产生一个flip,从而使得R产生一个jump point/非连续变化点.

可能也不一定是非连续的.

因为如果如果min的bias方变了的的话,也即S和D的倾向性有所交换的话.
那也是发生在S=D的临界点.

所以在P-C固定的情况下,它更可能想是一个对称曲线.

考虑更复杂一点的情况.
一般来说,Supply的增长一般会伴随着Cost的变化.

一种情况是规模效应,使得cost减少.
一种是增长并不不是scale out的,规模的扩大会带来成本的相应上升.

在前一种情况对应的是对称曲线右侧的相应区间拉长.
因为P-C的价衰减地更慢,所以相应地,在给定R相等的情况下,min的衰减要到更大的区间.

同理,后一种情况则会缩减右侧区间的跨度.

这里的一个假设是P-C是一个常量.

那么,考虑非常量的情况.
即一般的P非固定值的情况.

对于任意一个P取值确定的情况下,R曲线的形态和变化特征都是前述的情况.
而P不同所造成的影响是S和D的平衡点的变化的不同.

也即是对称曲线的中心点的区别.

P越高则对应的tipping point的取值会越靠左.
因为价格上涨意味着需求的减少,也就是供需曲线的左移.

那么现在考虑物美价廉这个词.

不考虑是否真的价廉,而是作为一个fix price.
那么一个rational的解释就是它的selling unit还处在堆成曲线的左侧.
也就是说供应还未过剩.

所以,在不触动P margin的情况下,U margin还有增长的空间.

而在P margin为零的情况下,再通过价格下调驱动曲线右移的话.
也就是压榨U margin的阶段.

也就是说,这里的模式是规模化,然后才是价格战.

如果是反过来.
即先压榨U margin呢?

U margin对应的是对称曲线的右侧外延属性.
也就是尽可能地让tipping point右移.
也即供需曲线的右移.

曲线右移对应的是Unit取值的右倾.
意味着供需平衡点是一个较大的值.

imply的就是需求的理性最大化.

也就是说,在这种情况下的策略是,一开始就是覆盖所有可能潜在的用户.
在这个规模/Unit margin归零的情况下,在通过提高P margin进一步提高Revenue.

这就是所谓的流量模式.

先覆盖尽可能广的人群,然后在此基础上提升价格.

实际上这里隐含的另一个中发展策略就是.
但coverage达到100%或者effective monopoly的时候.
消费者或者说用户是丧失了议价权的.

也就是为什么,一般来说互联网免费/流量模式最后指向的都是一两家公司的原因.
因为在纯市场的lockin状态下,基本上就是一个爱用不用的垄断地位.

而且相比物美价廉状态的,先价格天花板,再红海拼杀的情况.
流量模式有一种天然的一劳永逸状况.

因为红海情况的一个更大可能性的后果是被淘汰和利润的一路下滑.
而流量模式一旦建立起来,基本就是印钞机了.

那么流量模式就是完美的了么?

也不尽然.

它的两个要素.
一个是供给独占.
一个是需求锚定.

实际上来说,供给独占最后依赖的还是需求的锚定.

因为只有不可替代性才使得100% domination有意义.

在存在可选性的前提下,流量模式也是不一定成立的.

这么一想的话,欧盟在这方面确实有着很了不起的远见.