The idea of a C-set was introduced in an earlier post. In this post, we explain how C-sets are implemented as a data structure in the Julia programming language.

see: https://blog.algebraicjulia.org/post/2020/09/cset-graphs-1/

We hypothesized that if the threshold were raised, e.g. to 0.7 or 0.8, the model would reduce false positives by only returning articles it was very confident about. Our experiments confirmed this, but also showed a tradeoff: a stricter threshold means missing some truly relevant articles.

When we presented this tradeoff to the Pregnancy Justice team, they offered a surprising insight: they wanted the false positives. They explained that reviewing even the false positive articles, those not directly about pregnancy criminalization, was actually valuable. These articles helped them understand the broader landscape: adjacent policy discussions, related criminal justice issues, and the wider context in which pregnancy criminalization occurs. What we labeled as irrelevant from a technical standpoint was often relevant from a strategic advocacy standpoint.

Filtering is hard!

And how to build things the right way.

In his first week at SingleTrac, a video game company that made cult classics like Twisted Metal, Jay Barnson discovered the “black triangle” – a way of describing problems that are giant in engineering scope but don’t tend to be all that impressive to anyone else.

via: https://github.com/coln-project/Coln

Avid programmer that loves to push the limits of JavaScript

Dead blog of a good colleague.

I would have kept my identity separate from my projects. Requests is a library. I am a person. The conflation of the two was the root cause of most of the damage. When the project is you, every issue is personal, every critique is existential, and every success is addictive in exactly the wrong way. I’d build the thing, release the thing, and then go home and be a person who also built a thing. Not a person who IS the thing.

As an avid user of Requests for over six years, I had no idea that the author was basically running on empty for a decade due to bipolar disorder. I wish the system—both open source and education—hadn’t chewed him up and spar him out like it did. Watch yourself.

Low-background steel, also known as pre-war steel, pre-atomic steel, or pre-nuclear steel, is any steel produced prior to the detonation of the first nuclear bombs in the 1940s and 1950s. Typically obtained from scrapped ships, salvaged shipwrecks, and other steel artifacts of this era, it is often used as a shielding material for particle detectors and whole-body counting equipment because more modern steel is contaminated with traces of nuclear fallout. Other low-background materials, such as ancient lead, are sometimes used for especially sensitive equipment.

You probably know one hundred people. Picture two of them staring at a broken screen. The 98% statistic is a lazy shortcut. Truly robust engineering isn’t about what works for most; it’s about gracefully handling the edge cases. If a fancy new feature can’t degrade gracefully, then 98% isn’t “widely supported”. It failed to meet the basic minimum for 2% of the people out there.

via: https://news.ycombinator.com/item?id=48816959

Gigantic archive about physical properties of many materials.

LLMs don’t code well in actually challenging coding projects and lack agency. Tools are unproductive.

How Rust prevents data races, and how languages like it could influence future code generation.

As the title says, and a good reference for those new to the industry.

The choice of an efficient document preparation system is an important decision for any academic researcher. To assist the research community, we report a software usability study in which 40 researchers across different disciplines prepared scholarly texts with either Microsoft Word or LaTeX. The probe texts included simple continuous text, text with tables and subheadings, and complex text with several mathematical equations. We show that LaTeX users were slower than Word users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert LaTeX users performed even worse than novice Word users. LaTeX users, however, more often report enjoying using their respective software. We conclude that even experienced LaTeX users may suffer a loss in productivity when LaTeX is used, relative to other document preparation systems.

The choice of an efficient document preparation system is an important decision for any academic researcher. To assist the research community, we report a software usability study in which 40 researchers across different disciplines prepared scholarly texts with either Microsoft Word or LaTeX. The probe texts included simple continuous text, text with tables and subheadings, and complex text with several mathematical equations. We show that LaTeX users were slower than Word users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert LaTeX users performed even worse than novice Word users. LaTeX users, however, more often report enjoying using their respective software. We conclude that even experienced LaTeX users may suffer a loss in productivity when LaTeX is used, relative to other document preparation systems.

My latest open source project, though a bit different this time

Very cool!

What lets the same algorithm work across all three domains is that they share two key properties:

1. Closure under negation and intersection — so the difference between two candidates is itself expressible.
2. Sampling from that difference — so the system can show the user concrete cases where the candidates disagree.

How do we navigate the world of LLMs, and how they understand (or rather, don’t) the concept of truth? How can we use them for what they’re good for, rather than throwing them at every problem? Let’s discuss ways of constraining them, and ways to improve how they’re used.

via: https://www.aeracode.org/2026/06/01/constraining-llms/

It seems a bit counterintuitive that test case reduction would lead to the discovery of new bugs since we might expect that the space of inputs to a well-tested software system is mostly non-bug-triggering with a few isolated pockets of bug-triggering inputs scattered here and there. I am afraid that that view might not be realistic. Rather, all of the inputs we usually see occupy a tiny portion of the space of inputs, and it is surrounded by huge overlapping clouds of bug-triggering inputs. Fuzzers can push the boundaries of the space of inputs that we can test, but not by as much as people generally think. Proofs remain the only way to actually show that a piece of software does the right thing any significant chunk of its input space. But I digress. The important fact is that reducers are decently effective mutation-based fuzzers.

via: https://tratt.net/laurie/blog/2026/test_case_reducers_are_underappreciated_debugging_tools.html

my reducer has no understanding of my interestingness test or, by extension, the underlying program the interestingness test is running. In other words, test-case reduction has done something useful despite having almost no understanding of why what it’s doing is useful. This lack of understanding is the key to the success of test-case reducers. I can run my test-case reducer on any text file, and it will work.

Make it breezy.