Buffer overruns would not be as dangerous as they are, if stacks would not grow downwards, but upwards. Only because they grow downwards, they can be exploited to overwrite the return address on the stack in such a way that a system call is made.

How an intern hacked the powergrid (SHA2017)

I guess you are confusing it with the movie The Martian, where some left behind scientist starts growing potatoes. This movie wat totally unrealistic. Yes, there are strong winds at Mars, but because the air is so thin, the won't blow down rockets. And that is just one of the silly things in the movie.

I quite enjoyed watching the movie, but left with a feeling that I had to see it at least another three times to fully comprehend it. It has some interesting plot twists and some iconic scenes. It answers some questions, while are left unanswered. At least the movie is good, because it does not have one main character and that we see the struggles of several characters and going through some development to add to the story. It also leads to some dramatic choices being made. In a sense this may make the movie look quite chaotic, but in a sense it might be most emotional dramatic movie of all the movies that have been made so far. Maybe even the most convincing if you give it time to sink in.

At the company where I work, we review each other code changes. If you are using Jira (or similar bug tracking system) it easy to introduce a review step. If you use a code management system (and you should) you can do development in branches and have the reviewer (who preferable also performs a test by checking if the scenario mentioned in the bug report now works correctly) merges the branch to development if no problems are found. Otherwise the issue is reverted to open. Code review is a very powerful technique for finding bugs. It also helps understanding the code base, because developers tend to be drawn to certain parts of the code, often to the point that they are considered the owners. Code reviewing code written by others also helps you get better at developing software, because often you will find solutions that you had not thought about yourself. And because you review each others code, the learning goes in both directions. I sometimes spend more time on reviewing code than the fixer spend on solving the issue. Often I walk over to the developer to ask some questions, why he or she has chosen a certain solution. Sometimes, they give a good answers, sometimes it leads to a short discussion, and it even happens that the developer him/herself realizes that there is another case that will go wrong as well, and that the bug needs to solved in a different way. If you are using Scrum or similar development methods with short cycles/sprints, make code review part of your definition of done, meaning that an issue is not demonstrated as fixed (or included in a release) if it has not been code reviewed.

It is indeed true that one neural network was trained using a collection of games, but the version of AlphaGo that played against Lee Sedol last year, was using two neural networks, and the second one (for evaluating the positional strength of a board configuration) was trained by letting AlphaGo play against itself. It is not known how he current version of AlphaGo works, whether any additional neural networks were added, but if it has become stronger, it has done so by playing against itself. It should be noted that this latest version of AlphaGo was playing some surprising moves that made some people believe, it could not have been AlphaGo, or that it was a version that was trained without using a collection of games. It should be noted that DeepMind announced it wanted to experiment with training a neural network with zero additional knowledge for the game of go, just like they did with the neural networks playing old video games.

You seemed have to missed the fact that many of the top professional players were lining up to play against this bot. They view it as free training lession, not to beat an AI bot, but to beat their human counter parts. Since Lee Sedol played against AlphaGo, he has gained in strength, so much even that a certain point, using a certain method, AlphaGo was the strongest player, not because it had played more games, but because Lee Sedol had won so many games. Ke Jie, to be considered the strongest player at the moment, has made remarks that humans have only touched at the truth behind go, after he played against Master(P). Most go players have a very high regard for the game, as they sense that it is much deeper than human mind can consider. For this reason, I guess, many professional go players find this a very exicting time, because it will enhance their understanding of the game. In this view it is very unlikely that a professional player will use a trick to force a tie.

I would let LISP print out a s-expression representing the abstract syntax tree (usually called abstract parse tree). Next I would add a small piece of code to my IParse program to read s-expression and use the unparse abilities with the C grammar to produce nicely formatted C code. The unparse function is smart enough to output a S-expression like '(times (add 3 4) 5) into (3+4)*5 based on the given grammar rules fed to IParse. Feel free to contact me, if you want any help with using IParse.

I once discovered that an interpretting parser was faster than a compiled version of it. Probably because the compiled version became so large that it was larger than the CPU caches, causing lots of reads from memory, while the interpretter did not. It is often the case that interpretting is fast enough and that there is no need for compiling (to machine code or virtual machine).

The LoRa network has some measurements against these kind of attacks. I built a LoRa node myself (to connect to the free network owned by TheThingsNetwork.org with only limited coverage, see ttnmapper.org) and had to generate two private/public keys, one for the wireless connection and one for the application, meaning that the transmitted information is encrypted. There is also frame counting implemented. The maximum rate on this free network is limited to about 80 bytes per hour. Maybe the commercial network has a slightly higher rate and is bi-directional. The railway station of Utrecht has connections in five directions and is know to cause massive delays in the very tightly scedule rail network in the Nethelands due to (for example) frozen rail switches. So, I guess they are only using it to signal these kind of things. Not something as vital as the position of the switch.

I learned Algol 60, FORTRAN, and Lisp while still in high school. Writing programs out on paper before traveling to a near by city by train to make punch cards and run the programs, often going home with s stack of listings to study the results. Only in second year of university did I learn something truely new: currying and lazy evaluation. More details.

Did not know that s-wave propegate with the speed of light.

I felt that both the commentaries on the official stream and the one of AYA with Kim Myungwan were mostly focusing on analysing alternatives to moves that were already played, instead of focusing on possible moves to be played. At one point Haijin Lee, also known as Haylee, the current secretary of the International Go Federation, took a seat behind the computer. While Lee Sedol was taking a long time to think about the 78 move, she suggested the "wedge" move to Kim Myungwan. He first asked with some surpise: "This one?", and after she confirmed he exclaimed: "O, that is very creative". They analyzed the various possibilities to take benefit of the move, but did not see how it could work. Haijin at one time remarked, "It has to work", indeed because otherwise the game would be a loss. Then with still 6:16 on the clock, Lee Sedol played the proposed "wedge" move at L11. Then Haylee has to go. Then AlphaGo plays the move that Kim Myungwan just played as a possible continuation. Soon it is acknowledged that it is a mistake and that the chances for Lee Sedol have turned. The "wedge" move is later recognized as the genius move with which Lee Sedol defeats AlphaGo. Demis Hassabis tweeted Mistake was on move 79, but #AlphaGo only came to that realisation on around move 87 and When I say 'thought' and 'realisation' I just mean the output of #AlphaGo value net. It was around 70% at move 79 and then dived on move 87. The question remains if there is another move that AlphaGo could have played to prevent Lee Sedol from winning. If this is not the case, then move 78 is simply an over play that tricked AlphaGo.

It seems that AlphaGo suffers from the horizon effect, meaning that when it is ahead, it becomes blind for wining sequence that starts with an unusual move. It is great that Lee Sedol has won this game, because it shows that humans still have a better understanding of the game. Relying on a mental vocabular for reasoning about the game, has some weaknesses, it might still prove superior when reasoning about very complex situations like the one encountered in this game. It seems that Lee Sedol took most time to think about this move. Later on in the game, AlphaGo, played some bad moves, probably because its winning percentage had dropped.

A product with these specifications seems to be already available on the market: MTi-G by Xsens. The technical specifications talk of a resolution of 2.5 cm, which is about an inch. It uses the kind of sensor fusion algorithms described in the article. Xsens is a Fairchild Semiconductor company, an industry icon delivering power solutions for the mobile, industrial, cloud, automotive, lighting, and computing industries. Xsens has offices in Enschede, the Netherlands and Los Angeles, California.

It seems that if there is one thing our intuirion is often wrong about, then it is on the issue of performance. It might well be that in the case of sudoku's a back-tracking algorithm might be faster than any smarter algorithm.