physguy1123

I'm pretty sure you misunderstand market orders because by definition they are only visible to the market after they have traded, so nobody can get ahead of you or do sonething irrational before your order lands.

I would agree that market orders are a bad idea at any meaningful volume (outaide of retail sizes) because of liquidity and routing reasons

I know of certain firms that will never reject retail orders unless they're truly invalid and will just fill at a loss to keep their flow.

Market makers have absolutely no incentive to quote tight spreads up until the last minute where they might have some idea about the price, or maybe not so they don't quote at all.

A lot of 'alternative solutions' to the continuous limit book assume that there's some other mechanism for price discovery so people make informed decisions, but really it is the book itself which provides that information.

Manning rule dictates that retail orders held by a market maker must be filled before any other orders (or equally that fills must be given to the retail order), brokers don't look kindly on firms that reject customer orders with any regularity, and anyways retail flow on a volatile+wide spread symbol are loved by market makers.

Vanguard states that hft activities have lowered their trading costs, so I don't think this claim is necesarily true.

You might never exercise the option, but you could probably resell the option at a far higher price

With options, buying deep OTM puts won't result in an immediate impact on the underlying market because they have such low delta and market makers aren't going to move a lot of spot to hedge it.

Quant finance has been doing this stuff for years, high frequency or not, market or non-market data, deep learning or not. In general, quant finance did (big data, cloud orchestration, machine learning, neural nets, realtime web app stuff, etc) before it was cool.

Sentiment fund is doing nothing new, and will probably find that 'just deep learn the markets' won't work while getting crushed on non-deep learning things like simulation, portfolio optimizatio, and execution cost.

Also, there are already firms that very reliably make vast returns on predicting price moces in the market.

Really this blog post is uninformed bloviating on trading and financial markets.

None of the market makers as far as I know consider retail orders to carry any information at all, which is precisely why they love then so much.

They can fill retail orders with no real concern about adverse selection (unlike on an exchange where an informed institution is trading against you) and make much more of the spread per trade. Hence why they pay for the orders and give price improvement

Source: work at a market maker

That's easier said than done. If you don't already have proper market making infrastructure and strategies you'll probably lose money trying to do that. Add in market makers paying per order and it doesn't make sense

You need differential calculus in R^n, but there's no need for the full force of differential geometry. Also, I don't think that measure gains much in terms of understanding, but it certainly is needed to do some proofs the proper way.

I agree that cutting corners is something I would be super skeptical of in this degree. It should really be an offshoot of a mathematics program, not a CS program with the bare minimal mathematics included. It's end goal is probably PR, money grab, and pumping out students that are really attractive for doing analytics grunt work.

To be honest most of those are covered at a good-enough level in the sophomore and junior years of a math undergrad. You don't need measures, differential geometry, or even epsilon-delta analysis to do ML which pins the calculus requirements pretty much to whatever proper multivariable calc class one takes in their sophomore year

Edit: if my school wasn't so obsessed with teaching CS majors diffeq (probably just as a gpa filter...), they could already fit in the requisite math for a solid ML understanding

> It sounds like a CS degree where the electives are predetermined. Why couldn't they just make this a concentration when it's so intimately intertwined with CS

Unless they really mean "CS-degree with surface level knowledge of stats" this should really be an offshoot of the math/applied math department, not CS

Unless you mean some sort of differential topology, those are rigorously covered in and respectable math undergraduate.

A lot of relatively fixed-function peripherals tend towards hardware, but the industry is moving away from pure speed (alternative interpretation: pure speed people failed) and for many strategies software can be more than fast enough and the flexibility benefits are worth it. That's not to say there aren't pure hardware strategies, but most of them operate in tandem with latency-sensitive software strategies as well.

I use this all the time, it's a wonderful tool! One feature I would really like is the ability to have multiple text filters, either as part of the query or explicitly. I often find myself searching for a certain intrinsic (or family of intrinsics) that operate on a certain bit width.

Otherwise, this is one of the best cpu documentation tools I've used.

As a side request, it would be amazing if the intel documentation on non-temporal memory operations and sfence+lfence had more specifics about how they interact with the rest of the cache hierarchy and the load/store subsystems.

Nobody will tell you about the platform itself because those are closely guarded secrets.

A more specific description of the problem might help though. There's a huge amount of data in many forms, a huge amount of unpredictable major events, a lot of noise, a lot of hidden data (take hidden orders on exchanges as an example), and any action you take is going to affect the market. If you do something dumb, like place a bad order , nobody would take it in simulation but they would in real life. This makes it extremely difficult to understand why your model performed the way it did, what needs to be fixed, what sort of risk it entails, etc.

