lpage

As GP alluded to, there’s not really a proper ordering. If you’re talking ease-of-reasoning from a formal methods standpoint, linear types (or ordered types for that matter) are “superior” to affine types. By extension, when compiling to machine code for real-world computing architectures, linear types have advantages. They lend themselves to aggressive compiler optimization, instruction and data cache-friendly access patterns, and automatic parallelization and vectorization opportunities. All of those things boil down to proving equivalence, so the ability to mathematically reason about code has both testing and performance implications.

Affine types are less foreign to most developers. The safe fragment of Rust’s ownership model is an example of an affine type system...and that’s already a bit of a lift for folks new to the borrow checker. Affine types are harder to reason about than linear types, but still much easier to reason about than the Normal [1] (in the proper noun sense) types used in most PLs.

[1] https://en.wikipedia.org/wiki/Substructural_type_system

The three most recent HN discussions on CRDTs are all worth perusing.

[1] is an excellent tutorial that assumes no initial familiarity with CRDTs or the math that underpins them. It walks you through both the formalisms and the implementation, which is pretty key to understanding why making real-world CRDTs flexible enough to handle things like rich text editing is hard.

[2] is a talk that goes more in-depth on the hard parts

[3] goes deeper on OT vs. CRDT

It's worth noting that many of the CRDT discussions focus on collaborative text editing. That's a really hard problem. CRDTs are (and have been for some time) a useful primitive for building distributed systems.

[1] https://news.ycombinator.com/item?id=23737639

[2] https://news.ycombinator.com/item?id=23802208

[3] https://news.ycombinator.com/item?id=22039950

Also an industry practitioner, with an auction theory/mechanism design background. I agree with portions of what you said, but:

> queues are over sized with liquidity when the tick size is larger, creating more adverse selection for market makers

That's not right when it comes to price-time priority (pro rata is a different story). Consider that statement in limit; if the queue was of infinite length, there would be no trade-through, and no adverse selection. I'm talking about the price level penetration/second price dynamics that are relevant to a tick size conversation, not the more nuanced FV/winners curse stuff. To your subsequent point about bid-ask bounce, that's precisely why being towards the front of the queue on a deep bid and ask is valuable.

> Market makers have an incentive to do this when the tick size is large in order to preserve time priority.

> I have run market making algorithms in both small and large tick stocks and found both categories to be equally difficult.I have run market making algorithms in both small and large tick stocks and found both categories to be equally difficult.

There's an efficient frontier parameterized (to first order) by the probability of a round trip (spread width or otherwise), the payout upon success, the loss upon failure, and the number of RT opportunities per trading day. As you noted there's not an easy way or a hard way given that these considerations are not orthogonal, and they're correlated with tick size.

I haven't seen this mentioned yet, so I'll mention it explicitly. As it stands the 611-612 series rules pertaining to sub-penny pricing allow for average price executions; a large percentage of U.S. equities volume already trades at mid or within the spread, both principally and on venue. There are far bigger fish to fry in the market structure debate.

This pencil and paper approach to breaking up work is good at parallelizing things that don't appear parallelizable at first glance, e.g. prefix sum [1]. Compilers are good at identifying opportunities to reorder instructions in ways that break low level data dependencies. They tend to miss the big higher level opportunities like this.

[1] https://en.wikipedia.org/wiki/Prefix_sum#:~:text=A%20work%2D....

It's fantastic that Cloudflare is offering this. You might want to reconsider calling it CNI, or at least clarify that CNI is just an umbrella term for PNI and/or public peering. I'm the person that handles the PNI/IX stuff and after reading the article but before reading your comment I wasn't 100% sure if CNI was something Cloudflare specific (which we wouldn't immediately adopt) or PNI/public peering at an IX (which we would).

Ed Thorp's "Beat the Dealer: A Winning Strategy for the Game of Twenty-One" is one of the best books ever written about quant trading...despite not being about quant trading.

That was true until 4.08. OCaml now supports monadic let bindings, and more generally, user defined let bindings [1].

You get the benefits of ppx_let (Jane Street) but in a more general and syntactically nicer form. I still wouldn’t call it as nice as do notation in Haskell but it makes monads highly usable in OCaml without the need for an external dependency.

[1]: https://github.com/ocaml/ocaml/pull/1947

> The problem with learning about hooks is that they're not generally applicable knowledge about computing or programming.

That's true of the hooks API specifically, but not true of the underlying abstraction. Hooks are (informally) algebraic effects - one of the coolest and most general abstractions for inspecting and manipulating a program's control flow [1, 2]. Algebraic effects are still somewhat niche and most programmers haven't encountered them in name or in practice, so in that regard, hooks are actually one of the fun cases when learning a new API is mind expanding.

[1] https://github.com/ocamllabs/ocaml-effects-tutorial#1-algebr...

[2] https://overreacted.io/algebraic-effects-for-the-rest-of-us/

