HN user
There are 5 trits.
Whoops, of course!
I think storing 5 consecutive bytes per entry in a size-1280 table will still be faster than 5 single-byte lookups in separate size-256 tables, since it only requires 1 (unaligned) dword MOV and 1 byte MOV.
You can have a single 3x256=768-byte table -- just multiply the input byte by 3 to get the offset into the table, and read out the 3 trits (1 trit per byte) beginning at that offset.
ETA: If you're prepared to waste a byte per entry so that entries are 4 bytes wide, on x86 you can use effective address calculation to do the multiplication for you, letting you decode 3 trits in 1 CPU instruction:
MOV EAX,[RBX+RCX*4]A 256x3=768-byte lookup table will almost certainly be faster on a CPU. It will fit easily in L1 cache, and can extract 3 bytes at a time.
Ironically, x86 has an instruction, XLATB, that does almost exactly this (looking up a byte in a 256-byte table) -- but using it is actually slower than using an equivalent MOVZX RAX,AL; MOV AL,[RBX+RAX] sequence on modern CPUs.
Personally I’m exploring ways that AI can better serve people, rather than how I can replace people in my life.
Can you think of anything that an AI could do that could not be done by one or more people, for money?
Trying to reduce how much you pay other people, with its attendant job and self-worth losses, has been happening since at least the Industrial Revolution; nothing about it is novel. The only novelty of the latest wave (AI) is that it affects a class of society (knowledge workers; smart people with degrees) that previously considered itself immune to this process.
If you also hold all technological advances since the Industrial Revolution to be "bad in our culture", then no contradiction arises. Otherwise, please explain why that was good, but this is bad.
Insidious "gift" idea: A set of wooden track pieces with lengths and join angles chosen such that no subset of them can form a closed loop. No matter what you try, it's always just a little bit off.
I immediately got nerd-sniped by this...
A heuristic could try all kinds of fun force-directed placement stuff. For an exact solver, I think your best bet would (unfortunately) be to finely quantise the possible positions and orientations of each piece, describe each piece by 2 sets of positioned unit vectors (the vectors in one set start at the centre positions of each "hole" and are directed towards the centre of the piece, the other set is similar but holds the "plug" positions and orientations), and say that a partial solution is feasible iff every "plug" position is sufficiently far from all other plugs, and either sufficiently far from all other holes or within some small tolerances (in terms of both distance and angle) of some other hole. Actually, you would probably also need to treat the piece body as a "nothing else can occupy these positions" constraint. I say "unfortunate" because the position and orientation grids would need to be very fine relative to the size of the pieces, leading to a large state space thus long running times.
I think it would be fun to look for solutions that maximise the "badness" (e.g., sum of distances between matched holes and plugs) :)
Given my feelings about the quality of the... discourse... on LinkedIn, I can't tell if this is a genuine compliment or a fiercely backhanded one.
I'll supply such a comment: Any software open sourced by any for-profit company, including Google, is a calculated move ultimately intended to increase their bottom line, and it's naive to think otherwise.
I got a solid laugh out of this.
If you're curious what the actual optimal Paris cost is, I suggest formulating the problem as an integer linear program and submitting it to Gurobi on NEOS [0]. Gurobi is arguably the strongest commercial ILP solver; big companies pay big dollars to use it to optimise schedules, industrial processes, etc. I'm not sure it could solve this problem to optimality in the 8 hours NEOS provides you, but it might -- KIRO has some similarities to the Vehicle Routing Problem, variants of which are very commercially important. In any case, Gurobi is a monster, and even if you don't get an exact solution, it will give you a lower bound (which may not be tight, but it's nonetheless interesting).
I love the first JPEG where the final image is... a different picture of the cat. "The first images you see are just approximations to the final, exact version." Audience's heads nod in understanding
This idea sounded like it had lots of humour potential. Unfortunately, if there is in fact humour to be found in this dataset, it appears to be beyond the reach of current data science techniques.
I've found the most consistent indicator of overall app quality to be whether it is extremely small in size. An Android app under a megabyte in size is going to use the familiar, high-performance platform-native UI because it doesn't have room to do anything else. It is gonna do what it says on the tin and nothing else. It won't have ads. It won't phone home. Since it doesn't show ads and doesn't phone home, it's quite likely open source, meaning it quite likely has a GitHub project that I can look into if something goes wrong -- and because it's so tiny, I won't need to spend days trying to figure out how it works.
The ARC-AGI Prize 3 [0] is an agentic LLM benchmark that amounts to basically this: Seeing how well they can learn to play video games. They aren't very good yet -- the recent GPT 5.6 Sol only reached a score of 7.5%.
There’s really not much question we are in a giant bubble
IIUC, some indicators correlated with previous bubbles are lighting up now, which is being interpreted as evidence that AI is likewise a bubble. But what about indicators of previous non-bubbles? How did it look when textile mills were first industrialised, or kerosene replaced whale oil for lighting, or the electric grid became widespread, etc. -- real advances that materially increased productivity in a lasting way? If these same indicators lit up in those cases too, how can we distinguish bubble from genuine advance?
This is really surprising! I've never considered the possibility that using an equality test to skip a write that would be a no-op could break a dependency and thus lead to higher perf overall if the "equal" outcome occurs often enough. This might be applicable in many situations where you "edit" some data in-place, but most of the time there are few or no changes.
As I understand it, the value proposition is that it can deal with a spiky stream of problems to solve better than buying a bunch of on-prem hardware and running local solvers on them would -- similar to why it often makes sense to spin up cloud VMs on demand to handle spiky web traffic.
Performance on an individual problem is still interesting of course, but maybe not the main focus.
Not if i have to pay for it and use a different API?
TFA says Quicopt supports Pyomo. The example uses the "free tier", so you're not paying for anything (yet -- though I'm confused by the phrase "one-time entry point").
NEOS has generous limits, but the fact that Gurobi are still in business tells me that NEOS by itself can't satisfy everyone. Were Quicopt to offer access to Gurobi, etc., per your hypothetical, I think this would clearly be valuable.
More strongly I don't think it's crazy to offer "just" publicly available solvers, despite how much weaker they are than commercial ones. If I had to solve a stream of optimisation problems that were individually pretty easy but the rate of arrival was unpredictable, using such an "Optimisation as a Service" would make sense in much the same way that it makes more sense to serve spiky web traffic by spinning up cloud VMs on demand than by buying a bunch of on-prem boxes, even though those cloud VMs might be very weak.
In every context I know of, "naive" is a condescending term when applied to an adult. Do artists in this "genre" appreciate their work being labelled this way? "Unconventional" was right there. It means roughly the same thing, but without the side helping of implied... deficit.
Can an artist who submits their work to this gallery -- which features the word in its very name -- really be called "naive"?
I can't tell that the works are "naive" in any sense -- they look no better or worse to me than other artwork -- and I feel no desire to change that by "educating" myself on how "non-naive" art is supposedly better.
But right now, this wouldn't even be interesting to me to use even if they actually were fronting commercial solvers, because they can't actually run it any faster
So you use NEOS, but another service offering the same thing as NEOS would not be useful?
Thanks, I've been using SQLite for a while and I did not realise that FKs are disabled by default! Fortunately not on anything critical, still... Yikes.
taking a tool’s shortcomings and reselling them as a “puzzle game” which is “fun” to solve
cough Perl cough
Complete speculation, but it could be simply that clang only considers applying the branchless optimisation when the code inside the "if" block "looks like" a single instruction/statement -- and this "looks like" check might be done quite early, before "*x++ = y;" and "*x = y; x++;" are converted to the same thing.
Why restrict the optimisation unnecessarily like this? It's never the intention to artificially restrict optimisations, but they are difficult to test and debug as they can interact with other optimisations, and applying an optimisation too broadly leads to horrible correctness bugs. So if you cannot be certain that you understand all possible interactions now and in the future, it makes some sense to be conservative in applying them.
12 nautical bushels per Fahrenheit
Cost/task: $25.1K
Yikes
Rookie numbers! You gotta pump those numbers up!
For me personally, seeing the phrase "both sides" used pejoratively is a red flag telling me I don't need to read any further.
When people disagree about something, hearing from both sides is important. Can this ideal of openmindedness be cynically abused by strawmanning one side while steelmanning the other? Yes, but in that case the appropriate response is to criticise the specific ways that one or both sides were misrepresented -- which is also the appropriate response to a piece that only presents one side, and does it badly. Muttering about "both sides" never adds anything to an argument. All it does is signal a deep commitment to remaining entrenched in your current position.
This doesn't add any malware risks beyond what a JavaScript-enabled browser already allows.
Re excessive browser memory use: Yes, it adds non-negligible weight, but again, you could already achieve excessive browser memory usage before this. For comparison, a true color 1080p image, uncompressed (which is needed for actual display on screen) is only slightly smaller at 6.22Mb.
Elm was better without custom kernel modules and sync JS-interop.
That may be true, but what would have been even better is never having the feature, as opposed to adding it, allowing many people to become dependent on it, and then taking it away. (Like everyone else, I'm not claiming Evan should not be able to make such changes -- just that making such changes will breed predictable resentment.)
It kept the Elm kernel small and portable.
This is a good thing.
It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
This is a bad thing, presented as a good thing. Boring as it may be, if wrapping an existing piece of working code does the job with no downsides then it's always better to do that than reimplement it for reimplementation's sake.