datastoat

I believe that chain-of-thought reasoning blocks don't really correspond to what humans think of as reasoning. (See section 6.2.2 of the Fable/Mythos system card about "illegible reasoning", and the questions raised by the Apple paper on "The illusion of thinking".) I assumed they obscure the reasoning blocks because if users saw what's going on they'd be alarmed. Just as I'd probably be alarmed if I saw what was really going on in the heads of my colleagues ...

Goodhart's Law of Specification: When a spec reaches a state where it's comprehensive and precise enough to generate code, it has fallen out of alignment with the original intent.

Of course there are some systems where correctness is vital, and for those I'd like a precise spec and proof of correctness. But I think there's a huge bulk of code where formal specification impedes what should be a process of learning and adapting.

Wouldn’t it be handy if the browser could intelligently join this author’s sentences into paragraphs?! (in connection to the thread about Mozilla putting AI in the browser)

Darwin would claim otherwise! Single cells plus random mutation plus selective copying = rocket ships.

> They should also share their prompts

Here's a recent ShowHN post (a map view for OneDrive photos), which documents all the LLM prompting that went into it:

https://news.ycombinator.com/item?id=44584335

Author: "5% chance of shipping something that only looked good by chance". One philosophy of statistics says that the product either is better or isn't better, and that it's meaningless to attach a probability to facts, which the author seems to be doing with the phrase "5% chance of shipping something".

Parent: "5% chance of looking as good as it did, if it were truly no better than the alternative." This accepts the premise that the product quality is a fact, and only uses probability to describe the (noisy / probabilistic) measurements, i.e. "5% chance of looking as good".

Parent is right to pick up on this, if we're talking about a single product (or, in medicine, if we're talking about a single study evaluating a new treatment). But if we're talking about a workflow for evaluating many products, and we're prepared to consider a probability model that says some products are better than the alternative and others aren't, then the author's version is reasonable.

Empirical Bayes is exactly what I was getting at. It's a pragmatic modelling choice, but it loses the theoretical guarantees about uncertainty quantification that pure Bayesianism gives us.

(Though if you have a reference for why empirical Bayes does give theoretical guarantees, I'll be happy to change my mind!)

Non-Bayesian NN training does indeed use regularizers that are chosen subjectively —- but they are then tested in validation, and the best-performing regularizer is chosen. Thus the choice is empirical, not subjective.

A Bayesian could try the same thing: try out several priors, and pick the one that performs best in validation. But if you pick your prior based on the data, then the classic theory about “principled quantification of uncertainty” doesn’t apply any more. So you’re left using a computationally unwieldy procedure that doesn’t offer theoretical guarantees.

I like Bayesian inference for few-parameter models where I have solid grounds for choosing my priors. For neural networks, I like to ask people "what's your prior for ReLU versus LeakyReLU versus sigmoid?" and I've never gotten a convincing answer.

The article explained that there are two roughly equal drivers: (1) Water is a better heat reserve than land, and winds tend to blow eastwards, so Europe gets air warmed by the sea and the US east coat gets colder air that's come from the land. (2) The joint effect of the altitude of the Rockies and the angular rotation of the earth mean that air currents are southeast over the Rockies and then northeast, so arctic air gets pulled down and then pushed back up over the US east coast.

It'd be fun (and a bit scary) to use an LLM as a shell replacement. We'd give it the history of our commands as per the recent post [0], as well as their outputs, and it would turn natural-language commands into proper bash. The xkcd comic [1] would be solved instantly. "Tar these files, please." "Delete all the temporary files but please please please don't delete anything else." I'm sure people have implemented this, but my searching isn't good enough to find it.

[0] https://news.ycombinator.com/item?id=38965003

[1] https://xkcd.com/1168/

According to the Wikipedia page for eszett [0] it evolved from "sz", as the name "eszett" suggests. (I only realized the link with "z" when I saw "tz" ligatures on street signs in Berlin.) Given that its typographic origin is sz, and given that its name literally says sz, I wish the spelling reformists had gone for sz rather than ss!

[0] https://en.wikipedia.org/wiki/%C3%9F

They use Pyodide, a full Python interpreter in WASM: https://pyodide.org/en/stable/console.html

Pyodide includes manyuseful Python libraries including numpy, pandas, and matplotlib.

Windows 8 (Metro) used semantic zoom. It's been a while, but I do remember that one of the apps that used it very nicely was Photos. A search for "windows metro semantic zoom" comes up with lots of articles about semantic-zoom-aware GridView controls etc.

Why isn't it commonplace? I think that touchscreen laptops are still too much a minority, and keyboard + mouse + monitor are too entrenched, for anyone to seriously attempt it again for a while. (A shame -- I'm one of the few who really liked the Windows 8 Metro interface.) I think that phones are too small for it to really work well. I don't know why it's not more popular on tablets.

