The most appropriate behavior is implemented by regex.
Find the empty string and replace with say
`($&)`
where
`$&`
refers to the captured variable, and with input
`xyz`,
the result is
`()x()y()z()`
With an empty input, the result is
`()`.
The result of indexOf can consistently return the first index of the first half open subrange in a string. It just so happens that the first subrange of an empty string in an empty string is [0, 0).
The limiting case is also an interesting way to look at it:
I haven't done the analysis, but one major assumption that the whole result is based on is whether the rules of the game are pre-established or just revealed after the first pick.
With an adversarial game host who has the option to reveal or not, maybe the result changes, but more importantly, it explains the intuitionistic refusal for some to buy the argument.
In an adversarial setup you basically get 1/3 wins like you started with because the optimal host move is to provide no information whether they reveal or not
In an adversarial setup, the optimal host move is to permit you to switch only if you picked the car. You still get 1/3 wins with optimal play (never switching), but it's better for the host because it allows people who think it's the traditional game to get zero wins.
If the host strategy isn't explicitly specified, it's reasonable to assume an adversarial setup, because seeing the player lose after switching would be more entertaining for the audience.
> seeing the player lose after switching would be more entertaining for the audience
Have you ever watched game shows? Because it is far more satisfying and fun for the audience when players win, not lose. If you are out there rooting for people to lose, you're a miserable bastard.
Now that I think about it, I have watched a few episodes of game shows, and I think you're right. They are always set up so the audience identifies with the players and the hosts are the adversaries, so you want the players to win.
Spherical Harmonics became extremely trendy in the graphics literature for dynamic lighting and pre-baked light maps of some sort, and completely dropped off at some point. Still remember some discussions and questions regarding how they're not easy to "orient".
They're an excellent solution for dynamic objects w/o too much hardware reqs(PS3 era HW should handle it easily), I think they're still used in tons of places.
It's just that most usage is through finished impls on lower end HW like Unity, Godot,etc and those that implement their own engines these days probably skip them for more global methods directly or just go for good-enough simpler solutions to get "gi-like" appearance like screen space ambient occlusion and/or cubemaps.
Also I think once people finds Greens walkthrough they can get much from it (or give up).
I often don't comment code, especially in personal stuff, but when I occasionally do, which happens mostly when things get overwhelming, I find bugs or fix things that I was stuck on. Writing forces you to understand better, name better, and almost feels like providing you with another perspective, all without leaving your own self.
What I like about this approach is that if you are using any other protocols for transport, everything becomes instantly portable.
Imagine having the same logic serving objects per IDs through HTTP and websockets.
Rest makes things more clumsy.
Though I would concede doing things the REST way, as in the app-server participating in the http headers/status enables caching and all sorts of things that would be hell to do through otherwise.
Interesting to think how many 10^6 faster gates would be needed to do the work of 10^9 at the same speed. Say take the 8086 and make it a million times faster. At about 30K transistors and 5MHz. A photonic 8086 apparently would run blindingly fast around anything available now.
Serial speed is always a gain up, no questions asked I guess.
Obviously all of that is over simplified, and not considering other components to any system that would be built (but hey, it's not like any of this is happening tomorrow anyway).
Computer science is much more like Mathematics than Physics.
It feels wrong calling "computer science" a science, in the same sense of calling "Mathematics" science.
In addition to the other mentioned reasons, I guess it's valuable feedback for their providers, and if that feedback is acted upon, it's beneficial for them.
Bitcoin is more of ash rather than a battery in this analogy.
I like bitcoin (the idea, not the burning of the planet, even though it's only a temporary hack to bootstrap the whole thing). And hey, maybe it will encourage building nuclear mining farms, that will give their owners free bitcoin, and then we can use the nuclear plants.
The only defense I can stomach for Bitcoin's unfathomable energy consumption is that it might be only temporary. Is it worth it? So far, not that much, but I think developed-countries under-estimate the value of bitcoin, since they have more stable economies, and thus currencies, and enjoy freedom of moving their money, and data privacy...
Find the empty string and replace with say
where refers to the captured variable, and with input the result is With an empty input, the result is The result of indexOf can consistently return the first index of the first half open subrange in a string. It just so happens that the first subrange of an empty string in an empty string is [0, 0).The limiting case is also an interesting way to look at it: