bnjmn

"Context and intent cannot be known" seems like a bit of an overstatement? A qualifying clause like "in all cases, with complete confidence" would allow for the possibility of alignment in some cases (yay), but not always, and of course it's that "not always" that's problematic when you're trying to make blanket safety guarantees.

Here's a version I imagine both the author and I can nod along with: "Context and intent cannot be known at model training time, so most attempts to enforce safety or ethics guardrails purely through the weights of the model, fine-tuning, or other training-time interventions are doomed to guarantee very little at inference time."

This game was the first software I ever modified! I added an easter egg where if you spent all your money immediately on cocaine, its price would reliably skyrocket, so you could go ahead and pay back the loan sharks, or buy lots more drugs.

Humanoid robots are handicapped by their similarity to humans which is really an artificial constraint.

YES, and I wish people would stop pretending we've unlocked some new generality by promoting generic humanoid robots over task-specific ones.

You can probably Rube-Goldberg your way to a diaper-changing robotic enclosure with a 3D baby bidet that uses many low-force robot arms to subdue (most) babies, but a humanoid robot is a very a poor substitute for a human here.

Plus, a human can take personal responsibility for the baby's safety, which is not something a robot can ever do, unless we somehow make the robot fear for its life/freedom/employment the same way the overarching social/legal system does for humans who sign contracts or accept highly accountable roles.

Here's a use case that seems more science fictional to me (as the parent of a 2yo) than warp drive: a robot that can gently restrain an uncooperative human baby while changing its diaper, with everything that entails: identifying and eliminating all traces of waste from all crevices, applying diaper cream as necessary, unfolding and positioning the new diaper correctly and quickly, always using enough but never too much force... not to mention the nightmare of providing any guarantees about safety at mass-market scale. Even one maimed baby, or even just a baby some robot neglects to prevent from falling off the changing table, is game over for that line of robots.

Is there any research program that could claim to tackle this? It's so far beyond folding laundry and doing dishes, which are already quite difficult.

I wouldn't bet my life on this tech _never_ materializing, but I would mistrust anyone who claimed it was feasible with today's tech. It calls for an entirely different kind of robotic perception, feedback, and control.

Among other general advice, my CLAUDE.md insists Claude prove to me each unit of change works as expected, and I'm usually just hoping for it to write tests and convince me they're actually running and passing. A proof assistant seems overkill here, and yet Claude often struggles to assemble these informal proofs. I can see the benefit of a more formal proof language, along with adding a source of programmatic feedback, compared to open-ended verbal proof.

"Overkill" of course is an editorial word, and if you know about https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspon... then you know many statically typed programming languages are essentially proof assistants, where the proof goal is producing well-typed programs. LLMs are already quite good at interacting with these programming language proof assistants, as you can see any time a competent LLM interacts with the Rust borrow checker, for example.

They say the e-ink display has "Unmatched Speed, Never Seen on ePaper" so it would nice to know the actual refresh rate.

This is not an endorsement, but https://daylightcomputer.com/ claims 60fps, so that's the bar to meet in my opinion. Caveat: the daylight display is not true e-ink, but an e-ink-like LCD, IIUC.

Thanks for these detailed replies! Now I really want to read your paper.

I fully agree with your final statement, but needing to constrain the problem in an artificial way to prove it's NP-complete doesn't mean the constraint was justified or realistic, because then you've only proved the constrained version of the decision problem is NP-hard.

There might be plenty of perfectly "good" tokenizers (whatever that ends up meaning) that can be found or generated without formulating their design as an NP-complete decision problem. Claiming "tokenization is NP-complete" (paper title) in general seems like an overstatement.

We still do not know, for instance, what makes a good tokeniser (Gowda and May, 2020; Cognetta et al., 2024): which characteristics should its produced subwords `s` have to be a good starting point for language modelling? If we knew this, then we could define an objective function which we could evaluate tokenisers with.

I don't see how the authors get past this true general statement from the first paragraph of the introduction. Finding a good tokenizer is not just NP-hard; we have no idea how hard it might be because we don't have theoretical agreement on what "good" means.

In order to have something to prove, the authors decide (somewhat arbitrarily):

