As far as I can tell: yes.
The top z-layer of designated stairs will always become pure down, the bottom layer pure up.
But I think you can get around that by designating one more z-level than you need, and then removing that. Blueprint mode or designation priorities might also work.
Tell you what, I am going to try now, will post my results shortly.
Edit: Yes this works. After finishing the designation, it will change to the corresponding stair type. By doing one more z-level, you move the "down/up only" layer there, and can remove it. The designations in the level below will not change as a result.
For anyone wondering: Yes, this is still an improvement over the old way of doing it.
I want to point out that none of your points are an actual indicator of how good someone is at programming.
They are important in the context of a job, especially in a team, but not for actual coding.
So its really two different things we are talking about here.
Good point. The points I made apply more to Software Engineering. I should have clarified "good programmer to work with". But as you say, this is in the context of a job. There are no managers in amateur/hobby programming.
Most likely, yes.
Combined indexes are real cool, because if the database can satisfy a join only from the index, it can usually perform it completely in memory, instead of having to do a table scan/hitting the disk for the values.
Another trick people usually shy away from: temporary tables.
It might seem slow and wasteful to create a table (plus indices) just to store results for a fraction of a second, but for very large tables with large indices, creating a smaller index from the baseteable and joining against that can be magnitudes faster!
There is even dedicated syntax for that: CREATE TEMPORARY TABLE. They are local to the connection and will get dropped automatically at the end of the sql session.
They are also great for storing the results of (nondependent) subqueries, because for large sets, not every database is able to find the proper optimizations. Mysql versions < 8 for example.
I really recommend you to try that one. So far I could fix every "query takes too long" problem that resisted other solutions that way.
There is also Linux Mint XFCE. I prefer this because *ubuntu isn't focused on the desktop any more and Mint is. Also, Snaps are annoying and he repo is controlled by Canonical. Mint doesn't have Snaps unless you want them.
One big difference: GOTO ist not bound to any scope. Which ist no wonder, its usually just syntactic sugar for an omnipresent assembly instruction: JMP.
Algebraic effects are less general and play nicer with scoped constructs like finalizers and exceptions. The downside is that they work via stack unwindindig, so they incur some performace penalties.
I highly recommend reading the original article - "Algebraic Effects for the Rest of Us". It demonstrates their operation via Javascript by renaming try/catch, and I think it will answer your questions nicely.
I know that, and I did read that article. I wasn't criticising algebraic effects, I suggested it may indeed have something on the mere "power" of constructs that can implement the same flow.
That said, the article didn't make me much wiser on what's the point. I could sort of see it if it came with guarantees in the type system, I guess.
Yeah thats fair I guess, it IS hard to see whats so special about it.
Imho, it's the same deal as with monads: Outside of pure functional languages with a strong type system there is not much appeal. But for e.g. a Haskell programmer its like the next coming of christ...
But I think it could be very useful if combined with the equivalent of javas checked exceptions, even in other languages.
Hah, when I wrote that I was thinking of qualifying it a bit better to prevent the very obvious objections.
It really depends on the language
and what kind of goto you mean.
But in the context of the post I replied to, yes, because you cannot replace algebraic effects with "neutered" gotos (like the ones in c), you need the equivalent of longjmp, or maybe gosub.
You can obviously design a language where goto does implicitely run finalizers or does similar fancy stuff, but this is again leaving the scope of the original discussion I think...
Goto tags and blocks/return-from have lexical scope and dynamic extent. Lexical scope means that one can goto to enclosing goto tags and one can return from enclosing blocks. "dynamic extent" means that corresponding scoping constructs tagbody and block not have been exited yet.
CATCH/THROW has dynamic scope and dynamic extent. Means that the CATCH targets will be looked up on the stack.
Then Common Lisp has UNWIND-PROTECT, which sets up a dynamic scope. When leaving this scope by a non-local control transfer, it is ensured that some specified code will be executed.
These are then building blocks for higher-level control, like the Condition System, which provides condition types, handlers, restarts, ... which is used then for error handling, where on error the stack is left like it is.
> Assembly lets you jump anywhere
it's just that jumping to some arbitrary place might not make sense.
setjmp/longjmp (aka goto on steroid) is a better example. Algebraic effects are sort of a structured (and, depending on the language, typed) form of sjlj.
Probably by learning how humans have to balance their extremities to remain standing upright. The camera angle with respect to the enviroment is likely a factor too, since errors got larger when outdoors.
Errors are also not exactly small, ~6cm average, although it's more like 1-2 or 5-12, depending on body part. I think this would very likely be noticeable in VR applications, but it is still very impressive accuracy overall.
The question also nicely highlights the disadvantages of trained algorithms: No one knows for sure, and it certainly isn't obvious by looking at the network weights...
On the other hand, when looking at the pictures, I felt like the authors: There should be enough information in there to get at least a good estimate. And it is extremely useful that one can nowadays "just" train a model to confirm such theories.
Has the result been reproduced? I could quite easily move my forearm to several distinct positions not visible from that view that would have no impact on the rest of my posture. I feel like there's a lot of ML out there making big claims and not distributing the models for verification.
Cyberpunk 2077 at least pushed the rendering part of the engine into next-gen territory: Volumetric lightning and fog almost everywhere, environment reflection on even the smallest water surface and monochromatic light actually turns many surfaces into mirrors. All that in an outdoors setting with a ton of assets and an almost impracticle amount of verticality (no naturally empty half of the Screen).
Before that release, most game devs would have told you that this is still impossible on todays hardware.
But that engine also shows that you are not wrong with your remark about consoles holding progress back: The game barely ran on the ps4, and even on the ps5 you won't get stellar framerates... You need a really nice PC to run the thing smoothely...
I think I get why this might be the most effective:
When I look at that, my mind completes it to a stick figure, like an optical illusion. At least to me, that one is immediately recognizable as a human.
I think it is worth pointing out that Chess.com did sign a contract to buy the Play Magnus Group last month.
I dunno what to make of that, but this whole thing could have been handled a bit more professional...
Yes! The game itself supports [PRINT_MODE:TEXT] in the ini. Depending on the version you might need a virtual x server to trick the game into starting though.
Used that to run it via wine + quemu on my android phone, at a whopping 5fps at embark. Didn't play for long, but was totally worth it!
But I think you can get around that by designating one more z-level than you need, and then removing that. Blueprint mode or designation priorities might also work.
Tell you what, I am going to try now, will post my results shortly.
Edit: Yes this works. After finishing the designation, it will change to the corresponding stair type. By doing one more z-level, you move the "down/up only" layer there, and can remove it. The designations in the level below will not change as a result.
For anyone wondering: Yes, this is still an improvement over the old way of doing it.