Alternative titles: These are all about equivalent to the risk of one year of smoking. (Continue reading the full article on the web.) … earns you a high-risk pregnancy … earns you an ascent of Matterhorn … earns you 10,000 km on a motorcycle … earns you two BASE jumps … earns you a day on the frontline in Ukraine
I have a copy of SICP, or as it is also known, The Wizard Book . This book is widely praised, but I can’t take the time to work my way through all of it. Instead, I’m going to occasionally jump into the parts of it that look interesting. Last week, we looked at tagged data in Haskell. The authors of SICP weren’t convinced that’s the best approach, so they move on to data-directed programming. We’ll do the same. Complex numbers can be stored in their rectangular form, with a real and an imaginary part. They can also be stored in polar form, where there’s a magnitude and an angle. Whichever way a complex number is stored, we would like to be able to query it for all of these four quantities: (Continue reading the full article on the web.) The real coordinate in the rectangular form of the complex number. The imaginary coordinate in the rectangular form. The magnitude in the polar form. The angle in the polar form.
I have a copy of SICP, or as it is also known, The Wizard Book . This book is widely praised, but I can’t take the time to work my way through all of it. However, sometimes I jump into parts of it that look interesting. Today, we’ll see how to support multiple representations of data through tagging. This article is written in Haskell throughout, but at the start it will look a lot like the Lisp code in SICP. I have intentionally tried to recreate the SICP solution as closely as possible, including dynamic typing and all. See the appendix if you’re curious how it works. Complex numbers can be stored in their rectangular form, where there’s a real and an imaginary part. They can also be stored in polar form, where there’s a magnitude and an angle. The authors ask us to imagine that two people have been working on a library for mathematics, but ended up choosing different ways to store complex numbers. How can they write their code so that they don’t have to agree on one way to store the data? (Continue reading the full article on the web.)
Lucas Costa has written a good article on how to build systems that can handle code-generating robots. Unfortunately, when calling it backpressure , he used the wrong metaphor. Backpressure is about signaling to upstream processes that they are running too fast and need to slow down. The suggestions presented by Costa are mostly about signaling to the upstream process that it needs to do things differently , rather than just slow down. This has more to do with ensuring sufficient quality is sent downstream, rather than quantity . This irked me. As I was reading, I was searching for the right analogy. I kept coming back to lean manufacturing . The more famous half of the lean philosophy is waste reduction. The other half is about managing the unstable input of people. That’s what we’re interested in here. (Continue reading the full article on the web.)
TL;DR: My new prior is that top-of-the-line LLMs working on easy tasks generate code that is maybe 10 % more complicated than necessary. I also think we accept this complexity too easily, because it comes from code that is right here , right now , solving an immediate problem. This may have consequences for maintenance in the long term. The background to this discovery was that I needed to do some CRUD plumbing in a work project. It was a simple change that mostly mirrored existing functionality. This is a perfect fit for LLMs, in my experience, so I used a frontier model to generate the code for it. The change ended up being a total of just over 200 lines, mostly additions. The part of the generated code we’ll talk about is a 24-line function that converts an arbitrary (user-supplied) string to a safe HTTP header value. (Continue reading the full article on the web.)
A Formula One driver triggered my fact-checkitis. They claimed that Winning the Monaco Grand Prix in Monte Carlo is determined nine out of ten times by which position one starts in. That makes intuitive sense, because the Monte Carlo track is a narrow street track with few opportunities for overtakes. But … really? Is that an off-the-cuff remark or an accurate statistical prediction of the race? (Continue reading the full article on the web.)
William Sealy Gosset was great. He improved beer at Guinness by using the statistics that existed at the time. Not happy with that, he invented new statistics to brew even better beer. The things he invented are used all over the place now, but Guinness wanted to keep him a secret weapon, so they made him publish his results under the fake name Student . One thing Gosset realised is that it is wrong to compute 90 % confidence intervals for the mean by taking the standard deviation of the sample, and assume a normal distribution , like-a-so: \[\hat{\mu} \pm 1.645 \hat{\sigma}\] (Continue reading the full article on the web.)
TL;DR: Instead of labouriously computing \(c = \sqrt{a^2 + b^2}\), we can mentally calculate using the alpha-max plus beta-min algorithm, by estimating \[\hat{c} = \mathrm{max}\left(a, 0.9a + 0.5b \right)\] and this will be very close to the actual \(c\). This is useful for adding up sources of variance, or figuring out radiuses, or other such things. (Continue reading the full article on the web.)
In the Henley Royal Regatta two teams at a time propel their boats up a river and compete to be first to go a distance. Teams get assigned to their starting stations – Berkshire or Buckinghamshire – at random. From there, it is a straight shot up the river, with the lane from each starting station being seemingly identical. I didn’t know any of this, but a reader reached out some time ago because they had noticed something odd about this, and they wanted to borrow me as a sounding board. Here’s the odd thing: the team that starts from the Berkshire station has won 53.5 % of the 7555 races in the historic data this reader looked at. This is highly unexpected. If teams are assigned at random, and the starting stations are practically equal, then the starting station of the winning team should be a coin flip. If we flip 7555 coins, we would never have as many as 53.5 % come up heads. (Continue reading the full article on the web.)
Programming
Security
AI
Web
Statistics
Data Analysis
Tutorial
JavaScript
Git
Shell