That Niko's text-arrow lifetime annotations are so helpful here suggests a rust IDE could offer similar highlighting or annotations to explain borrow checker errors.
One of the ergonomic hurdles to rust adoption by experienced C++ users is that the language looks similar enough that such people may think they fully understand the semantics even before they've fully internalized all the details. It's a tricky zone when something feels familiar enough that you don't realize the remaining mistakes in your conceptualization.
You are not alone. If you look at the "target retirement date" funds Vanguard etc. run you'll see that by the time the target date is 5-10 years out they have shifted largely to bonds to provide defined income.
Anything with low-effort access will always connote little value in people's minds because endless alternatives exist. Anyone who wants to get paid for doing something hard should avoid channels like that, or only use them to float associated freebie products that can introduce people to the real product.
> If you could point me to a single bank president who says
Why do you think they would say what their true goals are to you? People in positions of power are extremely judicious and strategic about what they say and to whom. They get daily exercise in this and only the best survive. The most effective are excellent at pursuing their goals while maintaining a socially credible exterior. The less effective use coded language (corpspeak or political rhetoric) to try to hedge through via indirection.
Neat stuff. It's worth noting that shadow rays don't entirely avoid precision issues either. You still need to handle self-intersections. One option is to add a bias epsilon (which introduces other artifacts, depending on the scale); another is to reject local self-shadowing (which means you can't get finely shadowed surface cracks); another is to give artists explicit control over which sets of objects shadow which others (which adds artist time). Offline rendered movies use all of these.
A suggestion. Your comment reads as though you wrote your own press release to then take issue with. Mis-quoting them with hyperbole for emphasis is less persuasive than directly addressing what they actually wrote.
Makes sense. I didn't realize the problem description was for a game that would be played repeatedly with the same opponent -- i.e. one where you can gather information. If we were doing this in person instead of on a internet forum and async post/response we'd probably iron that out quickly. Thanks for elaborating.
Ok, I'm stumped. If I've parsed your description correctly, we get no info about our opponent's actions or the results until the end. Absent any ability to observe their strategy, it seems like you do want to maximize for expected value of your own actions, and I'm curious about the counterexample.
How do we maximize EV? A single throw's pdf is 1, for x in [0,1], so its EV is 0.5. The question is how to improve on a single throw by deciding to re-throw. A re-throw is independent and gives the same EV. We want a strategy that gives us higher cumulative EV. Say our strategy is that we have a threshold A, where we re-throw any result below A. Because x is uniform, the probability that we re-throw is also A. The cumulative EV of the strategy is A * EV(second_throw) + (1-A) * EV(keep_first_throw). Since we only keep the first throw for results in [A,1], the EV for that event (integrating x * pdf from A to 1) is (1+A)/2. So EV of the whole strategy is A/2 + (1-A) * (1+A)/2. It has max EV when A is 0.5, giving EV of 5/8.
It feels pretty grand to consider the prospect of no longer having to debug crashes due to expired QTreeViewItem pointers, or spending time counseling junior team members to check for expired weak pointers.
Qt is excellent for its epoch, but if you've read the source you will know that we should not treat it as sacrosanct. Algebraic types and explicit lifetime declarations and macro syntax extensions could all do wonders for it.
Agreed. I'd also make an analogy to C++ where you sometimes must hop between std::string and char*'s with ambiguous lifetimes. Not to mention various custom string types that any big app will have (ex. one that internally exploits jemalloc's allocator optimizations (i.e. exposing block overages), or does rope-style allocation, or intern's into a shared table, or whatever).
The history of gamedev (in particular) eschewing C++ for years until the consensus flipped gives me hope that something similar might happen here. The strings thing may take a similar path to so many aspects of C++ -- where it took years of folks like Scott Meyers and Josuttis and Herb Sutter and Alexandrescu talking through the details and rationale before enough people grew to like the decisions C++ made. Think of how many C++ programmers had to get their head around (say) RAII -- it probably first seemed horribly odd and weird, and now it's seen as a fundamental reason why it's a great language.
Agreed -- I've found these pearls of received wisdom often crumble on non-trivial projects. "Premature optimization" can lead some to defer thinking about performance at all. "Profile and fix the hotspots" without simultaneously thinking about architecture can yield a mass of uniformly slow branchy code with no path forward. It's hard to appreciate until you've been there. However, I do have faith that mozilla folks have most certainly been there and that those lessons inform the rust design.
Your observation reminded me of the Million Short search engine that skips past the first N ranked hits.
Is there a name for the phenomenon that the first entries in any contested ranking tend to be less interesting?
There's something about the ranking systems used on the web in the way they tally the nearly-effort-free actions of hordes (clicks, likes, upvotes, star ratings) that means they represent one kind of magnitude (statistical average impulse behavior) but very little of another (deeper reflection & significance). Deeper stuff tends to see less impulse attention and therefore sinks down the ranking, but is there some other way to identify it?
Isn't that what an option represents? The freedom to choose later is the inherent value of the option.
And that value isn't acquired risk free: it's compensation for putting time in in lieu of salary.