Congrats on the awesome project. In case you haven’t come across it ACAT [1] might be of interest, especially if word rate becomes a limiting factor in communication for you dad, or if he’s interested in using a computer. ACAT is highly flexible around how it accepts inputs. To that end, you might be able to take what you’ve done and open it up to a broader audience by writing an extension that turns the iPhone with force touch into an input sensor, with or without the use of Morse.

[1] https://github.com/intel/acat

Pros of asm goto: it's useful for introducing low overhead tracing and debugging abstractions. Tracepoints in the Linux kernel are one example [1]. It's also used for implementing certain Meltdown/Spectre mitigations [2].

Cons of asm goto: as parent points out, asm blocks are largely opaque to the compiler, which stands in the way of optimization. Control flow analysis can't take into account internal jumps, and for GCC at least, every asm goto block gets flagged as volatile. That disables whole classes of optimization.

Unless you're relying on hardware-specific instructions that the compiler doesn't know about or expose as an intrinsic, there's always an alternative to asm goto. That said, those alternatives might prove more expensive than the loss of optimizations precluded by the use of asm goto [2].

The pros/cons of including asm goto in clang were discussed in [3].

[1] https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748....

[2] https://lwn.net/Articles/748074/

[3] http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239...

> "Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang"

This is big. Support for asm goto was merged into the mainline earlier this year, but now it's released [1]. Aside from the obvious implications of this - being able to build the kernel with LLVM - working with eBPF/XDP just got way easier [2].

[1] https://github.com/llvm/llvm-project/commit/784929d0454c4df6...

[2] https://www.spinics.net/lists/netdev/msg544057.html

Incidentally, the execution model and abstract machine for OCaml (more accurately Caml Light) is based on Xavier Leroy's paper "The ZINC experiment: an economical implementation of the ML language" [1] - an all time CS classic. Reading that paper and the surprisingly approachable source code for OCaml's interpreter [2] is a great way to demystify functional compilers.

[1] https://caml.inria.fr/pub/papers/xleroy-zinc.pdf

[2] https://github.com/ocaml/ocaml/blob/trunk/runtime/interp.c

Previous discussion of the same article [1]

Discussion of another good article on the Therac-25 (with pictures of the machine) [2]

[1] https://news.ycombinator.com/item?id=7992548

[2] https://news.ycombinator.com/item?id=12201147

Haskell and ML languages look like symbol soup when you're used to mainstream/C style languages. Once you understand some of the basic syntax they become quite readable and easy to reason about as a series of transformations.

Step one, which applies to most functional languages, is knowing how to read a Hindley-Milner type signature [1].

Armed with that you can often gain a surface level understanding of what some function does - and what the program does in aggregate - just by reading type signatures and seeing what calls what.

Hoogle [2] is a good resource for figuring out Haskell syntax, like what's up with all of those $ signs.

Converting OCaml to ReasonML syntax with sketch or reason-tools [3] makes OCaml less foreign.

With basic knowledge of Haskell and ML syntax you'll find many FP languages readable.

[1] https://drboolean.gitbooks.io/mostly-adequate-guide-old/cont...

[2] https://hoogle.haskell.org/

[3] https://reasonml.github.io/docs/en/extra-goodies

Like Dropbox? I’ll just leave this here: [1]. The details are seldom easy.

[1]: https://news.ycombinator.com/item?id=9224

Related: the Farey sequence [1]. Well worth investigating if you found this paper interesting.

[1] https://en.wikipedia.org/wiki/Farey_sequence

Oblivious transfer [1], especially as it pertains to secure multi-party computation (MPC). It's not as easily visualized as Diffie–Hellman or Shamir's Secret Sharing (both of which have already been mentioned), but a good chunk of what MPC allows for [2] seems like magic.

[1] https://en.wikipedia.org/wiki/Oblivious_transfer

[2] https://en.wikipedia.org/wiki/Socialist_millionaires

Their original white paper [1] is one of my favorite math-meets-software reads. Readable, elegant, and real world.

https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf

For anyone else interested: https://git.kernel.org/pub/scm/git/git.git/commit/?id=7913f5...

As a self contained, foundational course, Georgia Tech's OMSCS offering [1] is solid. Charles Isbell and Michael Littman are great at building intuition into equations.

[1] https://www.udacity.com/course/reinforcement-learning--ud600

From grandparent:

> What's with the "AI" positioning?

It's an implementation detail that’s abstracted away from end users, but also one of the enablers/answers to the "why now" question on a business level. This article happened to focus heavily on that, probably because the other aspects (distributed systems and mechanism design) aren't broadly relatable.

> Seems like you just need really fast optimization...A robust, shallow, transparent approach seems both safer and easier to sell.

With you on that. Academically/literature wise our approach is AI + ML given that it has priors, and doesn't rely on oblivious search techniques such as branch and bound or LP rounding for end-to-end solving. The article states that there's a "black box" involved, which is incorrect. When we talk to regulators and market participants we're very clear on how objective and deterministic the process is, and the bounds. We've structured the problem in a way that uses the economics of a double auction as the floor, meaning that any match we return is equivalent to or better than what would have resulted from matching against a conventional limit order book (CDA) or batch auction. That, combined with the timestamping aspect, results in something that's more fair, transparent, and auditable than the existing market structure.

