czrnb

I think that in order to not break your flow, you should be able to translate your thoughts (the answer you found) to code or text as fast as possible. Typing slowly when you know what you want to write can be frustrating for one (lowering your motivation), but most importantly is too trivial a task to prevent you from thinking at the same time (and thus parasitic thoughts can break your flow). A HCI that can help you write your code as you think of it (and maybe log the thought process for future reference !) would be awesome on that front.

I think GP meant it's not shorthand for automatic

Thanks for the link!

I don't think it applies in this case however. There is no explicit cognitive bias at play. There would be if he considered his job is as good or better than plumber's (although actually, unless he has a very particular toilet setup, doing a good job after meticulous research and preparation is not out of reach at all).

In any case, even doing an OK job which is definitely worse than a plumber's but holds (and will presumably hold) is still a win if you're short on money but can spare the time/motivation.

You beat me, I skipped to yours :)

But can you easily differentiate between something which is pushed by the wall and something heavy that is on the shelf ?

Also granted you can, my instinctive reaction, the instinctive reaction is IMO try to get out, not push against the wall.

Seems to me it's not such a simple problem to solve unless you are ok with (i) some level of discomfort (ii) getting pets stuck inside and traumatised for life (granted the device does stop it's movement before crushing it).

While I mostly agree with your comment, I would like to point out that a company may have a lifespan much greater than that of a skilled worksman (which may or may not have transferred his "specific" knowledge to any co-worker and/or apprentice). A company, simply because of the stream of new people that will have to be trained, need to have that knowledge passed down at some point, and having it laid down in writing or any non perishable medium is the safest way to do so.

I'd like to add a little context around the quote [0], because I do think it makes another issue very apparent:

> Building a dam requires knowledge and skill developed through years of experience. Obayashi's automated system is expected to be a game-changer in dam construction, as well as in other applications.

> "By transferring expert techniques to machines, we're able to analyze what was once implicit knowledge," said Akira Naito, head of Obayashi's dam technology unit.

> Every process for constructing the 334-meter-wide dam will involve some form of automation. That includes the initial work of establishing the foundation, and pouring concrete to form the body.

Implicit knowledge here refers to dam builders' workmanship and experience. It is an empirically constructed knowledge which is "stored" in the worksman's mind as instincts, concepts, know-how... While these may "be analyzed" and re-used for automation purposes, I have very strong doubts whether such implicit knowledge may even be truly understood and translated (be it in code or any other media) if there is such a precise goal. Specifically because the knowledge is implicit and applies situationally, one may never be able to grasp it all without some kind of very complex knowledge transfer set-up that could cover a broad range of situations, allowing all of the patterns to emerge and be identified.

Enough knowledge may be gathered that a company could successfully apply it to dam building by machines. But as automation replaces dam builders, chances are that the portion of the extracted knowledge which is not necessary to the company will join the expertise which did not transfer from the workmans' minds to the company to lay forever in the land of lost knowledge (...until it is found again through experience).

The rest will most likely be preserved "forever" through more or less obscure patents and "hard", explicit knowledge in the company's hands.

[0] https://asia.nikkei.com/Business/Engineering-Construction/Da...

There is an error in the (pixelated) example that is given int the MIT tech review article (z² = 3 instead of -3). I think the fact that the author of the news missed this, that he probably took a screenshot of the formulas rewritten in Word, and that he was compelled to write such a long article on such a simple topic speaks for his level on the topic.

The fact that he only lists the formal article as a reference instead of the announcement, video, and accessible blog post by Po-Shen Loh really baffles me.

The original "disclosure" by Po-Shen Loh [0] is much less sensational and gives some context for his work (teaching middle school students). In the formal article, he is also stating that the method is very likely not __new__, but that he wants to popularize it in teaching.

I think, as many other commenters pointed out, that there is no great breakthrough here. However "his" method may have the advantage of training the intuition of young students, by helping them understand the concepts of average and "deviation" (I'm not really sure how to call it in that case), and maybe visualizing them.

[0]: https://www.poshenloh.com/quadratic

By the article's definition, yes, it would be a data race. With this example, I just wanted to make it more explicit to you what a data race without a race condition could look like.

Truly I'm still not sure why the author had to make a point and write a blog post about the conceptual difference between data races and race conditions.

> I'd say data races are race conditions, but not all race conditions are data races.

In practice, I think you are almost right. There are some cases which exhibit data races, while being free of race conditions, but I think the linked post overstates the importance of differentiating between data races leading to and free of race conditions.

> That's really multiple operations > [...] > if you deconstruct the actual operations performed by a single line of code as I did here

It is not a given that the increment operation is to be divided into individual operations.

All of this is very dependent on the language (interpreted vs compiled (and how it's compiled)), how the concurrency is implemented (managed by the kernel vs software threads), as well as the ordering model of the hardware (whether the processor takes the liberty of reordering instructions).

The data races you describe lead to a race condition under the assumption that `a` or a derivative is used in some conditional branching later on. Arguably, this is always the case, otherwise, there would be no point in having this variable in the first place. But this is just one example.

Now for an example of a data race without race conditions which, IMO, is a bit more explicit than the one from the linked post. Imagine the following: we want each of our threads to write a timestamp of its execution into a shared variable, in order to know when the last thread was executed. This situation contains a data race by definition, as we do not know which thread will write its value into the shared variable. However, both values are similar enough for our monitoring needs (e.g. correct), and do not lead to race conditions.