lpage

Thought of the day: bridge Grenade with like CλaSH [1] and realize network topologies directly on an FPGA.

[1] http://www.clash-lang.org/

The TC article is light on details compared to the actual call and 10-K.

Uber was 12% of total rev at the start of 2016, and 17% later on. WhatsApp was the next largest at 9% for the year. Concentration falls off from there, with the 3rd largest customer at 2%.

Twilio's initial (unamended) S-1 filing uses Uber as a customer case study [1]. They called out WhatsApp as a business risk given that they were and are a variable account (15% of their business at the time). Uber was not, potentially because they're a Base Customer Account, but as noted in in the 10-K [2]: "its usage historically has significantly exceeded the minimum revenue commitment in its contract, and it could significantly reduce its usage of our products without notice or penalty."

[1] https://www.sec.gov/Archives/edgar/data/1447669/000104746916...

[2] https://www.sec.gov/Archives/edgar/data/1447669/000104746917...

Kevin Leyton-Brown's research is a good read for SAT if you're interested in the state-of-the-art, and more specifically emperical/meta algorithms: http://www.cs.ubc.ca/~kevinlb/publications.html

I switched from MathJax to a middleman + execjs + KaTeX pipeline for my static sites earlier this year, and I'm very happy with it overall. KaTeX isn't 1-1 with MathJax when it comes to syntax support; I was surprised to see that underset and overset - which are ubiquitous - aren't supported. That said, I was able to work around every issue with alternative syntax. It's awesome that the heavy lifting is no longer client side, and it's a significantly easier build pipeline than MathJax if you're trying to generate a single minimized script or use webpack.

It's a community that knows low level CS/AI well. The chess programming wiki [1] is quite the knowledge hole for everything from bit twiddling hacks to obscure search algorithms.

[1] https://chessprogramming.wikispaces.com

There are very interesting and fairly recent results on causal discovery under additive noise models [1]. Although such models aren't universally applicable the underlying concept is intuitive and a good fit for many problem domains. On the time series front, google open sourced CausalImpact [2] for Bayesian structural time-series modeling a few years ago. Looks like RankScience [3] is putting that research to good use.

I'm surprised that causal discovery doesn't get more play. Aside from the direct applications to scientific research, causality is a strong consistency hint for assessing models/features learned from data.

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

[2] https://opensource.googleblog.com/2014/09/causalimpact-new-o...

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

Peter Muller has the most succinct summary of this that I've seen in his (very worthwhile) opinion piece on proprietary trading [1]:

Sharpe Ratio, Marketing department

≤ 0: Runs the firm

0.25: Very important; involved in all investment decisions; major focus on asset gathering

0.5–1.0: Secondary

1.0–2.0: Almost superfluous

≥ 2.0: What marketing department?

[1] https://faculty.fuqua.duke.edu/~charvey/Teaching/BA453_2004/...

Right, my comment retarding truth tables was only in reference to combinatorial logic. That said, pure circuit models of computations exist, and are interesting from a theoretical standpoint at least. They don't translate to hardware, though. As you noted doing arbitrary computation with (finite) circuits requires some type of feedback/sequential logic.

I'm in the process of writing a tutorial on this/hardware synthesis from first principles, but general purpose computers are way less magical when you think of components such the ALU as a mapping of binary inputs to binary outputs: a truth table. From there you can explicitly enumerate all possible inputs and outputs (for small word sizes at least) and go directly from said truth table to (inefficient) hardware.

Related: mov is Turing-complete [1] and X86 MMU fault handling is Turing-complete [2]

edit: formatting

[1] https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

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

The anonymity requirement is relatively easy to solve for with either blind signatures or a homomorphic voting scheme. The general availability part is trickier since solving for it is akin to solving for the current issues with voter registration and disenfranchisement. India is having decent success rolling out their UIDAI program, so there's hope on that front, but distribution is the part of the stack that math and technology can't solve for directly.

