从Google到Quadrature Capital

发生了什么

本马甲从浙大CS本科毕业之后,在Google伦敦干Software Engineer一年多,跳槽到了一家在伦敦名为Quadrature Capital的对冲基金做Quant Developer。

无论未来怎么样,这都是一个人生重要的转折点。

从互联网到金融;从大公司到小公司;从旁敲侧击,到直面自己的理想。

理想

首先必须明确我的理想是开对冲基金。

做这件事的原因是要帮助那些信任我的小伙伴们获得财务自由,能去追寻自己真正想要的东西,能多一些时间分给亲朋好友。见过了太多太多的朋友把闲钱放在活期账户里,吃着活期利息。虽然财务自由的定义众说纷纭,但是大致就是资本收益要能覆盖日常的支出。那么最简单地说:

资本收益=资本\times 收益率

因为不可能在资本上帮,那只能从收益率上帮了。

自己发大财当然好,然而带着大家一起发家致富才是真男人吧!

种子

大概是大四的期间经历了那波大牛市,开始萌生了做对冲基金的想法。那时候每周在学校去听老李讲股票,讲A股背后的各种资本运作,基本面,技术面,如何估值等等,自己也操作了一段时间股票。后来见到股灾又去开了股指期货,自己看各种材料想了很多,也学了不少。

家庭是金融背景,加上我自身的技术背景,怎么看做Quant都是一个非常适合的方向。另外看了一下本站里自己写的博客,这两个方向也特别明显。这么说吧,我大概是搞技术的里面比较懂金融的,搞金融的里面比较懂技术的。虽然中间也对各类互联网商业模式有了自己的思考,但很多时候是以服务于投资的心态去了解的。所以对冲基金这个方向也就可以理解了吧。

继续阅读

状态

回顾那些自己展现出优势的时刻,大多是因为自己做了别人没做的事情,思考过别人没思考过的问题。当发现自己因为困难而想回避的时候,恰恰是提升水平的绝好机会。

分享一个看A股各种估值数据走势的方法

www.jointquant.com

上面点『我的策略』

比如要看市盈率曲线:

def initialize(context):
    g.security = '000826.XSHE'

def handle_data(context, data):
    security = g.security
    df = get_fundamentals(query(
        valuation
    ).filter(
        valuation.code.in_([security])
    ).order_by(
        valuation.market_cap.desc()
    ))
        
    # df 包含各种数据,把下面的'pe_ratio'改成别的就能画出其他数据的曲线
    record(pe_ratio=df['pe_ratio'][0])

df里有的域是
id
code
pe_ratio
turnover_ratio
pb_ratio
ps_ratio
pcf_ratio
capitalization
market_cap
circulating_cap
circulating_market_cap
day
pe_ratio_lyr
默认的pe_ratio是TTM的,非常科学。

敲进去以后,选择要想获得的日期范围再运行,结果就出来。

在Google工作半年多的一些感想

算是一些要对自己说,让自己记住的话和人生经验吧。如果碰巧能启发到其他人,那就太好了。

每个时刻都应该知道自己该干什么,并有效执行

恰逢前阵子TI6护国神翼夺冠,看到知乎上有人回答,在dota界极少有整场都知道自己该干什么并贯彻执行的。而神翼是5个人都很清楚要干什么。就像大酒神伍声视频里总是强调,打dota路人就是要每时每刻想着单位时间里收益最大的动作是什么。在为梦想拼搏的时候,也是如此。生活可以过得写意一些,但至少工作时间里,需要做到这一点。曾经有人说我目的性太强。但正是这样,才让我走到今日。恰恰相反,我不是目的性太强,而是还不够强,因为我觉得自己还没有达到这种境界。

每次只干一件事

专注非常有好处,这可能分人。就我自己而言,即使面对multi-tasking的情形,事情也是要一件一件来处理,把所有东西都打开对我自身效率的提升毫无用处。我想如何处理multi-tasking,CPU调度方式已经给了我们答案。Round-robin scheduling + priority。

生活节奏不能乱

