Hacker News Reader

Comment by hntrader | Hacker News Reader

To add, quants that can't do the data engineering work are always crappy quants. I haven't seen a counter-example to that. Profitable models aren't going to be delivered on a silver platter. They need to be able to process pretty low level data effectively and build ad-hoc custom tools and data pipelines around that to test out their ideas. Otherwise they're constrained to the tools others have built and that massively narrows the search space that they're capable of traversing.

The best quants are 1/3 statistician, 1/3 developer and 1/3 trader, in my view.

View on HN

I'm not sure about crappy quants. Some people of the "quantitatively inclined trader who has learned Python" variety are never going to be good at the engineering side - it takes years to learn to be a good software engineer, and that's not a good use of time, for them, or for their employer. But they can still do useful work.

The trick is to figure out how to work effectively with those people. Build infrastructure that keeps them on the rails, refactor their code, push them in the right direction, tell them when they've fucked up, teach them little things with high leverage. As long as that doesn't turn into being their slave, that's fine.

If they're using a dynamically typed language to do monetary calculations, it's not going to be ideal.

Researchers do not need to have deep programming experience, but they have to be comfortable enough to use an environment that can lend itself itself to the problem at hand. On the quant side, unlike on the data science side, the barrier of entry on the programming side is a bit higher. To solve this problem many firms have their own internal programming language.

This is dogmatism swung too far in the other direction, IMO. There are many, many successful production code bases written in dynamic languages. In my own experience as a vision scientist/engineer, there is tremendous value in being able to quickly whip up a concept in Python and then being able to easily visualize the results. Doing this exploration in C++ is wasteful. Implementation takes much longer, the correctness brought by static typing is dubious since the code isn’t in prod, and the canned CV/visualization libraries are fewer and frequently suck in at least some way. That said, there is also tremendous value in understanding how to map your Python prototype into production code, too. Someone strong in this field can do both.

This was addressed in the previous comment

>On the quant side, *unlike on the data science side*,

Vision scientist is on the data science side. You're not dealing with monetary values where floating point error compounds on itself to the point your models become garbage. Quant work is it's own unique field with its own unique prerequisites.

Nothing precludes you from doing integer arithmetic in a dynamic language.

I’m not a quant and this isn’t my area of expertise, but, for example, I’m pretty sure various differential equation solving methods depend on variables taking on continuous values, so floating point basically must be used. Understanding the impact of that is definitely very important. Analogously, I frequently run into numerical precision issues in image processing. Understanding how numbers are represented on a computer isn’t unique to being a quant. Understanding how the choice of representation can impact prod is also not unique to being a quant. The dynamicness of the language isn’t particularly relevant, either.

>Nothing precludes you from doing integer arithmetic in a dynamic language.

You would be surprised. The second you use pandas with a custom data type (let alone any other library you'd want to use) it can randomly auto convert it to a float. Furthermore identifying when it randomly converts the type on you is a pain.

>so floating point basically must be used.

Quants tend to use fixed precision types. It is like a float in every way, except base 10 instead of base 2 so there is no floating point error.

Quants don't care about floating point precision in research. It's just applied stats

I do, because the results from my research varies when I'm validating the model.

> The second you use pandas with a custom data type

That's a pandas (and maybe numpy) issue, not a dynamic language issue. (If you want to generalize from the specific libraries more accurately than “dynamic language”, it's “using a low-level library whose type system doesn't match the host language type system” issue.

> Quants tend to use fixed precision types. It is like a float in every way, except base 10 instead of base 2 so there is no floating point error.

No, a type that is like binary floating point in every way except base 10 instead of base 2 would be decimal floating point, not fixed point. Decimal fixed point is different from binary floating point in more ways than base.

> "To solve this problem many firms have their own internal programming language."

Any examples other than Jane Street?

Goldman Sachs (Slang)

> If they're using a dynamically typed language to do monetary calculations, it's not going to be ideal.

I think this is an inaccurate take. No one in finance is doing accounting or model estimation using Python's floats; they are using numpy's float32 (or float64) type instead. I think a more accurate version of what you're saying is that static type checking is useful when modeling complicated contracts; this might be true, but I think it's not that important, as those things aren't that liquid anyway.

Jane Street's decision to use OCaml is almost as much about hiring and history as it is about language features.

> No one in finance is doing accounting or model estimation using Python's floats

We are. When your input data only has five significant figures, and probably less than that of real information, numerical accuracy is the least of your worries.

Or, they're using ints instead, at least for market data.

Fixed precision types technically. Internally they are an int under the hood, so yah basically that.

> If they're using a dynamically typed language to do monetary calculations, it's not going to be ideal.

And yet, Q.

> 1/3 statistician, 1/3 developer and 1/3 trader

How is being a trader different from being a statistician? Curious as I've never worked in finance before.

By trader, I mean domain knowledge about the markets. Statistics is the toolbox that this domain expert uses to test their hypotheses and turn them into a profitable model. But if the person isn't a domain expert and only knows statistics, their ideas about what to test won't be good.

And to knowledge, I'd add disposition. It's been years since I've been in finance, but the best traders I worked with were all very driven to succeed, to dominate, to win. Markets were really interesting to me, but I never cared much about that part.

Yeah, it's a performance discipline like any other (competitive gaming, athletics, etc) where only the top few % can succeed. If someone isn't very driven then they won't make it.

This is almost precisely the thought process behind how my company hires data scientists who build user-facing analysis.

1/3 statistician 1/3 engineer 1/3 product person who can learn the user's domain-specific needs

Reply on news.ycombinator.com