Thankfully "messing" isn't the word I would choose for most market participants but you're describing the algorithmic game theory that goes into designing a good execution algorithm.

For that matter, cuckoo hashing [1] in general is an interesting topic. Take a look at its application to cache oblivious dictionaries [2]. They work quite well in practice, especially for space constrained hash tables (e.g. caches).

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

[2] https://arxiv.org/abs/1107.4378

Comedy gold indeed.

> This is supposed to be impossible because it is incentivize-incompatible

Enter the wonderful world of coco values and side payments in game theory. Incentive compatibility and strategyproofness arguments break down when parties are compensated (implicitly or explicitly) out-of-band. That's not always a bad thing - it can lead to more efficient, utility maximizing equilibria. That said, under the status quo, we're trading one flavor of centralization (monetary policy) for another (core committers and mining pools).

My uncle was a radiation oncologist who worked with machines like this one. As a young child in the early 90s he took me to the hospital where he worked to watch him and their staff physicist calibrate a linear accelerator - an experience I remember vividly. A very long checklist culminated in them irradiating a plate of acrylic, which I got to keep. The plate was about 20cm x 30cm x 4cm and aligned such that the beam would strike the 4cm face and travel down the 20cm side, fanning out in the process. The result looked like a thinner version of this: https://en.wikipedia.org/wiki/Lichtenberg_figure#/media/File...

I asked him how they could possibly use such machines on humans, given what I just watched it do to a 1kg plate of acrylic. He told me that they hit the plate with way more energy than they ever would a human. That prompted my followup question: "uncle, what happens if you accidentally hit the wrong button?" He told me that accidents like that used to happen, but that the machines they used had special computers to keep the patient safe even if he made a mistake. "But uncle, what happens if the computer makes a mistake!?" I had no idea what a bug, or for that matter code was. He didn't have a good answer beyond "the computer can't make mistakes like we do." Having played with computers enough by then to know that his statement wasn't entirely true, I ended that outing wanting to know more. I started obsessing over what would happen to people if computers controlling things like that linear accelerator, or even the elevator in my dad's office building, made a mistake.

Incidentally, my uncle was the one who got me interested in science, and that trip to the hospital got me using computers for something other than games. Fast forward 24 years and...well...part of what I do is work on provably correct systems.

Yup. Incidentally this is exactly the same effect that makes model selection within a portfolio challenging. Two worthwhile reads on that front: the multiple comparison problem [1] and regression towards the mean [2].

Regardless of your objective - hosting a contest like this or allocating to individual institutions and strategies - you'll always face this problem. Good allocation decisions are tactical, taking both the logic of the strategy and the broader portfolio into account. Bad allocation decisions chase returns.

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

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

I mostly agree with this. Treating markets as an exercise purely in data science is a _bad idea_. Risking money without a solid understanding of market mechanics and trading conventions is a recipe for disaster. Taking a Bayesian view won't save you either - this is a land where some new "six sigma" event happens every six months.

That said, the same logic that holds for identifying profitable strategies within an institution holds for individuals: unless you have better gear, don't fish a crowded pond. As an individual, your small size is, in some regards, an advantage. Institutions routinely pass on strategies that don't have capacity (there's not enough liquidity to make the strategy's returns worthwhile relative to their trading level) or strategies that aren't quite up to their standards (but might be up to yours). There's also a huge class of strategies that have somewhat choppy but long run consistent returns. Traders and funds worried about MoM track records won't touch those.

Fees are the biggest barrier to entry. Institutions enjoy substantial discounts and an ability to amortize costs across a much wider base, making the strategy performance hurdle rate proportionally higher for smaller traders.

Yup, as described in TAOCP vol 2 as well.

