> Every Mathematician Has Only a Few Tricks
>
> A long time ago an older and well-known number theorist made some disparaging remarks about Paul Erdös’s work.
> You admire Erdös’s contributions to mathematics as much as I do,
> and I felt annoyed when the older mathematician flatly and definitively stated
> that all of Erdös’s work could be “reduced” to a few tricks which Erdös repeatedly relied on in his proofs.
> What the number theorist did not realize is that other mathematicians, even the very best,
> also rely on a few tricks which they use over and over.
> Take Hilbert. The second volume of Hilbert’s collected papers contains Hilbert’s papers in invariant theory.
> I have made a point of reading some of these papers with care.
> It is sad to note that some of Hilbert’s beautiful results have been completely forgotten.
> But on reading the proofs of Hilbert’s striking and deep theorems in invariant theory,
> it was surprising to verify that Hilbert’s proofs relied on the same few tricks.
> Even Hilbert had only a few tricks!
>
> - Gian-Carlo Rota - "Ten Lessons I Wish I Had Been Taught"
Bevy is a great engine for LLM-based games because it's 100% code. I'm toying with a few things in it, one of them is an entire-planet economic simulation, and it scales well up to a million dead tiles and 10k-50k live tiles on Apple Silicon, pretty impressive.
Oregon's kicker law is a textbook example of bad economic policy, sadly. It essentially means that in boom years the state can't accumulate any general funds for recessions, which is half of the point of a state-level political entity in the first place. Balanced budgets and pay as you go are fabulous over the medium term, but over the short term of a year or two during a disaster or recession, governmental spending is critical as a counterbalance to reduced investment and general employment income.
California is also required to refund taxpayers if it accumulates too much revenue. The state's spending is capped at some limit set in 1979 with adjustments for inflation and population.
Well maybe they should "project" a certain amount of revenue that goes to savings every year automatically, instead of waiting for a boom year windfall.
> in boom years the state can't accumulate any general funds for recessions
Genuine question: have states had the discipline not to raid these coffers in the boom years?
The alternative is borrowing in downturns. That works because during recessions interest rates are low. The opposite problem then manifests, however, which is the state continuing to borrow through the recovery.
Maybe instead of citing shortfalls and surpluses, such laws should cite unemployment and income growth.
> have states had the discipline not to raid these coffers in the boom years?
"Let's give the money back to voters because they will like that and we'll figure out something else in tough years" is, like, the quintessential example of "raiding these coffers."
It's basically like big tech companies turning profit into stock dividends because investors love it and the CEO will be handsomely rewarded, and who cares about long-term R&D. When big companies do that we blame MBAs and capitalism.
Oregon has a biennial budget, so some Oregon employee predicts how much money Oregon will earn over the next 2 to 3 years (which is basically impossible to do), and then Oregon leaders have to come up with a spending plan equal to or less than that revenue estimate.
However, Oregon's costs have no relation to the revenue that the state predicted it would get, so it is constrains the solution space when unforeseen costs or cost trends happen. For example, Oregon predicts a certain amount of revenue, but gets 3% more than the predicted revenue, but that is because prices for everything went up 3% more than expected, now Oregon has less money than it needs to pay its expenses (since it has to return any revenue which was 2% over the estimate).
Oregon is the only jurisdiction I have ever heard of with this kind of strict refund law, and its rigidity seems to be the main issue, along with the 2 year forecast requirement (since forecasting even 1 year is hard enough).
I appreciate you adding your experience here – I'm curious, just with the amount of knowledge you have of Oregon's fiscal oddities (e.g. biennial budgeting): are you an Oregonian yourself?
I feel that I'm part of a sector of Oregonians that, because of our mini-recession and constant cuts, is suddenly having to learn about a lot of fiscal oddities that are finally catuching up with us. (e.g. how centralized education funding is, for example.)
Ha! At this point it's timely. What are your thoughts on the income tax? (I'm on the boarder of Washington, so I'm amused ot observe the arbitrage between Oregon's sales taxes, and Washington's income taxes.)
I find that the core issues really revolve around the audience - getting it good enough that I can use it for my own purposes, where I know the bugs and issues and understand how to use it, on the specific hardware, is fabulous. Getting it from there to "anyone with relatively low technical knowledge beyond the ability to set up home assistant", and "compatible with all the various RPi/smallboard computers" is a pretty enormous amount of work. So I suspect we'll see a lot of "homemade" software that is definitely not salable, but is definitely valuable and useful for the individual.
I hope, over the long to medium term, that these sorts of things will converge in an "rising tide lifts all boats" way so that the ecosystem is healthier and more vibrant, but I worry that what we may see is a resurgence of shovelware.
Do not argue with the LLM, for it is subtle and quick to anger, and finds you crunchy with ketchup.
These are, broadly, all context management issues - when you see it start to go off track, it's because it has too much, too little, or the wrong context, and you have to fix that, usually by resetting it and priming it correctly the next time. This is why it's advantageous not to "chat" with the robots - treat them as an english-to-code compiler, not a coworker.
Chat to produce a spec, save the spec, clear the context, feed only the spec in as context, if there are issues, adjust the spec, rinse and repeat. Steering the process mid-flight is a) not repeatable and b) exacerbates the issue with lots of back and forth and "you're absolutely correct" that dilutes the instructions you wanted to give.
Even 911 will reasonably accommodate a test call as long as it's not high usage period or whatever, call the non emergency line to coordinate if you're concerned, just say "I wanted to test e911 from my cell phone" or equivalent. Remember, systems need to be tested and testable in real life, not just software engineering! When you set up a PBX or voip phone system, you'd better make sure 911 works through it or someone might have a really bad day.
For extraction, you'd want to use different solvents that have different dissolving properties - usually something like water, ethanol, DCM, acetone, MEK, methanol, toluene or whatever.
For strontium, it looks like it's relatively soluble in short chain alcohols (methanol/ethanol) compared to the other two, so you'd crash out the potassium perchlorate by dissolving the mixture in water, then reducing the temperature to cause perchlorate to drop out of solution, then mix in a moderate amount of methanol to crash the potassium nitrate out, being left with a reasonably pure strontium nitrate, that you could then hot filter and recrystallize in anhydrous methanol if you wanted >90% purity. One or two rounds of recrystallization will leave you in the high nineties, probably above 97%.
This is a classic chemistry workup kind of problem and there are interesting engineering challenges embedded in it.
Of course... practical people just buy technical grade strontium nitrate and make fireworks out of it directly, as the article says.
reply