Research platforms help answer these questions without quants having to do do complex bespoke analysis over and over again.

Send an email to the address in my profile. A team in my company is looking for talented hardware engineers and pays above what you want, along with great work/life balance and benefits.

FPGAs are certainly extremely useful but most hft is moving away from purely speed focused stuff. Only one place that I know of does asics like that and it was a complete boondoggle. The difficulty of changing, printing and verifying an asic just doesn't make sense especially once your latencies are a tiny fraction of exchange jitter, and the smarter player saw the trade you wanted to make way ahead of time anyways.

Copy and clone have specific meanings and must resolve to the type of the class itself - basically copy or cloning a class of type A gets you another class of type A always.

It's possible, from a language sense, to have an implementation of box that could directly clone the trait, but I don't believe it would have a reasonable api.

> there is a trait of Material that has a function on it, and then there are different "implementations" of Material with different implementations of that fn, and can have arbitrary data stored against them.

Do you mean like a class hierarchy+virtual functions, or just having allocated data of arbitrary length past the end of a struct?

If it's the former, C++ fares no better in this regard but it's pretty easy to do in Rust. You just have a cloner in the interface. If it's the latter, that's pretty nonstandard and Rust doesn't make that easy for good reason. Unless this raytracer is doing something wild the code should hopefully be refactorable into a more normal struct+trait layout.

> In any case, my point remains the same: it is very challenging-- at least for someone used to just creating data structures and letting GC handle it-- to build code that does what you want, and you spend large amounts of time "fighting" the compiler.

This is a fundamental problem of languages that don't use a managed runtime. You either take the C route and just hope the user did things right or try and enforce it somehow. If you're used to writing GC-code, your problems around understanding object lifetimes are probably going to manifest as 'fighting the compiler' with Rust whereas with C they would manifest as intermittent and hard-to-track segfaults.

If I follow the github in your profile and take the Rust issue you opened, in C that mistake may never manifest except in certain control paths after you've turned off debug mode, and you'd compile code easily but sit banging your head against the wall.

I write a decent amount of Rust and write both C and C++ professionally, and in most cases Rust is drastically easier to write nontrivial code in because it catches all sorts of lifetime issues and has so many QOL improvements.

There's nothing at all preventing you from having a Vec in a struct, and the use cases for variable sized structs are pretty rare. It sounds more like you conflated having a different problem with having a Vec be in a struct and stuff like that poisoned your further attempts to understand the language

This is certainly true of most stock-picker type hedge funds, but there are legitimate strategies that aren't a shirty replication of an index fund. Unfortunately, stock-pickers have somehow become most of the industry seem to be most of the industry (probably because there's no real talent or capital constraints on them).

> With regard to entering the industry, it's pretty hierarchical, and can be siloed: techies do tech, traders do trading, and there's not much crossover.

Not really true. It's true that there are software roles that don't interact with strategy much, and often traders/quants that don't do much proper software. But in many places the line can be very blurry.

> The most reliable way of entering the industry is to get on a graduate program and work your way up. Failing that, a quantitative PhD might get a hedge fund or HFT interested.

HFTs and hedge funds all hire of plenty of new grads and experienced-but-not-PhDs doing quant/trading style work - Hudson River, Jane Street, Two Sigma, Tower, I think Citadel all will.

This is just a relative jump instruction and on intel can be just 2 bytes, although an ignop might fit into one.

It wouldn't solve the icache problem though. Also, writing to data inline with code would be super problematic performance-wise with modifying icache lines that currently are being executed from.

That's why I said it's tricky to deal with interrupts, but possible if the effort is worth it to the use case. One could run the code in a kernel module which masked interrupts or use restartable sequences and cleared sse in the kernel when in certain code sections.

SSE registers will never get stored to ram without emitting explicit instructions (or getting an interrupt) to do so on any Intel/amd cpu as far as I know. It can be tricky to deal with such situations, but if you have a stretch of code where you can stop that registers can be used to hide data from memory.

I reliably see gains from unrolling relatively simple loops on very recent cpus. Going to 8+ iterations is usually overkill, but it can help. Sometimes one can split a dependency chain by unrolling as well.

Trades made with/without insider knowledge reveal the same amount of information to the market since the market doesn't know what made you decide to trade. It's illegal for a few reasons - it encourages quid-pro-quo relationships between investors and businesses, makes the good investment opportunities only available to those with privileged relationships (and magnifies 'the rich get richer' problem), and poses serious conflict of interest problems to everybody involved.