Yes, that's right.
I'll have to update my blog with additional information about this. Thank you!
BTW, you can also start from the top right with the two 1s. One of the rightmost two cells contains a mine, so the 3rd from the right can't.
Readit Newsbadmintonbaseba commented on Making Explainable Minesweeper sublevelgames.github.io/b... · Posted by u/greentec
badmintonbaseba commented on Making Explainable Minesweeper sublevelgames.github.io/b... · Posted by u/greentec
I tried some no-guess variants but somehow there's a kind of sterile feeling to it. For some reason it makes it more boring compared to vanilla variant. It of course excels when I'm getting frustrated at guesses and 50/50, but otherwise I play the normal minesweeper more.
It's an entirely a different metagame if the goal is to improve your personal best time over multiple games within a given time frame. Once you get good enough with the deterministic reasoning, the game transforms into probabilistic strategies for time saves in both the vanilla and the guaranteed solvable game, and at that point the two games are very different.
For the vanilla game the guesses become integral part of the game that you can strategize around. There are guesses where some squares are less likely to contain mines than others. You can also try to uncover guesses as early as possible in a game, so you don't waste too much time on a game that is doomed to fail.
Both a human and a machine learn from it. You can design an LLM that doesn’t spit back the entire text after annealing. It just learns the essence like a human.
Morally maybe, but AFAIK machines "learning" and creating creative works on their own is not recognized legally, at least certainly not the same way as for people.
That's why key revocation, like credit card blocking, should be a separate service that is available 24x7. Like, if you know the value of an AWS token, this should be sufficient data for you to call an AWS API that revokes it.
That doesn't help if revocation, without renewal means immediate outage.
badmintonbaseba commented on XSLT – Native, zero-config build system for the Web github.com/pacocoursey/xs... · Posted by u/_kush
Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.
I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.
badmintonbaseba commented on XSLT – Native, zero-config build system for the Web github.com/pacocoursey/xs... · Posted by u/_kush
From my experience, most simple websites are fine with XSLT 1.0 and don't experience any performance problems.
Sure, performance might never become a problem, it is relatively rare. But when it does there is very little you can do about it.
badmintonbaseba commented on XSLT – Native, zero-config build system for the Web github.com/pacocoursey/xs... · Posted by u/_kush
Are you using the commercial version of Saxon? It's not expensive, and IMHO worth it for the features it supports (including the newer standards) and the performance. If I remember correctly (it was a long time ago) it does some clever optimizations.
We didn't use Saxon, I don't work there anymore. We also supported client-side (browser) XSLT processing, as well as server-side. It might have helped on the server side, maybe could even resolve some algorithmic complexities with some memoization (possibly trading off memory consumption).
But in the end the core problem is XSLT, the language. Despite being a complete programming language, your options are very limited for resolving performance issues when working within the language.
badmintonbaseba commented on Why is the Rust compiler so slow? sharnoff.io/blog/why-rust... · Posted by u/Bogdanp
> Most of the build time is spent in the code generation phase.
I can believe that, but even so it's caused by the type system monomorphising everything. When it use qsort from libc, you are using per-compiled code from a library. When you use slice::sort(), you get custom assembler compiled to suit your application. Thus, there is a lot more code generation going on, and that is caused by the tradeoffs they've made with the type system.
Rusts approach give you all sorts of advantages, like fast code and strong compile time type checking. But it comes with warts too, like fat binaries, and a bug in slice::sort() can't be fixed by just shipping of the std dynamic library, because there is no such library. It's been recompiled, just for you.
FWIW, modern C++ (like boost) that places everything in templates in .h files suffers from the same problem. If Swift suffers from it too, I'd wager it's the same cause.
It's partly by the type system. You can implement a std::sort (or slice::sort()) that just delegates to qsort or a qsort-like implementation and have roughly the same compile time performance as just using qsort straight.
But not having to is a win, as the monomorphised sorts are just much faster at runtime than having to do an indirect call for each comparison.
badmintonbaseba commented on XSLT – Native, zero-config build system for the Web github.com/pacocoursey/xs... · Posted by u/_kush
I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could.
1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards.
2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes.
badmintonbaseba commented on The first non-opoid painkiller worksinprogress.news/p/th... · Posted by u/ortegaygasset
I guess that would make sense in a scientific paper or journal, but most people would have no idea what that means and just make for a confusing title that would turn people off from reading it. Almost everyone has heard of opiates in the evening news or social media.
Also everyone heard of pain killers that are non-opioid, so you can't really get around explaining why this one is novel.