And yet a lot of speakers still seem to need that self-evidently true statement pointed out to them. Tautological advice isn't necessarily bad or useless, especially for beginners.
> Ever try or even see a "Leet-Code" style question that stated the problem without providing example results?
This style of question asks the examinee to devise a procedure for producing those results, not to come up with the individual results themselves. If a student is given a bunch of systems of linear equations to solve, an answer key isn't especially useful since checking a candidate solution is pretty straightforward.
We could be extremely, reductively classical about it and say that all of Nerdle's answers point to the same place (⊤, since any answer equivalent to ⊥ is disallowed by the rules), but the real answer is that Nerdle—like Wordle—is simply about finding the right piece of syntax, not finding the right semantics.
> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing.
Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup, or something similar that effectively has `object` carrying around its own particular implementation of `f` (which might have been closed over some hidden internal state as well), and I'd expect `f(object)` to not do anything of the sort.
> In Pandas, you sometimes have a function with the same name as a method, which behave subtly different from each other.
This sounds more like a poorly designed library than any language-level awkwardness.
> Python's OOP is awkward with object.f() meaning something different from f(object), when really they ought to mean the same thing.
>> Why should they? Coming from other OO languages, I would expect `object.f()` to involve a vtable lookup
Low level details like that should not concern me. In which case, maybe `f(object)` should do a vtable lookup then; why not? The syntax `object.f()` and `f(object)` should be interchangeable in all situations.
> This sounds more like a poorly designed library than any language-level awkwardness.
Languages ought to disallow these things. E.g. I'm constantly baffled that many languages won't let you use symbols as normal method names, but are absolutely fine with you having two methods whose names differ only in case. (There's even academic research showing that case sensitivity is the biggest pitfall for beginners learning Python).
> Figure 2 shows plots of overnight and intraday returns for twenty-one major stock market indices around the world. Turn the page and compare Figure 1 with Figure 2. See if you can tell a difference.
These images... do not render well on my machine, to put it lightly. So they look remarkably similar to me. Perhaps the author could spell out what this difference is? There is eventually mention of "striking similarity in the overnight and in- traday return patterns in the indices around the globe," but I don't think I'm ready to conclude that strong correlation of phenomena across markets in a global economy must be caused by a collection of manipulators acting on all of those markets.
I'm curious to see what others have to say, since I lack the hardware and background to properly read this document.
The issue is about which edges are in the same plane as which other edges. If this is a polyhedron, AD and BE must be coplanar, and BE and CF must be coplanar. Extending the edges into lines, they don't form a 3-way intersection. G gets projected to the same screen point as some point on line AD, but the only way G can be on line AD is if AD and FC are coplanar. If all three of AD, BE, and FC are coplanar, the entire figure is a flat pentagon (and DE, BE, and FE are not edges).
If G isn't on line AD, then BE and CF can't be a side of the same truncated pyramid.
