When telling a story through film, changing what depth is in focus is a great way to move the viewer’s attention, without the need for cutting to a different angle or camera movement.
Sure. But most shots have a deep depth of field or just follow one person. Even when autofocus isn’t needed, you can just turn it off. It’s just kinda weird that they don’t include the feature at all.
Off topic: The very first assignment in this game is called “oil tank holiday”: fly the chopper to unguarded oil tanks, shoot and watch them burn, and then fly home. No enemies. Just learn to fly and shoot.
I apply this in testing code. After you write some code, try to think of the absolute minimal test to prove that your code does anything at all without crashing. These are my “oil tank holiday” tests. It is always humbling to see those fail.
You know, if can change code without overhead to ends of the pipeline, using the language & library of my choice, I’d do this too. For many of us this isn’t always the case.
It’s faster for 3 digits and more. 3 digits is not galactic scale. Otoh, if over half of your numbers are single digits, it will lose to other implementations. I think that is more often the case that we’d like it to be.
What you can do in C# today is convert any unsafe pointer to Span whenever you get your hands on it, and pass around slices. You can still drop down to ‘fixed’ when it turns out you need it for performance.
I could say that the perf difference between spans and unsafe pointers in most cases is just zero, if not in favor of spans at times due to the optimized helper methods or just better code generation. Add the safety benefits to the mix, and it's a no brainer. So, unsafe pointers may not have an edge for performance anymore. They might have other uses cases of course: interop, etc.
With fixed you do pinning on GC memory, which can have a negative performance effect. You can also do unchecked pointer arithmetics on references with the Unsafe class, which avoids that. A lot of the methods of Span use that internally.
The way I understood the 80% is that is the margin on the actual product. 36% is what remains after the “investments” in moonshot projects nobody asked for.
I’ve learned this lesson over the years. It is quite common that users make a screenshot of the error with their phone, and send it on to support with hardly any details. The fact that errors become recognizably different is also an improvement: the user and support staffer can recognize recurring errors, and notice patterns.
reply