Specifically, we focus on finding tokenisers that maximise the compression of a text. Given this objective, we then define the tokenisation problem as the task of finding a tokeniser which compresses a dataset to at most δ symbols.

Is a tokenizer that maximizes the compression of text (e.g. by identifying longer tokens that tend to be used whole) necessarily a better tokenizer, in terms of overall model performance? Compression might be a useful property for an objective function to consider... but then again maybe not, if it makes the problem NP-hard.

I'm also not sure how realistic the limitation to "at most δ symbols" is. I mean, that limit is undeniably useful to make the proof of NP-completeness go through, because it's a similar mechanism to the minimum number of satisfied clauses in the MAX-2-SAT definition. But why not just keep adding tokens as needed, rather than imposing any preordained limit? IIRC OpenAI's tokenizer has a vocabulary of around 52k subword strings. When that tokenizer was being designed, I don't imagine they worried much if the final number had been 60k or even 100k. How could you possibly choose a meaningful δ from first principles?

To put that point a different way, imagine the authors had proven NP-completeness by reduction from the Knapsack Problem, where the knapsack you're packing has some maximum capacity. If you can easily swap your knapsack out for a larger knapsack whenever it gets (close to) full, then the problem becomes trivial.

If the authors managed to prove that any arbitrary objective function would lead to NP-hard tokenizer optimization problem, then their result would be more general. If the paper proves that somehow, I missed it.

I suppose this paper suggests "here be dragons" in an interesting if incomplete way, but I would also say there's no need to hurt yourself with an expensive optimization problem when you're not even sure it delivers the results you want.

On any macOS computer (or replace /usr/share/dict/words with your own word list):

  grep '^[qwertyuiop]*$' /usr/share/dict/words | \
  awk '{ print length(), $0 }' | \
  sort -n

Are there any new cars / car brands that credibly promise not to track their drivers?

Any car with a network connection for software updates seems likely to be harvesting driver data, or is at least capable of doing so.

Mostly because they admit those results are not statistically significant (for example, at the bottom of the summary diagram). That said, I admire their honesty, and I hope these results suggest other kinds of experiments to other researchers. Maybe the study just needs to be larger, or longer.

Focusing on specific kinds of mortality might also give stronger results than measuring "all cause" mortality. I say that because it seems like cancer was the biggest killer in these groups. I am not a doctor, but I wouldn't have thought cancer was causally related to (lack of) exercise, the way cardiovascular diseases are believed to be. I'd be interested to see larger studies with enough non-cancer deaths to say something statistically significant about the effect of exercise on those outcomes.

Although these results are not exactly impressive or compelling (they don't make me want to change my exercise habits), it's reassuring to see researchers go through with publishing underwhelming results, rather than cherry-picking only the interesting results and sitting on the rest, which is a major contributing factor to the crisis of confidence/replication in the social sciences.

- https://en.wikipedia.org/wiki/Cherry_picking

- https://www.nature.com/news/scientific-method-statistical-er...

- https://fivethirtyeight.com/features/science-isnt-broken/

- etc...

"Potentially" is an understatement! A much better take, IMO.

This isn't exactly what you asked for, but it seems pretty relevant to your stated interests: https://www.jasondavies.com/maps/voronoi/capitals/

I don't think you can have a proper Merkle tree if cycles are possible, and cycles definitely are possible in this AST representation: https://www.unisonweb.org/docs/faq#how-does-hashing-work-for...

My thoughts as well!

you're right, I should have replaced "intuitions" with "observations" instead of waffling

Scientific understanding (defined by the ability to make accurate predictions) can be (must be?) anchored in both the math and physical intuitions/observations, and it's very difficult to bridge the two without resorting to natural language (even if it's just you talking to yourself in your head while you look at the equations).

The whole problem with the Navier-Stokes equations is that the math seems to work extremely well, but we have no way to be sure it actually captures every aspect of reality (given suitably accurate initial inputs). You can use the equations to generate pretty convincing simulations, but they certainly do not always predict the fine-grained behavior of real-world turbulent systems.

Feynman's lectures repeatedly stress that physical laws (and the math that formalizes them) are, at best, idealized approximations of reality. Here's one, but you can google "feynman approximation laws" for more: https://www.feynmanlectures.caltech.edu/I_01.html

