badmintonbaseba

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.

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.

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 doesn't help if revocation, without renewal means immediate outage.

I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.

Sure, performance might never become a problem, it is relatively rare. But when it does there is very little you can do about it.

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.

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.

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.

JS might have other problems, but not being able to resolve algorithmic complexity issues is not one of them.

Also everyone heard of pain killers that are non-opioid, so you can't really get around explaining why this one is novel.

How does uv get around this?

It's up to the demangler, the info must be there in the decorated/mangled name. Demanglers sometimes choke on these complex symbols.

AFAIK MSVC also changed their lambda ABI once, including mangling. As I recall at one point it even produced some hash in the decorated/mangled name, with no way to revert it, but that was before /Zc:lambda (enabled by default from C++20).

> Smaller size at runtime (uses less memory).

Yours is smaller (in terms of sizeof), because std::function employs small-buffer optimization (SBO). That is if the user data fits into a specific size, then it's stored inline the std::function, instead of getting heap allocated. Yours need heap allocation for the ones that take data.

Whether yours win or lose on using less memory heavily depends on your typical closure sizes.

> Faster at runtime

Benchmark, please.

Just use std::function, you don't have to pass a lambda. Any callable is fine.

Still better than the MS Teams website, which can get into a weird state and redirect in circles.

It is possible to approximate perspective using piecewise affine transformations. It is certainly possible to match the perspective transformation at the vertices of the subdivisions, and only be somewhat off within.

How do you transform paths? Do you just transform the control points?

An other approach would be to apply the transformation to SVG elements separately. Inkscape has a perspective transformation tool, which you can apply to paths (and paths only). It probably needs to do approximation and subdivision on the path itself though, which is possibly more complex.

I don't think your algorithm is correct. At least on the checkerboard example on the cube face the diagonals are curved. Perspective transformation doesn't do that.

Possibly you do the subdivisions along the edges uniformly in the target space, and map them to uniform subdivisions in the source space, but that's not correct.

edit:

Comparison of the article's and the correct perspective transform:

https://imgur.com/RbRuGxD

I wonder how effectively the regulation achieves its desired outcome of fewer minors being exposed to porn.

Made it to the summit at double speed.

  :strawberry:x14
  3:17:46
  deaths:1981

Well, that's true, but at least now compiler explorer links will stop working when compiler explorer vanishes, but not before that.

I think the most valuable long-living compiler explorer links are in bug reports. I like to link to compiler explorer in bug reports for convenience, but I also include the code in the report itself, and specify what compiler I used with what version to reproduce the bug. I don't expect compiler explorer to vanish anytime soon, but making bug reports self-contained like this protects against that.

Which makes sense, there is only so much you can do with loudspeakers to affect the perceived location, you don't really know where the loudspeakers and the listener are located relative to each other.

Possibly, I'm indeed on a 120Hz display. I still got up to 1600m, it's a good challenge.

edit: 2000m now that I revisited. Crazy hard.

At least video games use way more complex models for that, AFAIK. It might be tricky to apply to mixes of recorded media, so loudness is commonly used there.

The main utility isn't for the user to more precisely locate the sound source within the screen. Phased speaker arrays allow emitting sound in controlled directions, even multiple sound channels to different directions at the same time.

For some reason that runs at like double speed for me, very challenging.

There are already barriers like that at the edges of the common:

https://maps.app.goo.gl/1anrXAPRE3Dp3ZFo9

https://maps.app.goo.gl/YTfAYamG55SftWay6

https://maps.app.goo.gl/AWKxr76HUzgvSqBG7

People have free access to the river and the field, any physical barrier would limit that.

That's a screenshot of this website:

https://ijmacd.github.io/rfc3339-iso8601/

The cows graze in parks shared with people. You don't want to fence around the people, just the cows. This is an example of a field that the cows visit regularly:

https://maps.app.goo.gl/iYbCeJu8fvrmuAXz9