The United States is a country that doesn't require any form of identification to have a phone number. You can buy a "burner phone" at any Walmart, with prepaid minutes and no contract, in cash.
... How about fixing basic things like the cursor position in code blocks, and being able to select text on mobile, instead of unnecessary "AI Agents"?
Or is the frontend now supposedly obsolete since all the work will be done by "AI"?
Indeed. About 26% of the disk space for a freshly-installed copy of pip 25.2 for Python 3.13 comes from https://pypi.org/project/rich/ (and its otherwise-unneeded dependency https://pypi.org/project/Pygments/), "a Python library for rich text and beautiful formatting in the terminal", hardly any of the features of which are relevant to pip. This is in spite of an apparent manual tree-shaking effort (mostly on Pygments) — a separate installed copy of rich+Pygments is larger than pip. But even with that attempt, for example, there are hundreds of kilobytes taken up for a single giant mapping of "friendly" string names to literally thousands of emoji.
Another 20% or more is https://pypi.org/project/requests/ and its dependencies — this is an extremely popular project despite that the standard library already provides the ability to make HTTPS connections (people just hate the API that much). One of requests' dependencies is certifi, which is basically just a .pem file in Python package form. The vendored requests has not seen any tree-shaking as far as I can tell.
This sort of thing is a big part of why I'll be able to make PAPER much smaller.
What is the actual model that takes 15 seconds to compute?
If I understand the setting, you are estimating the demand curve for a given price... And there are only 40 such curves to compute.
Surely each curve is fit with only a few parameters, probably fewer than five. (I think for small price ranges the demand curve is usually approximated as something trivial like y=mx+b or y=a/(x+b)+c)
Why does evaluating the model at a particular price need to take milliseconds, yet alone 15 seconds?
This is the right question. The article reads like answering a XY-problem, where instead focusing on the actual issue, the author triples down on polishing a turd.
Haskell has genuine mutable memory, through State and IO.
But even without it, you can emulate mutation in a pure language by threading a "heap" parameter through everything.
There's only at most a log factor of extra space and time required in most computing models to "update" a persistent map (though I'm not sure the best way to encode persistent maps directly in Turing machine tapes, which is the model this result is specifically about)
What do you mean by "purely with logic, no guessing"?
"Guess and backtrack" is a totally valid form of deduction for pen-and-paper puzzles, it's just not very satisfying. But often (always?) there is a satisfying deduction technique that could have replaced the guess-and-check, it may just be fairly obtuse.
Or do you just mean where the clues for the raster don't result in a unique solution?
Not OP, but you don't ever have to guess and backtrack, you can always work out the next move. After playing about 100 boards several simple "rules" emerge which allow for this.
In summary the only ones that don't let you put a square immediately are "0", "1", "2" and "1, 1". And as soon as you put a square you can put some crosses (right click). In the end it becomes fairly mechanic.
Hot take: Some valid rules are just brute-force search in an altered state space.
For example, a valid "advanced" rule is this: consider a line, then consider all permutations of ways to complete it given the current state of the line. If a square is filled in/crossed out in all these permutations, then it you may fill it in/cross it out.
This is an O(n!) algorithm! In practice you only have <5 permutations.
If I recall correctly, it's actually possible to implement this in O(n) (or maybe O(n^2)) time and space using a "dynamic programming" algorithm.
But in general, Nonogram solving, like most pen-and-paper puzzles, is NP-Complete for large enough puzzles, so even such a high-powered rule isn't guaranteed to completely solve a (large) puzzle.
Only tangentially related, but just yesterday I learned of Lego's defunct "Modulex" brand, and the serious and apparently widely popular Lego-brick-based project management display boards from the '60s to the '90s.
The small size and comforting pastel colors seemed especially inviting to me.
It makes me yearn for more tactile and actually pleasant-to-work-with computer UIs.
reply