PAM is great, and it's especially great as a layer of indirection, but I can't agree with your overall point that using PAM = problem solved. To your no harder than LAMP point, most teams can't competently manage a security critical LAMP stack. They're in good company given that big companies/governments get pwned with great regularity. Survival requires defense in depth, and that gets expensive. It's a matter of everything from policy (are there two-man change controls on firewall rules, do separate teams own the route tables and firewall, do separate teams develop/audit/deploy security critical code) to hardware (is private key material stored on an HSM, are sensitive services physically isolated, does entropy come from a hardware RNG). Most small companies aren't thinking about those things.

Also, given that the P is for pluggable, what's the backend? You wouldn't use pam_unix for users outside your org. A DB? Now you're back to square one. LDAP+Kerberos/AD? That beats the DB but it doesn't do anything for your defense in depth requirement.

> Outsourcing them is not the answer

It very much is, if you're outsourcing to someone who can do it with greater competence than the average team can. Keeping current on the crypto, designing with the ability to sunset algorithms in mind, continuous pen testing, investing in physical security/network security/HSMs/you name it definitely isn't cheap or easy. Unless you're in the business of doing _that_ you're almost certainly better off having someone do it for you.

That said, I'm with you on the social logins front. I have/had? hope for OpenID Connect as an alternative so it would be great if someone neutral like Mozilla jumped on the bandwagon.

> all the jobs that involve picking up something and putting it somewhere else

The a well phrased name for the superset containing automated freight and logistics. As discussed in https://news.ycombinator.com/item?id=11568699 trucking alone is 1% of the U.S. workforce, and that's not counting the support industry (gas stations, highway diners, rest stops, motels, etc).

The litany of contradictory or bad information on thorium reactors (and nuclear in general) is astounding. That's probably a function of both how polarizing nuclear energy is as a topic, and how nuanced the science actually is.

First off, note that thorium is not the fissile material - it's the fertile material. Thorium 232 is transmuted into something else like Uranium 233 via a breeder reactor, so saying that these reactors use thorium "instead" of uranium is about like saying your gas powered automobile burns crude oil.

As others have pointed out there's also a ton of bad information in this about fuel cycles and half life being the biggest driver of clean vs dirty nuclear, but lest I perpetuate more bad information...

Here's a detailed look at the science: http://www.world-nuclear.org/information-library/current-and...

Thorium or otherwise, it's tilting that the public perception of nuclear energy is based on dated technology. Almost as tilting as electric cars being marketed as zero emission. We as a society have to figure out better answers to power production. When you sell bad science or buzz words to people who really take them as such without realizing that the power still has to come from somewhere, there's less support for funding the research that gets us end-to-end clean power.

Also, FWIW, the only reference I found to "war time politics" being the main driver was http://discovermagazine.com/2014/june/3-ask-discover. I'm guessing the full history was far more complex and nuanced than that.

Yes that's totally correct but they're factoring the entire reinsurance/reinvestment pipeline into how aggressively they can price the policy in the first place.

Assuming that insurance is correctly priced, buying a policy in any form is negative expected value. The companies that write such policies would slowly bleed dry if that wasn't the case. However, that's irrelevant unless you have the bankroll to withstand tail risk. Given that most people don't, as a society, you pretty much have to make things like auto liability insurance compulsory.

If you're a "good driver," as defined by a lack of tickets and accidents, you get discounts. There's really no way to tell if you're _actually_ a "good driver" because "good driver" is a hidden variable, and the only observables from an insurance standpoint are tickets or accidents. I know horrible drivers who never have accidents and avoid tickets via luck or skill. Conversely, you can be a good driver who's unlucky enough to have multiple accidents in a short period of time. Outcomes = baseline truth + random noise.

