shoo
yeah, provided:
1. test cases are being designed to cover functionality
2. test cases are implemented correctly - i.e. they actually fail if the implementation is defective
3. the tests aren't all commented out
4. the test suite fails if a test fails
5. CI actually detects test suite failure
6. failing tests block changes from being merged (apart from initial triage to stabilise the suite)
Five years ago, outsourcing your software development (including QA) to the lowest bidder might have gotten you results like this -- if you didn't explicitly require automated tests as a deliverable, you wouldn't get any, or if you got some they'd be vacuous and not test anything.
I can see it happening if they genuinely had no idea of how defective / non-existent their internal QA & testing processes were.
A modest download tax of USD $2.07 per GB suffices.
Estimate:
- 134 million households
- approx 80% of households subscribe to home broadband
- approx 750 GB download per month per household
- $2 trillion annual deficit
- assumes no change in household behaviour in response to the new taxSee the earlier discussion about DeepSeek's revenue: https://news.ycombinator.com/item?id=50163494
then 2^(n^(1-epsilon)) belongs to 2^o(n)
Suppose p(n) is some polyonomial in n, our polynomial reduction. Let's make it a monomial for simplicity, p(n) = n^a
Does 2^(p(n)^(1-epsilon)) necessary belong to 2^o(n)?
No, that only holds if (n^a)^(1-epsilon) = n^(a (1-epsilon) ) < n^1 . So, it fails for p(n) = n^a for any a such that a >= 1/(1-epsilon)
Even if something is a reasonable infrastructure project with a sound long term business plan, investors can still lose money if they pay too much for it. For the Telco bubble & crash, there were a few of these Telco companies engaging in financial shenanigans / securities fraud to juice their quarterly financials by leasing capacity to artificially inflate their operating revenue etc. E.g. we booked $100m of revenue by leasing X units of our capacity to $competitor! Sure, we're still extremely cashflow negative, but look at our operating revenue grow! Fine print: we also incurred a symmetric $100m expense to lease X units of capacity back from the same $competitor, but for some reason we didn't classify that as an operating expense, we've thrown it into a different accounting bucket.
That said, overbuilding fiber optic capacity by laying undersea cables is likely different to overbuilding GPU datacenter capacity in that most of the cost of laying a cable is the physical cost to lay the cable -- given you're already laying an undersea cable, the incremental cost to add a bit more capacity to it (more optical fibers) is negligible -- at least before you've sunk the cable! Whereas for a data center full of GPUs, maybe 50%-60% of the total cost is the GPUs, so it isn't cheap to massively overbuild capacity.
Maybe a similar-ish idea could be done in a continuous 2d space, without a grid, using 2D computational geometry operations (e.g. GEOS's [1] buffer operation to grow shapes by a given radius & so on).
Each component is a point-set -- a subset of points in the 2d space we're working in.
1. sample a bunch of seed points from some distribution. these define initial connected components
2a. grow each component by radius r. union any components that touch.
2b. shrink each component by radius r + delta. delete components that contain no points
3. delete any components that are 'too small': shrink each component by r_min, delete any components that now contain no points, then grow each surviving component by r_min again
4. link the surviving connected components somehow:
4a. identify pairs of components that are adjacent (e.g. compute voronoi 'triangulation' using components as seeds instead of points, if two resulting triangles border then their components are neighbours)
4b. propose candidate corridors linking the nearest points between each pair of adjacent components
4c. find a minimal/interesting spanning tree on component-corridoor graph using corridor lengths as edge weights
4d. carve selected corridors by growing each coridoor line by some radius
4e. everything should be some big connected component
5. sanity check that we got something playable (maybe based on area). if it's too small/uninteresting, reject & try again from step 1
Nethack's cellular automata gnomish mine algorithm on a small grid is of course going to be massively faster than stuffing about with masses of GEOS Buffer & Union calls, but it's fun to think through how much of this extends.
It looks like pytorch's various knapsack implementations (including the one contributed by the author) are here:
https://github.com/pytorch/pytorch/blob/31ba9a56657bc887c957...
appears to be used e.g. here
https://github.com/pytorch/pytorch/blob/31ba9a56657bc887c957...
One thing that jumps out at me while staring at the baseline dp_knapsack code is that it isn't very clear what the units used to measure memory are meant to be. The dp_knapsack code assumes that memory & max_memory (aka the memory budget) are floats. dp_knapsack internally multiplies these floating-point memory values by 10,000 & then rounds them to integers to quantise the memory values -- the quantised max_memory value defines the size of one dimension of the dynamic programming table. the other dimension is sized by the item count.
From reading patches of partitioners.py, it seems like the memory budget is meant to be a floating point number between 0.0 & 1.0, and presumably the memory of each item is normalised relative to that memory budget?
If so, & dp_knapsack is called with a max_memory of 1.0, then the a 2d array for n items is allocated and m=10,000 quantised memory values is allocated as shape (n+1, m+1). So for 100 items that'd be an array of shape (101, 10001) - it's filled with float32s, so 4 bytes per element, so the size required for the table would be ... about 4MB.
So it's not obvious why that would be running out of memory.
Another possible explanation of why the baseline dp knapsack could be using a bunch of memory -- speculation -- is that some code could be calling dp_knapsack with a different unit convention than what dp_knapsack expects --- suppose a caller passes in memory & max_memory values that are measured in floating-point GB. If the max_memory was passed in as 1024.0 then, for 100 items, the dp_knapsack code would allocate a float32 array of shape (101, 10240001) and this would require about 4GB.
Given the units of these inputs aren't documented (& certainly not enforced by the type system) & there aren't runtime range checks on the value of max_memory there's a lot of room for something like this to be happening.
Perhaps dp_knapsack could be reimplemented where it is responsible for rescaling input memory values relative to max_memory, where the rescaling always forces max_memory to be 1 before the memory values are quantised. Then there wouldn't be a way for the caller to get the undocumented calling convention wrong.
1) rejection sampling - this is the name to the general technique used in the first example, to estimate pi by sampling from a uniform distribution over a unit square (easy) and then rejecting the samples that fall outside of the distribution you're actually interested in (unit disk).
Another simple example of rejection sampling is if you want to randomly pick between 5 ordered options and only have a d6. Roll the d6. If you roll a 6, reject the roll & re-roll. If you roll 1-5, that's your choice.
2) the Metropolis-Hastings algorithm -- this is a Markov chain Monte Carlo algorithm. It can be useful in some applications to sample from a distribution that is difficult to sample from.
Suppose you have some system described by a state vector x & you know that the probability of the system being in state x, p(x), is proportional to q(x), where q is some function you can compute. If you could integrate q over x, to give Z := integral_{x in X} q(x) dx then you'd have p(x) = Z^-1 q(x)
For a concrete example, x might be a state vector of a physical system -- say a bunch of molecules in a box, where you can compute the energy of any given state u(x) and know the probability of x, p(x), is proportional to exp(-u(x)).
Metropolis-Hastings is neat as it gives you a way to sample from p even if you cannot compute Z or sample from q --- you just need to have some way to sample a proposed a new candidate state x' from x (this proposal distribution doesn't need to have any relationship to the distributions p & q you're actually interested in). Can often think of the proposed candidate state x' as some kind of local mutation of x. Provided you can compute q(x') / q(x), you can use that ratio as a probability of accepting the move to replace x with candidate x'.
By the algorithm depending on the ratio of probabilities of two different states p(x') / p(x) = q(x') / q(x), it lets you sample from p even if you can't compute Z or have any direct way to sample from p or q. *
Metropolis-Hastings & Markov Chain Monte Carlo methods are definitely in the territory of clever 'what to do if you don't know what to do' methods --- if there's some other more direct & practical way of computing the thing you're trying to compute, use that instead! But if there's not, & you have some gnarly problem, maybe MCMC might be the best option available.
* caveat caveat caveat: provided you let the sampler run long enough for it to 'burn in', & perhaps restart it a few times from different initial states x_0 to reduce the chance of it getting trapped in some unrepresentative local optima
PressAudit's Pr(D win senate) = 0.63 is in the ballpark with forecasts from The Economist (0.58) & FiftyPlusOne (0.73)
Here's what PressAudit's midterms forecast page says about methodology:
> PressAudit probabilities blend recent polls with Polymarket and Kalshi odds, giving polls more weight as more surveys become available. Chamber-control odds come from 10,000 simulations that account for shared national and state-level shifts. These are experimental estimates, not guarantees; the simulation assumptions have not been historically calibrated.
Hmm. In contrast, FiftyPlusOne's forecasting model doesn't use prediction markets as inputs:
> Other forecasters are increasingly using prediction markets as signals in their forecasting systems. We do not [...] There is a poisonous logical circularity in using prediction markets to update a statistical model when the statistical model is itself being factored into the prediction market. Because of these limitations, our opinion is that if you’re going to inject prediction market data into your forecasting model, you should at least let users view a version that doesn’t rely on such data.
[1] https://www.economist.com/interactive/2026/us-midterms/predi...
[2] https://fiftyplusone.news/
[3] https://blog.fiftyplusone.news/p/2026-forecast-methodology
> Across the country, there are now barely 4,000 bank and building society branches, down 80 per cent in 40 years.
So, a big decline, but still 20x as many high street banks than what a 99% decline claims.
[1] https://www.ft.com/content/10ce1086-a9ae-4851-92e4-3b6efc8a0...
In traditional brainfuck, a single < suffices to move The Pointer one cell to the left.
For a dialect of brainfuck where The Pointer is 3x as heavy as is traditional, you'd have to apply 3x the effort, i.e. <<<, in order to move one cell to the left.
Cursed bogocomputing idea of the day: a variant of brainfuck where The Pointer is physically simulated, with mass & momentum. < & > apply impulses. The Pointer continues to move across The Array with momentum after you apply an impulse.
I recall we found a neat use for call stack introspection in one project - not to change control flow but to improve logging. Inside an open_db_connection utility function, to auto-generate an informational name describing which part of the codebase had opened the connection:
E.g. some_backend_process: main -> ... > grandparent -> parent -> open_db_connection
We'd use information from the call stack generate a string "some_backend_process grandparent.parent" describing the call site which could be passed to postgres as the application_name [1] when establishing a connection. Then from the database side, if we had problematic queries at runtime, we had a lot more clues to figure out which part of the backend codebase was responsible [2].
There'd be a way to do something equivalent without peeking at the call stack, by requiring the caller to explicitly pass a descriptive & unique name, but that makes things a bit more error-prone, especially since some devs would be prone to copy-pasting chunks of existing code & reusing the same name everywhere.
[1] https://www.postgresql.org/docs/current/libpq-connect.html#L... [2] https://www.postgresql.org/docs/current/monitoring-stats.htm...
No idea. The boring (in a positive sense) answer I'd expect for any backend API server is that encryption in transit is handled by TLS. So I'd expect either the MCP server in question can be configured to support TLS connections & refuse plaintext HTTP connections, or that for a production-like deployment it expects to be deployed behind a reverse proxy that is responsible for terminating TLS.
Market caps are roughly expected future earnings, discounted back to give some net present value. They're expectations about the profitability of businesses, with expected profits accumulated over forecasts decades into the future. Market caps ignore privately held businesses, small businesses, state owned businesses & economic activity, economic output that might be happening at a household level, etc.
GDP is some peculiar measure of a country's economic output, over one year. It doesn't care if the economic activity is profitable or not & it doesn't care if the surplus of the economic activity is extracted by public companies or not. It's not forward-looking & based on expectations.
all that said, ggm has a fair point that individual investors & retirees with share portfolios directly benefit from the profits of companies whose economic activities may not be particularly pro-social & beneficial to the world. it's similar for climate change -- easy to point the finger at the energy producer, the big dirty brown coal plant. harder to point the finger at the demand side of the same equation - much of which is household demand. but both the individual end consumer households and the energy producer & everyone else involved in the value chain benefit out of the trade, even if the trade is net-negative for the world if we were to properly account for the externalities (e.g. polluting the atmosphere with CO_2 pushes the costs to everyone on the planet, current & future generations, not just the folks benefiting from the trade).
On the non fiction side, I'm slowly chipping away at Joe Studwell's book How Asia Works, about East Asian development. In the first section of the book, the author argues that the foundation for successful development was boosting agricultural output -- instead of spending precious foreign currency on food imports, surplus agricultural output can be exported & intensive farming provides a way to soak up and use labour before other industries develop.
Studwell also argues for the importance of land reform in boosting agricultural output -- appropriating land from wealthy landlords & redistributing it to landless peasants & tenants. This happened in both socialist & capitalist societies. There was a huge demand for land reform from landless peasants. I was completely ignorant of this chunk of history & found it fascinating. Agricultural output increases on a per hectare basis when farmers have the incentive to work hard - unlike if they're day labourers or share croppers paying much of their output as rent. Landlords don't have an incentive to increase output as its easier for them to earn money from renting out their land & lending money. Studwell gives examples of small farmer-owned farms being much more productive than colonial plantation style farming. Developmental success stories (Japan, Taiwan, South Korea) were those where governments supported their huge newly created markets of tiny landowner-farmers with subsidised fertiliser inputs, better varieties of crops etc & where peasants & tenants got a seat at the table to influence the land redistribution process. There are also stories of failures where wealthy elites got control of the land reform process & rendered it largely ineffective (the Philippines).
With one of these solver-based approaches, you encode the problem with decision variables in some fashion, state all the constraints & call solve. There's some art & experience in how to encode & model the problem, but the specification of the model & the problem is fairly declarative.
What's great about general purpose solver-based approaches is that its usually faster (in terms of implementation time & effort) to start getting solutions & they're also much more robust to changes in requirements & the problem statement. That's less of a concern in this toy example, where the problem is small, well-defined & unambiguous, but in a real business/industrial application, the problem statement often changes considerably over time.
I agree that the performance & behaviour of a black box solver may be much harder to reason about than something you custom build by hand & know inside out, but if the general purpose black box solver is 'good enough' for the distributions of problem instances it needs to process, then there's no need to custom-build anything. Throw the black box solver at it -- job's done, and you're left with something that's both quite readable (declarative modelling of the problem, particularly if someone documents the formulation - the meaning of all the decision variables, index sets, constraints, objective terms etc) & flexible to future change.
Custom solvers & heuristics can sometimes be much, much more effective in being able to scale and solve industrial-scale problems, but usually at the expense of being much more effort to set up in the first place, and very fragile to changes in requirements -- if you learn something a few weeks into a project that perturbs the problem statement, maybe it wrecks the particular mathematical structure you were relying upon for a custom solver/heuristic, so you need to chuck out all your work & go back to the drawing board.
misc feedback
- dominant strategy seems to be drive to point blank range & fire. needs some playtesting & rework to make it interesting for 2 players.
- how do you bring up help for a reminder of what the controls are once the game is in progress?
- the arrow keys for controlling the turret are unintuitive. i'd expect left & right arrows to change the barrel angle, like in the original scorched earth, but here they change the power level
- the visual trajectory preview doesnt seem useful whenever the moon is involved as by the time you fire, the moon has moved the trajectory is wildly different to whatever the preview showed
But none of this "implementing stuff" is making progress to solving the issue of unclear / changing / vague / missing requirements.
To crudely estimate a fundamental valuation for MongoDB as a discounted sequence of future earnings, we'd need some understanding of the main factors that are driving this change in the net profit margin (over the next 5 years do we expect those factors to persist? to decay? to accelerate?), some modelling assumptions & forecasts for how they'll evolve over the next decade or two, and a discount factor.
Out of curiosity, I bashed together a naive NPV valuation, in complete ignorance of MongoDB's underlying business.
Completely unjustified modelling assumptions: suppose MongoDB can grow revenue at +20% / year for 5 years, then +5% / year for the next 5, then hitting a steady state +2.5% / year revenue growth; MongoDB grows net profit margin by +5% every year until hitting a 25% net profit margin, where it tops out; discount factor of 9.5% (= 5% risk free rate + 4.5% equity risk premium); no change in number of shares outstanding (perhaps optimistic, given they issued a bunch of stock within the last 5 years). Projecting this out 20 years & then using a 20x P/E valuation multiple at year 20 for the terminal value gives us an NPV estimate of the value at about $290 / share.
So if you believe MongoDB's business will do about that well, with your fundamental valuation investor hat on you could consider buying some stock if it were offered at, say, half the current market price or less -- assuming there isn't anything more attractive to invest in.
If you believe MongoDB's revenue growth & improvement in net profit margin will be much stronger over the next decade, maybe you'd be comfortable buying closer to the current market price.
(I don't hold any MongoDB stock & find it hard to stomach investing in growth companies vs companies that are more mature & easier to understand, but I appreciate that to value growth stocks you're not going to have much luck using P/B or P/E ratios)
One way to start could be to ignore performance of the data structure.
The first main job dicts are being used for is the `mem` dict mapping a key (variable name) to some value record.
A data structure that supports Store(K, V) & V = Get(K) could be something like an stack allocated array of (Key, Value) pairs, that you search through using linear search to implement Store & Get. It wouldn't be very fast, but you probably don't have too many items in a typical DSL program. You'd need to implement some kind of stack or so on - or perhaps you could get away with reserving some fixed capacity.
Interesting to see how the author decomposed the problem:
- C raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.c
~~ LLM refactor of the C code ~~>
- SSA-style C raytracer code https://github.com/mTvare6/rayfuck/blob/master/ray_ssa.c
~~ c2dsl.py helper script (compiler) ~~>
- DSL raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.dsl
~~ dsl2bf.py helper script (another compiler) ~~>
BF raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.bf (~22 mb of unreadable nonsense)
The dsl2bf compiler has a bunch of examples of implementing slightly higher level abstractions atop BF primitives. E.g. "go" to move the pointer to a different offset, destructive & non-destructive copies, all the way up to things like division -- BF only natively offers unary addition/subtraction.
If we have a read of the code of the final compiler, dsl2bf.py, the abstractions used in that code are relatively simple: global variables, local variables, lists, dicts, for loops, function definitions & function calls. It is feasible to implement a simple compiler like dsl2bf in BF itself, with sufficient head scratching. Again, quite unpleasant to try it directly in BF, but a next step could be to implement the dsl2bf compiler in the DSL itself - extending it if necessary, then compiling it with itself to produce a dsl2bf compiler implemented in BF.
> It has been discovered that online used bookstores across Japan have been receiving a surge of large orders for books since around August of this year. Interviews with these bookstores reveal reports of "100 books sold per day" and "days where sales have increased fivefold," leading to widespread speculation within the industry that the orders are intended to collect training data for generative AI (artificial intelligence). Further investigation revealed records of over 50 tons of books being exported from Japan to the United States. Is it acceptable for books to be consumed and discarded for AI training?
[...]
> Nippon Television investigated using "Sayari," a tool that analyzes import and export data, and confirmed records that a group company of this major Japanese book distributor exported more than 50 tons of "JAPANESE BOOKS" to the US since last year. Assuming that all the books were heavy hardcovers (calculated at 500 grams), this would amount to the equivalent of 100,000 books.
It's unclear if this is very useful.
The reason it may not be very useful is that one of Deflate's ingredients is a pass that replaces repeated substrings with backreferences to the earlier occurrence in the plaintext input stream.
E.g. suppose we want to find an n=200 byte sequence x that minimises len(gzip(context+prompt+x)).
If there exists any 200 byte sequence y such that prompt+y is a substring of context, then Deflate can encode prompt+y as a backreference to that earlier sequence - it needs to store a match-length & a distance-length, encoded using its Huffman trees. This candidate solution y may not be a global minima to our stated objective function, but if not, it's probably going to be a very good near-optimal approximate solution.
Taking a step back, repeating huge chunks of the input context produces something that's great for minimising compressed output size but doesn't seem particularly helpful as a generative model.
edit:
Yep, I tried it out by running an experiment. Searching for the prompt in the context & then copying the following text as the solution produces solutions that are much better, in the sense of minimising the compressed output length, than beam search, while also being unhelpful as a generative tool.
With the same example as the blog post:
context: first 30,000 bytes of tinyshakespeare.txt
prompt: 'MENENIUS:\n'
Let L(x) denote len(gzip(context+prompt+x)), our objective function
Let's call the proposed search method of searching for the prompt in the input rfind (after python's str.rfind).
Then we have
search method soln soln length feasible? objective value search time (wall clock, s)
------------- ---- ----------- --------- --------------- ---------------------------
emptystring "" 0 no 13,023 0.04s
gzipt beam search see blog post 200 yes 13,051 11.93s
rfind see below 200 yes 13,026 0.04s
Here's the solution 'generated' by rfind copying and pasting from the input context, starting from the rightmost occurrence of "MENENIUS:"
MENENIUS:
O, true-bred!
First Senator:
Your company to the Capitol; where, I know,
Our greatest friends attend us.
TITUS:
COMINIUS:
Noble Marcius!
First Senator:
MARCIUS:
Nay, let them follow:
The Volsces
def find_candidate_solution_from_context(context, prompt, length):
n = len(context)
i = context.rfind(prompt, 0, n-length)
if i < 0:
return b''
i += len(prompt)
return context[i:i+length]
out += find_candidate_solution_from_context(corpus_window, prompt, length)