As an Australian I'm used to hearing "antipodean" and sometimes "antipodes", so "octopodes" sits well!

That xkcd comic highlights the problem with observational (as opposed to controlled) studies. TFA is about A/B testing, i.e. controlled studies. It’s the fact that you (the investigator) is controlling the treatment assignment that allows you to draw causal conclusions. What you happen to believe about the mechanism of action doesn’t matter, at least as far as the outcome of this particular experiment is concerned. Of course, your conjectured mechanism of action is likely to matter for what you decide to investigate next.

Also, frequentism / Bayesianism is orthogonal to causal / correlational interpretations.

I’m curious! Why “Bayesian”?

I tried... I pointed out a problem and asked ChatGPT to fix it, unsuccessfully. I asked it for a proof of correctness, then pointed out a problem in its proof and asked ChatGPT to fix it, again unsuccessfully. (It's all in the notes I linked to.) Perhaps I'm just crummy at prompt engineering; or perhaps this is one of those questions where the only way to engineer a successful prompt is to know the answer yourself beforehand.

You're right, ChatGPT is probabilistic. None of this is graded by the way -- it's all just for fun and bragging rights.

I've asked students to share their full dialog, both prompts and replies, so the whole class gets to see; and I'll invite one or two to talk through their attempts. This is all just a trick to make students engage with "how do you you spot bugs in a proof?", hopefully more than they would from just reading CLRS! Often, students engage well when they're hearing the material from other students.

I'm trying something similar with an introductory Algorithms class.

After we go through Breadth First Search, there's a practical assignment where students are asked to modify the algorithm to return _all_ shortest paths. Then I ask ChatGPT for its solution, and students try to spot its mistakes.

Later, after going through the proof of correctness of Dijkstra's algorithm, I ask ChatGPT for a proof of correctness of its all-shortest-paths algorithm, and again students try to spot what's wrong in the proof. I want students to learn to tell the difference between a bullshit proof and a real proof; in the past I've given them bullshit proofs from real students in exams, but ChatGPT makes the point more nicely.

Finally, students are asked to figure out prompts that will make ChatGPT give a correct algorithm and proof. I haven't managed this myself! I'm looking forwards to seeing what students manage.

Here's a link to lecture notes, including the ChatGPT dialog: https://www.cl.cam.ac.uk/teaching/2223/Algorithm2/alg2-full....

I’m in the same boat as you — sensitive teeth, but can’t not rinse. What works for me is to treat the toothpaste as a “post-rinse medicated rub”: squeeze out a bit more, and rub it over the most sensitive teeth.

> Please, please: learn some probability via measure theory. You’ll start reading machine learning papers wondering how people ever express themselves precisely without it. The entire field seems to be predicated around writing things like x ~ p_\theta(x|z=q_\phi(x)) as if that’s somehow meaningful notation.

Hear hear! How did ML get saddled with such awful notation?

Indeed, there are Bayesian neural networks and there are non-Bayesian neural networks, and I shouldn't have implied that all neural networks are non-Bayesian.

I'm just trying to point out that there is a dichotomy between the Bayesian and the non-Bayesian, and that the standard neural network models are non-Bayesian, and that we need Bayesianism (or something like it) to talk about (epistemic) uncertainty.

Standard neural networks are non-Bayesian, because they do not treat the neural network parameters as random variables. This includes most of the examples that have been mentioned in this thread: classifiers (which output a probability distribution over labels), networks that estimate mean and variance, and VAEs (which use Bayes's rule for the latent variable but not for the model parameters). These networks all deal with probability distributions, but that's not enough for us to call them Bayesian.

Bayesian neural networks are easy, in principle -- if we treat the edge weights of a neural network as having a distribution, then the entire neural network is Bayesian. And as you say these can be approximated, e.g. by using dropout at inference time [0], or by careful use of ensemble methods [1].

[0] https://arxiv.org/abs/1506.02142

Quote: "Deep learning tools have gained tremendous attention in applied machine learning. However such tools for regression and classification do not capture model uncertainty."

[1] https://arxiv.org/abs/1810.05546

Quote: "Ensembling NNs provides an easily implementable, scalable method for uncertainty quantification, however, it has been criticised for not being Bayesian."

In my example, of predicting a coin toss, the naive output is a probability distribution: it's "Prob(heads)=0.5, Prob(tails)=0.5". This is the distribution that will be produced both by the person who sees 2 heads and 2 tails, and by the person who sees 2000 heads and 2000 tails.

Bayesians use the terms 'aleatoric' and 'epistemic' uncertainty. Aleatoric uncertainty is the part of uncertainty that says "I don't know the outcome, and I wouldn't know it even if I knew the exact model parameters", and epistemic uncertainty says "I don't even know the model".

Your example (outputting a mean and variance) is reporting a probability distribution, and it captures aleatoric uncertainty. When Bayesians talk about uncertainty or confidence, they're referring to model uncertainty -- how confident are you about the mean and the variance that you're reporting?

Probability estimates are not the same thing as uncertainty.

Consider tossing a coin. If I see 2 heads and 2 tails, I might report "the probability of heads is 50%". If you see 2000 heads and 2000 tails you'd also report the SAME probability estimate -- but you'd be more certain than me.

Neural networks give probability estimates. Bayesian methods (and also frequentist methods) give us probability estimates AND uncertainty.

The literature on neural network calibration seems to me to have missed this distinction.

One other point to make about MPTCP: it has a congestion controller that takes pains to be fair with respect to regular TCP. It's a subtle problem...

MPTCP sender -> [link1 | link2] -> shared link -> MPTCP receiver

There might be a TCP flow using the shared link, in which case fairness means that the MPTCP sender should only send the same total traffic as would a single TCP flow. Or there might be a TCP flow using link1, and a second TCP flow using link2, and the shared link might be uncongested, in which case MPTCP could reasonably behave like two TCP flows. Or maybe there's a single path TCP flow using (link1 -> shared), or one using (link1 -> link2), or ...

The MPTCP congestion controller was designed so that in all of these cases it's no greedier than if it were a single TCP flow. And it has to do this without knowing the network topology, nor what other flows are using the network.

Reference: 2011 paper, https://www.usenix.org/conference/nsdi11/design-implementati...

Suppose the sender has a single interface, and it's the receiver that has multiple interfaces. With MPTCP, the sender will learn that there are multiple paths available, and it'll balance its load adaptively over those paths.

I don't know enough about bonded interfaces, but I don't see how they'd help in this scenario. This scenario is natural with mobile devices, which is probably why Apple uses MPTCP.

MPTCP is a drop-in replacement -- but its original designers were paranoid about e.g. packet-sniffing middleboxes, so they made it opt-in.

Suppose for example there's a packet-sniffing security appliance along the path, and it only sees packets on one path of the MPTCP flow, and it says "This stream of packets doesn't look like a legitimate TCP flow, so it's probably an attack, so I'll block it."

> This seems very much like an outsider's critique

Spot on! This same sentiment was expressed very well in a paper evaluating the R language [1]:

"This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular."

It would be nice to see a post about R that analyses _why_ it's so hugely popular with data scientists. It's easy to write "R doesn't do what we computer scientists think languages should do, so it's no good". It's harder to analyse what R gets right (for its domain) that other languages get wrong. Personally, I think it's not just that R has the best data-handling libraries (ggplot2, plyr, data.table), it's its "unlikely linguistic cocktail" that is perfectly suited for data exploration.

I think that maybe we hear the views of software engineers who get handed a messy R script and are asked to make it run in production, or make it run on big datasets, and so they only ever see the downsides of R. R wasn't designed to make life easy for production! It's designed to make it easy to explore datasets, which often means one-off code, 99% of which you run and then delete because your hypothesis about the data was wrong.

[1] https://www.researchgate.net/publication/240040602_Evaluatin...

What you provided isn't (just) maths, it's a modelling assertion: that failures are independent from part to part, and independent from day to day.

I'm skeptical about your first assertion -- think of the effect of a power surge. I don't agree with your second assertion at all, from my experience of cheap devices that fail not long after their warranty expires.