One of my favorite takes on this topic:

"From... elementary theories we build up descriptions of more and more complex systems. But in all these efforts we take for granted that we may use any language we wish and as many [languages] as necessary. That is, we choose whatever mathematical formalism is most useful and then interpret the symbols and measurement operations in very highly developed natural language. To a large degree, the simplicity of natural laws arises through the complexities of the languages we use for their expression."

– H. H. Pattee

Thanks!

Speaking as a maintainer of large open-source projects, I know what it's like to get stuck working on a release branch (which is sometimes just the `master` branch) that takes forever to become an official release. I'm not sure if that's the story here, but there have been a lot of commits since the last release, so maybe?

In any case, I strongly recommend publishing alpha/beta releases along the way, without the ceremony of an official release, so that folks can give feedback during the long months that fly by when you don't have nearly enough time to spend on the project.

Respect the needs of your conservative users by not publishing official releases until they're really ready, but trust your more engaged users to use whatever you have right now, and let you know what's working/broken, without judgment.

Here's a comment from Sebastian M (React core team member) about why they chose not to use generator functions: https://github.com/facebook/react/issues/7942#issuecomment-2...

Yes! I was also curious about this, because I'm sure you could make generators/yield work for asynchronous interruptible rendering, but here's what the React team has to say: https://github.com/facebook/react/issues/7942#issuecomment-2...

Here's their official position on generators: https://github.com/facebook/react/issues/7942#issuecomment-2...

Does anyone know why they chose Node.js 12.8.1 instead of 12.13.0, the first LTS release on the 12.x line?

A potentially less labor-intensive way to estimate animal population is to capture a sample, tag them, release them back into the wild, and then later take a second sample and see how many of those animals are tagged: https://en.wikipedia.org/wiki/Mark_and_recapture

I was hoping this article would say something about improving the margin of error for this kind of statistical estimate, or at least provide a critique of mark-and-recapture statistics for counting squirrels (maybe they are just too... squirrely), but alas it sounds like they threw a bunch of volunteers at the problem:

The trick is to divide and conquer. They drew a grid of 350 hectares—plots of land measuring 10,000 square meters—over Central Park. Think of them as something like Census tracts. Volunteers then fanned out and conducted two counts, one in the morning and another at night. The Squirrel Sighters, as they were called, spent 20 minutes per count searching for furry subjects, looking up in the trees and down in the bushes, and listening to the clawing and clucking sounds they make. Allen likens it to an Easter egg hunt; some volunteers found many squirrels, others saw none.

Thanks, this is a good take.

I would add: now it's everyone else's job to make those smaller, more focused libraries work together. The time wasted is unfathomable, but the blame for misconfiguration now falls on individual developers, rather than monolithic frameworks. Progress?

Does this mean Meteor is dead?

Absolutely not! We depend on it internally (engine.apollographql.com is a Meteor app), and Galaxy hosting revenue is THE reason we didn't have to raise money until we felt like it, which is why we got to pick our investors in this round.

Behind the scenes, as the lead developer for both Apollo Client and Meteor, I am constantly borrowing technologies from one to benefit the other. Meteor may move more slowly these days, but that's because it's relatively mature. Apollo has to move more quickly because we're still making (and remaking) fundamental decisions.

Even as community enthusiasm for Meteor has slowed, Galaxy revenue has not, and it's honestly not the worst thing for an open-source project if people who came for the hype either (a) find real reasons to stay, or (b) take their hype-thirst elsewhere.

I have some ideas for increasing Meteor contributor engagement that I'll be giving a talk about at the next Meteor Night (tentatively July 9th in SF).

Looking through the supported APIs (https://docs.aws.amazon.com/documentdb/latest/developerguide...), it appears DocumentDB has no support for Mongo's oplog (https://docs.mongodb.com/manual/core/replica-set-oplog/), or change streams (https://docs.mongodb.com/manual/changeStreams), which I guess is no surprise because change streams were introduced in Mongo 4, whereas DocumentDB copied the 3.6 API. So DocumentDB seems much less useful as a reactive data store than MongoDB.

In other words, DocumentDB is only a drop-in replacement for MongoDB if you weren't using any of the features Amazon decided not to support.

Happy to be corrected if I'm misreading the documentation!