该睡觉就睡觉,该吃饭就吃饭,该干活干活,该看书看书,该玩就玩。再也不像学生时代那样可以随便乱来了。因为如果工作了还保持这样,很可能一辈子就是这样了。Life is not a sprint, it is a marathon。仰望星空的同时,更重要的是脚踏实地,过好每一天。你仰望的星空,也许在你实力增长以后,就不再是你要的星空了。但脚踏实地带来的提升,会永远保留着。这一点上很佩服一些女孩子XD。

努力一定会有提高

这一点其实以前大学搞竞赛的时候就已经深刻体会到了。第二年打world finals和第一年打的时候比完全是处于两个境界。犹记得第一年训练结果忽好忽还,后来我甚至对训练的效果产生了质疑。我还对搞学长说:『训练根本就没有什么用,该会的知识都已经会了,那都是智商题,临场想得出来就想得出来,想不出来就想不出来,就这样了。』后来一年练多了以后才明白那种忽好忽坏,其实就是菜。理解还不够深刻,手还不够熟练。当思维熟练到一定程度的时候,解法和灵感就自然来了。

所谓的创新,也不过是把相似的东西联系结合起来罢了。人的联想能力是有限的,所以当我们面对很难的问题的时候,如果你的记忆里储备的相关内容不够多,是不可能把他们联系结合起来的。除了要提升自己知识储备的量以外,对学习到的内容加深理解也是很重要的。所谓加深理解,就是提取事物的本质特征。因为最终你能联想到相关的东西,一定是因为一些共同的本质特征。如果你事先提取好这些特征放在脑子里(做法就是平常对遇到的事物多思考),那么联想起来就容易很多了。人类的思考模式有点像广度优先搜索,遇到问题,先找最相关的一堆东西,不能解决再找次相关的一堆东西。这里简单想一下就会知道这个『相关事物的量』相对于从问题到要找的东西的距离是指数级的。所以你平常不思考做好索引,搜索起来肯定就慢得要死了…还很可能超出你能搜的能力极限,反映到实际就是,你搞不定这个问题了。

分析了这么多,就是要印证这个标题:努力一定会有提高的。能到什么程度不知道,但一定可以比原来强。

适当展示自己

这一项的目的不是为了show off,而是为了调节他人对自己的期望。有些牛人确实很低调,那是因为他们不再需要周围人改变对他的期望来实现自己的价值。我觉得之前在依图那边听来的一句话非常正确,大意是:一个人的成长是由他做的事情决定的。

如果你做的东西都是打杂,那成长的速度是很慢的。

而对于我们刚出来社会工作的new graduate来说,在大公司被boss拿去打杂是十有八九的。要去做重要的有难度的事情,就必须要秀你自己的能力。万事开头难,当你抓住机会表现了一两次以后,别人对你的期望就会得到改变。这时候拿到了一些有意思的活就不要再表现得那么强势了,不然最后不能meet老板的期望就适得其反了。

强者的谦虚才是真的谦虚。当在别人的期望里还是个弱者的时候,再谦虚就没人会注意了。记得大酒神打dota1 solo大赛的时候杀完对面的鸡打的那一句:对不起,这场比赛我要赢。人都是需要机会来证明自己的。当你被推到那个舞台之后,自然而然就会变强了。

不过呢,这一点在比较小的创业公司就没有这个问题,反正事情都干不完,you can you up…

就像@Lpuck跟我说的:你玩宠物小精灵的时候,一个怪也就是一开始厉害一点,后面你一直用,他升级飞快,就很厉害了。展示自己,做的就是让自己“看起来厉害一点”。

坚持自己的想法

别人的意见要看,但是不要随便就接纳。犹记得刚进来的时候,随便一个提交都好多comments。然后当时比较naive,觉得他们说得有一点道理的都照着改。结果一会儿你把这次的经验用到下一个提交上面的时候,又有一个另外的人来说,你这里不应该这样…然后我就意识到其实这群比我senior的人之间其实都不能统一意见。在那之后,如果不是我想过非常有道理的意见,基本都坚持自己的想法。

