I was looking for the etymology of these two terms which I had thought to be synonyms. As an avid screenshotter myself, I never knew the subtleties that differentiate it from screengrabbing...
In Python, coroutines cannot yield from within another function call: if coroutine A calls function B, B cannot yield. In Lua, it's possible to yield a coroutine at any function depth: B can yield.
To implement something like this in a compiled language, you just need multiple stacks instead of the usual 1. Most architectures, such as x86, have a stack pointer register; when yielding a coroutine, just change the sp register to point to some other stack -- when resuming, restore the sp.
This is not a new concept. Pokémon on the gameboy did this for its UI fiber, for example.
I agree that it's must be a standard understanding among statisticians that one of these interpretations is implied (although maybe given what happened with the Monty Hall problem, it's not really so standard?). It's legitimately interesting that these two different interpretations result in different answers, but I feel that it is rather confusing to tell an outsider of the field that 1/3 is "the" answer and that their intuitions are wrong -- when actually it's just one conventional interpretation.
The Monty Hall problem is often understated, and for example the "intuitive" answer of 1/2 (i.e. that switching doesn't matter) can be restored if we assume the host himself didn't know where the car was and just happened to reveal another mule by chance. The assumption that the host knows where the car is is often not mentioned explicitly. Now it's just convention that in other such scenarios that there should be a similar understanding.
I found that Elden Ring ran better on Proton on Linux than on native Windows on the same device. Loaded faster and ran more smoothly. I do not know why.
I still feel the problem arises from English, not probability. It's clear that "we've checked one child, it's a boy" implies "at least one child is a boy." But furthermore, If someone tells me "at least one the two kids is a boy," I do not know how they arrived at that information. It could either have been through the bucket method or the knock-at-door method.
From a Bayesian perspective, we should consider both as possible with priors P and 1-P (i.e. the answer is somewhere between 1/3 and 1/2). On the other hand, from the perspective of someone taking a math test, I'd rather like the professor to tell me their own prior -- which, given they felt confident enough to put this on a test, they must believe it's basically 0 or basically 1.
Ultimately, both scenarios are describable by the same English phrase, and it feels proscriptivist to just consider one of them, even if it happens to have the least entropy in this case. There should always be the followup question asked: "_how_ did you know this?" and if it's kicked back to " because someone told me," either we need to ask how that person learned it or else bust out some priors.
Probability does not bite; describing partial information in English bites.
It's not actually true that the probability is 1/3, nor that the probability is 1/2. (Same with 13/27 vs 1/2). The problem is underspecified. Here's two different more specified versions for which the answer is clear:
1. Sample from all two-child families with at least one boy. What portion of these families have two boys? (answer, rot13: n guveq)
2. Choose a random two-child family, then knock on their door. A boy answers. What are the odds the other child is a boy? (rot13: bar unys)
These are both consistent with the description "at least one child is a boy"!
The day-of-week versions:
3. Sample from all two-child families with at least one boy born on a Tuesday. The odds both are boys? (nyzbfg unys)
4. Knock on the door of a random two-child family. A boy born on Tuesday answers. Odds both are boys? (n unys)
"Deep coroutines:" where you can yield from a function called from the coroutine. Lua supports this, but python doesn't (as far as I can tell). Is there a term for this?
To the author: you could make the code even cleaner by moving the yield to within the action functions. Though maybe this won't work as well for parallel actions...
I may have misunderstood, but I believe step 1 (eliding loads) is simply a cache scheduling problem. The optimal solution is the greedy "furthest in the future" eviction policy.
Gimp takes strange turns now and then, does but gradually improve over time. It used to be that fuzzy-select would cause immense lag practically every time. Now my biggest complaint with selection is merely that the rectangle select tool defaults to centred.
If it helps, you can enable the old style icons in preferences.
"Silence" apparently does what Signal used to: https://silence.im/#download -- unencrypted SMS messages, and encrypted SMS for others who use the same app.