From parent:

> There is no collapsing it

This is correct for truthful approximations and most formulations of combinatorial VCG. We don't fall into that camp, but we're still left with something that is worst-case exponential.

> ...sort of approximation

In many cases we can find the true optimal, and the cases where we can't become adversarial inputs for the AI and are still subject to the bounds described above. This has to do with the empirical runtime versus worst-case runtime of an algorithm, which is a fascinating field in its own right.

Yes. Two of the more straightforward ones involve market impact and spreads.

Short term market impact results from supply and demand imbalance. As such, multi unit blocks are either an asset or a liability, depending on how you're positioned. Block venues are largely predicated on natural crosses, which are somewhat rare, given correlation across the street. Some market makers will quote block size for conditional orders, or against individual clients, but due to the limitations posed by double auction (mainly the inability to ensure atomicity between getting a hedge off and the outright), it's not done on a firm, multi dealer basis. Combinatorial auctions allow for multilateral block market making on a firm venue, which solves a ton of agency problems and improves liquidity.

Similarly, spreads on anything except for the most liquid financial products are generally superadditive when viewed from the taker's standpoint, given that you you'll need to either cross spreads or accept legging risk to execute.

Hi, Kelly and Steve here, founders of OneChronos. Happy to answer any questions.

In short, we're applying combinatorial auctions to financial markets. Combinatorial auctions are generally speaking computationally intractable. Our art pertains to structuring the problem in a way that's a good fit for finance, while remaining tractable. The classical approach to solving combinatorial auctions for indivisible goods on the "hard" cases (ones without a totally unimodular constraint matrix) generally involves encoding the problem as an integer program, at which point you're faced with solving an NP-complete combinatorial optimization problem. Needless to say, that doesn't lend itself well to financial market speeds or scales. As such, we've taken a different approach based around guided search, similar to AlphaGo.

The Bloomberg article doesn't go into this, but the other half of the model involves inverting the traditional market event loop. As it stands, market participants receive market data and fills from geographically discrepant trading venues, action it via their models, and update their resting orders accordingly. We invert that model by putting points-of-presence equipped with highly precise network timestamping infrastructure at all of the major financial data centers. We use said infrastructure to timestamp snippets of code (our bidding language) that market participants send to us, as well as market data from other exchanges. At discrete, random intervals on the order of every ~100ms we resequence data in accordance with its origin timestamp (buffering by max time-of-flight) and feed it into our client's code for them to act upon and enter orders into our combinatorial auction. The net effect is an environment that's agnostic to geography, immune to latency arbitrage, and free of the traditional exchange race conditions. That's a huge win for everyone currently stuck in the prisoner's dilemma outcome that results from continuously reinvesting in what's now commoditized low latency trading technology.

Combinatorial auctions aren't a new concept, nor are Lamport clocks/distributed systems primitives based on timestamps, nor is the notion of using code as a proxy bidder (ad exchanges). Our art is around making combinatorial auctions practical for finance, both from an API standpoint, and from a computational tractability one. There's a huge impedance mismatch between what market participants want to do from an economic standpoint (trade on a portfolio level/express contingencies/force atomicity across actions) and what they can currently do with traditional limit order book/auction based venues (simulating the aforementioned by cancel/replacing as quickly as possible). Fixing this will be a big win, and broaden market participation.

Etherscan has an option for linking the source [1], in which case they compile it and verify the result against the bytecode that's publicly available.

Edit: the source itself is based off of [2]. The custom part is ```contract PonziCoin...```. It's well written in the way that all Solidity code is well written...

[1] https://etherscan.io/verifyContract

[2] https://github.com/humaniq/ico-contract/

This has seen ~$10,600USD worth of love so far [1]. The contract source is comedy gold [2].

[1] https://etherscan.io/address/0xe3f64dc522a66405c51d96aae2342... - accessed at Wed Jan 24 16:10:39 EST 2018

[2] https://etherscan.io/address/0xe3f64dc522a66405c51d96aae2342...

Nope, just an evening hack :)

As for what's next, I'm adding time as a dimension for analysis, entity recognition, and an .mbox source for e-mail. That aside, feature requests and PRs welcome!

I'm not sure about that error specifically, but I just simplified the environment.yml file s.t. only direct project dependencies are included. Hope that helps!

Hi, author here. Happy to answer any questions. Check out the notebook itself for a sample analysis. If you're on mobile, make sure to request it as a desktop site or GitHub will render it raw.

Sorry about that - I'm relying on the notebook itself as the example. If you open it up, you'll see a full analysis.

For those interested in the intersection of computer science and economics, I highly recommend the freely available Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations by Yoav Shoham and Kevin Leyton-Brown [1].

[1] http://www.masfoundations.org/mas.pdf