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.
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.
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.
I wasn't saying that all Sudoku's can be solved without back-tracking, I was just commenting about that its bad design to only guessing and back-tracking while there are other methods for finding a solution much faster. It is nice to note some improvements that could be made to the program, but missing the fact that a very poor performing algorithm is being used, is much worse. It is like correcting spelling mistakes in a mathematical proof while missing the fact that it has a logical error.
Most Sudoku's can be solved without back-tracking. There is a rather trivial mapping of Sudoku's to Exact Cover problems (see: Hardest Sudoku). Good solvers, only use back-tracking when needed, and try to apply logic reduction first. When there is a column were A implies B, all rows in which B is true and A false can be eliminated, because a selection of such a row will leave the A column empty. Most of the published Sudoku's can be solved with using this simple reduction rule.
I wonder if the the opportunity rover project will get an extra extension now, or that this very succesfull rover will be left alone, while still being functional.
Here in Europe radars remain essential because of Russian planes (both fighters and nuclear bombers) are flying around with their ADS-B switched of, just to test how quick European forces respond to possible treats. These planes fly in international air space, but often at close range of commercial flights. European countries are quite angry about this behavior, but the Russians think that they do nothing wrong. Just waiting for the first mid-air collision to happen. About a decade ago, the Russians started with these flights again, which they did during the Cold War. Especially, the last year they are become bolder and bolder, trying to enter national air space over and over again, and flying at supersonic speeds.
We only used branches for very long running project or after a release. All other work was simply done in our development branch. Keeping you changes local for a long time is no problem. I used to use update many times a day, always keeping up-to-date with the latest check-ins on the development branch and occasionally having to resolve a merge conflict. For really long running projects, I would create a patch at the end of the day and store it on a file server for back-up. Transfering changes from one branch (development) to another branch (for a bug-fix release) can simply be implemented by creating patches and apply these to the given branch. Which is not really much complicated than all the commands that you have to use in Git for some operations.
I am not denying that Git is more powerful than Subversion, but to me it seems much less user-unfriendly and less robust agains commonly made mistakes. I feel Git makes me think much more about what I have done, and is less forgiving for small mistakes, in that sense it often feels like a burden than a support.
And why then does it say in all kind of manuals that you should not use rebash unless you know what you are doing!
After using Git for about a year now, my conclusion is that subversion is good enough for your team, and heaven compared to Git. With subversion you can just peform an update without having to wonder if you might have something that still needs to be commited. I am also not convinced that creating branches and merging all the time is realy a good way of working for the team we are working in. I am getting used to stash, pull, stash pop, and resolve possible merge conflicts, and only commit and push when I am done with my changes. Yes, that sounds very much like working with Git in a subversion manner, but it seems to be the most productive way of working for us.
In fact in Chinese many words (characters) are pronounced in the same way and same tone, just like there are words in English that are pronounced in the same way, but written differently. Which meaning is intended is usually clear from the context. Tones often differ between dialect, and usually this is not a problem, not any more when English speakers from different dialects speak with each other. Furthermore, tones are restricted to the vowels, not to the sentences, as otherwise it would not be possible to sing in Chinese. The use of tones do not restrict you with respect to expressing emotions and there are just as many ways of saying hello in Chinese than there are in English.
I do not know whether Wikipedia counts as a reliable source, but it gives the same number: Chinese language and Languages of China. I also would not count Cantonees as a dialect of Mandrin. Cantonese has nine tones, where as Mandrin has only four, and most words are pronounced differently.
Some minorities are allowed to use their own language. I have been to a large city were many signs were written with Arabic characters.
In China, highschool is divided into junior secondary school and senior secondary school, both being three years. Only junior secondary school is compulsory. So, not all Chinese do attend highschool in the sense that they attend both junior and senior secondary school. In 2010 the percentage was 82.5. One should note that these percentages have increased strongly in the past two decades. To enter most higher education institutions it is not sufficient to finish senior secondary school, but one has to pass a state exam as well. I am aware that Chinese are obesessed with education, but it is also a fact that many Chinese still live in rural areas, where the quality of education is not always very high.
Fact is that most Chinese do not speak English, as I have experienced first hand. In fact 30% of the Chinese do not have Mandrin (including local dialects) as their first language: see this list of languages spoken in China. English is now taught at highschool, but not all Chinese do attend highschool. I have noticed that they are usually beter at reading the language than speaking it. I have met Chinese who published scientific papers in English, but could not keep a normal conversation.
Slashdot Mirror
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.
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.
I wasn't saying that all Sudoku's can be solved without back-tracking, I was just commenting about that its bad design to only guessing and back-tracking while there are other methods for finding a solution much faster. It is nice to note some improvements that could be made to the program, but missing the fact that a very poor performing algorithm is being used, is much worse. It is like correcting spelling mistakes in a mathematical proof while missing the fact that it has a logical error.
I have read stories that NASA considers to shutdown this rover mission due to budget cuts and priorities.
Most Sudoku's can be solved without back-tracking. There is a rather trivial mapping of Sudoku's to Exact Cover problems (see: Hardest Sudoku). Good solvers, only use back-tracking when needed, and try to apply logic reduction first. When there is a column were A implies B, all rows in which B is true and A false can be eliminated, because a selection of such a row will leave the A column empty. Most of the published Sudoku's can be solved with using this simple reduction rule.
I wonder if the the opportunity rover project will get an extra extension now, or that this very succesfull rover will be left alone, while still being functional.
Here in Europe radars remain essential because of Russian planes (both fighters and nuclear bombers) are flying around with their ADS-B switched of, just to test how quick European forces respond to possible treats. These planes fly in international air space, but often at close range of commercial flights. European countries are quite angry about this behavior, but the Russians think that they do nothing wrong. Just waiting for the first mid-air collision to happen. About a decade ago, the Russians started with these flights again, which they did during the Cold War. Especially, the last year they are become bolder and bolder, trying to enter national air space over and over again, and flying at supersonic speeds.
I am not denying that Git is more powerful than Subversion, but to me it seems much less user-unfriendly and less robust agains commonly made mistakes. I feel Git makes me think much more about what I have done, and is less forgiving for small mistakes, in that sense it often feels like a burden than a support.
After using Git for about a year now, my conclusion is that subversion is good enough for your team, and heaven compared to Git. With subversion you can just peform an update without having to wonder if you might have something that still needs to be commited. I am also not convinced that creating branches and merging all the time is realy a good way of working for the team we are working in. I am getting used to stash, pull, stash pop, and resolve possible merge conflicts, and only commit and push when I am done with my changes. Yes, that sounds very much like working with Git in a subversion manner, but it seems to be the most productive way of working for us.
In fact in Chinese many words (characters) are pronounced in the same way and same tone, just like there are words in English that are pronounced in the same way, but written differently. Which meaning is intended is usually clear from the context. Tones often differ between dialect, and usually this is not a problem, not any more when English speakers from different dialects speak with each other. Furthermore, tones are restricted to the vowels, not to the sentences, as otherwise it would not be possible to sing in Chinese. The use of tones do not restrict you with respect to expressing emotions and there are just as many ways of saying hello in Chinese than there are in English.
Some minorities are allowed to use their own language. I have been to a large city were many signs were written with Arabic characters.
In China, highschool is divided into junior secondary school and senior secondary school, both being three years. Only junior secondary school is compulsory. So, not all Chinese do attend highschool in the sense that they attend both junior and senior secondary school. In 2010 the percentage was 82.5. One should note that these percentages have increased strongly in the past two decades. To enter most higher education institutions it is not sufficient to finish senior secondary school, but one has to pass a state exam as well. I am aware that Chinese are obesessed with education, but it is also a fact that many Chinese still live in rural areas, where the quality of education is not always very high.
Fact is that most Chinese do not speak English, as I have experienced first hand. In fact 30% of the Chinese do not have Mandrin (including local dialects) as their first language: see this list of languages spoken in China. English is now taught at highschool, but not all Chinese do attend highschool. I have noticed that they are usually beter at reading the language than speaking it. I have met Chinese who published scientific papers in English, but could not keep a normal conversation.