Most corporate data grabs bad news, but I'm ok with it when it comes to pricing insurance (outside of health). If I run a business that has rock solid, well enforced policies in place to mitigate risk, I don't want the insurance company's priors over my company's sector driving the premium. I only want to pay for coverage on idiosyncratic risk - the risk that remains after addressing everything that I can. Same goes for driving habits. Things like health are almost entirely idiosyncratic risk (ergo, let's agree that doing this for health is a bad thing), but when that's not the case pricing policies using true states (the baseline) and not observables (baseline + noise) puts you as the policy buyer more in control, not less.

That said, I have major concerns over the implementation. A breach is all but inevitable, so there needs to be a means of updating models online, and rules against data retention. It's also bad news if flawed models or corner cases incorrectly price someone out of a policy and there's no sanity check. Unfortunately, that's not too different from the actuarial status quo.

Obligatory link to the highly approachable and all around amazing http://nand2tetris.org, which will get you to the level of FPGA knowledge necessary to tackle projects like this.

You might be surprised (when talking about the U.S equities exchanges at least): http://anova-tech.com/wp-content/uploads/2014/09/market-data.... The LoS distances in NY are on the order of 5-30mi and the lowest latency links are over microwave and laser.

Previous discussion on HN - not sure why it got killed as a dupe: https://news.ycombinator.com/item?id=11926084

A lot of this is predicated on the practicality of writing contracts in conventional code, so let's talk about the state of writing "bug free systems," and the cost. In some cases, there are options that come pretty close. All have huge trade offs and drawbacks.

Model checkers work. You can, with effort, prove programs correct. This works very well for small programs but grows exponentially more complex in the number of branches and variable constraints. Even if you had the computational power you'll quickly hit an inflection point where you're as likely to have a bug in your proof as you are the underlying code.

Life-critical systems style code review works. NASA is very good at writing bug-free C code via a style guide that subsets the language, static analysis/formal methods, and a review process that makes waterfall look agile.

Voing works. In aerospace, code that's responsible for controlling actuators and surfaces is often implemented in three different ways, driving three different actuators. If one implementation returns a different result, majority wins. Same principle for other applications - the output need not be an actuation.

The biggest problem isn't that bug free system are a pipe dream - it's that making one is very expensive, and the cost grows massively as your tolerance for error decreases. This is a community that wants to drive adoption, and that means competing with the status quo. If one of your selling points is that you're saving the cost and complexity of dispute resolution and human constructs, you've gotta factor in the cost of writing bug free contracts in the first place.

Good lawyers don't write overly complicated contracts, and they don't speak in legalese. The concepts covered within the contract might be complex, but the writing itself is deliberately readable. Complex things are brittle. Clear, well written contracts are more likely to be interpreted correctly by all parties if something unforeseen happens. Contrast this to the alternative - writing a contract by enumerating every possible outcome, hoping that you don't miss one, knowing that if you do, every party will argue for the interpretation that's most favorable to them. The adversarial aspect makes things that much harder.

Contracts in something as flexible as Ethereum strikes me as the ultimate in fragility. There's a great use case for anything that looks like a smallish FSM - formal methods will yield something very usable and provably correct. Being able to do that on a system with a state space the size of Ethereum + The DAO - yea, we're a ways away from that one.

In other compression news, Apple open sourced their implementation of lzfse yesterday: https://github.com/lzfse/lzfse. It's based on a relatively new type of coding - asymmetric numeral systems. Huffman coding is only optimal if you consider one bit as the smallest unit of information. ANS (and more broadly, arithmetic coding) allows for fractional bits and gets closer to the Shannon limit. It's also simpler to implement than (real world) Huffman.

Unfortunately, most open source implementations of ANS are not highly optimized and quite division heavy, so they lag on speed benchmarks. Apple's implementation looks pretty good (they're using it in OS X, err, macOS, and iOS) and there's some promising academic work being done on better implementations (optimizing Huffman for x86, ARM, and FPGA is a pretty well studied problem). The compression story is still being written.

Correction to my post above:

I used the word "parallax" poorly to refer to the offset between the detectors - localization is most definitely not done via parallax. It's arrival time + some signal processing, so with two detectors, resolution is limited.

Additional details and an image depicting the improvements made by adding a third, properly positioned detector are available at: https://www.ligo.caltech.edu/news/ligo20160404