每个人都有不同的想法,所以外界的意见是不可能保持自洽的,能自洽的只有你自己的体系。但是当外界对某件事形成一个统一的想法的时候,就要特别注意思考其原因。虽然这种意见不一定对,但即使是错的,也值得积累下来的。这样在你带领别人的那一天,就能快速理解别人的动机并指正。

Java中重载equals方法的大坑(OOP通用)

看《Effective Java》看到的,主要讲对Java equals的override。C++对==的重载也是一样的。下文就用Java举例子了,因为是OOP的通用问题,所以很容易类比到C++。

问题描述:

class A {
    int x;

    public A(int x) {
        this.x = x;
    }

    @Override
    boolean equals(Object o) {
        if (o instanceof A) {
            return x == (A)(o).x;
        } else {
            return false;
        }
    }
}

class B extends A {
    int y;

    public B(int x, int y) {
        super(x);
        this.y = y;
    }
}

以上代码中B如果想Override equals使得y也能加入判断,应该怎么做?

也许最直接的答案是

    @Override
    boolean equals(Object o) {
        if (o instanceof B) {
            return x == (B)(o).x && y == (B)(o).y;
        } else {
            return false;
        }
    }

然而equals需要的是一种等价关系,需要满足三个条件:

  1. 自反性。即x.equals(x)为真。
  2. 对称性。即x.equals(y) == y.equals(x)
  3. 传递性。即x.equals(y) && y.equals(z),则x.equals(z)

上面这个做法明显对称性会崩盘。

A a = new A(0);
A b = new B(0, 0);
a.equals(b); //true
b.equals(a); //false

那如果加入对父类的特判呢?对称性是没问题的,但是传递性会崩。

A a = new B(0, 0);
A b = new A(0);
A c = new B(0, 1);
a.equals(b); //true
b.equals(c); //true
a.equals(c); //false

实际结论是B根本没有办法重载一个合理的equals。
证明:因为不能更改A类的equals,因此A的实例equals B的实例的时候一定会只判x然后返回true。那么根据对称性,B类的实例equals对应A类的实例的时候,也一定要返回true。所以如果想要在B的equals中判断y,上面传递性的问题一定会出现。至此对称性和传递性不可能同时满足,所以不可能存在科学的重载方法。

这个从本质来讲,父类和子类的相等是一种偏序关系,然而equals要的是等价关系,所以被父类强行equals为true以后,就怎么也救不回来了。

那么我们放松一下条件,允许修改父类呢?
从上面的教训可以知道如果子类和父类之间可以相等的话,一定会GG。那只能做成不相等了。
于是直接getClass判吧,直接看new的时候是什么的类,不同就直接判不等。那么假如A多了一个方法。

    private static final Set <a> luckyA = new HashSet<>()
    static {
        luckyA.add(new A(5));
        luckyA.add(new A(10));
    }

    public boolean isLucky(A a) {
        return luckyA.contains(a);
    }

这个isLucky写得再正常不过了,然而如果我们那么做,那这个isLucky对于所有子类就失效了。这违背了OOP的Liskov substitution principle
Wiki上的定义:Subtype Requirement: Let $latex\displaystyle \phi (x)$ be a property provable about objects x of type T. Then $latex\displaystyle \phi (y)$ should be true for objects y of type S where S is a subtype of T.

你也许会想,不加这个isLucky不就没有违反了吗?是的,但是只要A中有依赖A的equals的方法,就会违反这个规则。

然而你觉得因为子类的一个equals问题,给父类定下不能依赖自己的equals实现任何功能的规矩,合理吗?

综上所述,父类与子类equals可以为true是不行的;然而一律为false又会break OOP的原则。于是我们可以推导出即使允许同时修改父类和子类的equals,也没有任何合理的写法。这也是《Effective Java》给出的结论。

形式化描述一下这个结论:

如果父类是可实例化的(非abstract,非interface),子类如果添加了新的域想override equals把这个域放进去,没有任何一种override的方法是合理的。

那么该怎么做呢?答案:不要用继承,用组合。然后加一个fallback的方法。

class B {
    A a;
    int y;

    public asA() {
        return a;
    }
}