Google's Deepmind AI ALPHAGO Hands Historic Second Consecutive Loss to World Champion Go Player

[Doobeedoo]

8 minutes ago, Roawoao said:

http://spectrum.ieee.org/automaton/robotics/artificial-intelligence/custom-ai-programs-take-on-top-ranked-humans-in-starcraft

 

They lost. But as I've been saying but the other guy keeps brushing off why not apply DNNs to more complex game applications and less boring games. One other key concept is not to make the best AI either just make realistic AIs that can make games more immersive in general. 

Yeah, I've read about it. AI is learning and preparing it self

[Roawoao]

9 minutes ago, Doobeedoo said:

Yeah, I've read about it. AI is learning and preparing it self

AI self programming is also something that is a bit lacking. With DNNs they are extremely specific in what training data they can learn from and without a team of programmers it is very unlikely to stay the best Go playing AI for long. If another expert programming team had a few days they could find a whole laundry list of bugs and win in a game of Go very quickly using said discovered bugs. Think of it this way if they fired all the developers and never patched the AlphaGo AI it would lose short notice especially if its source code and training data were publicly accessible. 

 

One of the biggest problems is that these are all super simple games for the computer to understand (winning it is hard obviously but isn't exactly an unexpected development if you have been following the progress) and designing an AI for games where there is no winning condition or even clear goal is a far better goal and much more likely to produce fun developments in modern games that tons of people play.

[Curufinwe_wins]

33 minutes ago, Roawoao said:

Which ideas? You don't have anything to go on and it shows in your post. 

Do you actually want me to go into full bore detailed explanation as to your mistake in this matter?

 

Because if you knew anything about Monte Carlo this issue would be blatantly obvious to you before we even begin... After this explanation, to which, without a full explanation/explanation of Monte Carlo methods, you will not have the knowledge necessary for me to bother with a second explanation to the inevitable rebuttal.

 

@patrickjp93 Or anyone else with a high level of knowledge in Monte Carlo methods and game theory, this issue is self-evident and I would love to see a short statement (I can think of two one-word explanations as well as a few good single sentence ones) before I go into detail about this.

 

 

Summary:

• The problem as stated is that Roawoao believes due to "inevitable bugs" in the Deep Neural Network (even though there are multiple) would allow any expert programmer with full access to all of AlphaGo's source code and "game database" to take advantage of said code and find a specific game that AlphaGo fails to win (presumably offsite weeks/months before the event) then show up to the event playing the game in the "prerecorded fashion" and winning.
• As I have mentioned, the obvious solution to this issue lies within the Monte Carlo portion of AlphaGo.

 

EDIT:

@Roawoao The secret here is glossed over numerous times in the paper explaining how AlphaGo functions if you care to read it (which you should regardless).

http://www.nature.com/nature/journal/v529/n7587/full/nature16961.html

[Roawoao]

16 minutes ago, Curufinwe_wins said:

Do you actually want me to go into full bore detailed explanation as to your mistake in this matter?

 

Because if you knew anything about Monte Carlo this issue would be blatantly obvious to you before we even begin... After this explanation, to which, without a full explanation/explanation of Monte Carlo methods, you will not have the knowledge necessary for me to bother with a second explanation to the inevitable rebuttal.

 

@patrickjp93 Or anyone else with a high level of knowledge in Monte Carlo methods and game theory, this issue is self-evident and I would love to see a short statement (I can think of two one-word explanations as well as a few good single sentence ones) before I go into detail about this.

 

 

Summary:

• The problem as stated is that Roawoao believes due to "inevitable bugs" in the Deep Neural Network (even though there are multiple) would allow any expert programmer with full access to all of AlphaGo's source code and "game database" to take advantage of said code and find a specific game that AlphaGo fails to win (presumably offsite weeks/months before the event) then show up to the event playing the game in the "prerecorded fashion" and winning.
• As I have mentioned, the obvious solution to this issue lies within the Monte Carlo portion of AlphaGo.

 

EDIT:

@Roawoao The secret here is glossed over numerous times in the paper explaining how AlphaGo functions if you care to read it (which you should regardless).

http://www.nature.com/nature/journal/v529/n7587/full/nature16961.html

You do realize the whole point of finding the bugs is that it doesn't matter what algorithm your using because the bug is where it stops working after that point nothing normal will occur (No more Monte Carlo method) and if you find a really good bug it will literally just crash. This has nothing to do with how it well it works normally just basic computer programming in the inevitability of computer bugs. 

 

It is blatantly obvious that your just ignoring how humans can think out of the box to win. I do not care how advanced or whatever the program is the simple fact is that with access to its source code, database, state you could easily crash the AI when playing it by exploiting unpatched bugs. 

 

The goal is not to win by playing Go but to win at playing computer so that you win by default in playing an odd game of Go.

[Curufinwe_wins]

13 minutes ago, Roawoao said:

You do realize the whole point of finding the bugs is that it doesn't matter what algorithm your using because the bug is where it stops working after that point nothing normal will occur (No more Monte Carlo method) and if you find a really good bug it will literally just crash. This has nothing to do with how it works just basic computer programming in the inevitability of computer bugs. 

 

It is blatantly obvious that your just ignoring how humans can think out of the box to win. I do not care how advanced or whatever the program is the simple fact is that with access to its source code, database, state you could easily crash the AI when playing it by exploiting unpatched bugs. 

 

The goal is not to win by playing Go but to win at playing computer so that you win by default in playing an odd game of Go.

Since this isn't related to the post/explanation I am going to make, your cop-out is this:

 

"WELL UHH... if they fucked up really hard then uhh... you can find the bug that just crashes it instead of it even playing stupid... and uhh if you can find a bug before the Monte Carlo method happens right away (aka before the first turn?) ... then uhh gg right?"

 

Yes because all of Google is willing to stake their reputation (and 1 million USD) on a program suite with a sufficiently easy to exploit bug that causes a fatal crash within a single move (or even within the time it takes to play the game using only legal actions...)

 

Even though the only part with potentially mistake ridden code is the DNN networks (because trust me on this, you know when you fuck up Monte Carlo) which once the game starts do not even decide anything.

 

Keep going on that...

[Roawoao]

14 minutes ago, Curufinwe_wins said:

Since this isn't related to the post/explanation I am going to make, your cop-out is this:

 

"WELL UHH... if they fucked up really hard then uhh... you can find the bug that just crashes it instead of it even playing stupid... and uhh if you can find a bug before the Monte Carlo method happens right away (aka before the first turn?) ... then uhh gg right?"

 

Yes because all of Google is willing to stake their reputation (and 1 million USD) on a program suite with a sufficiently easy to exploit bug that causes a fatal crash within a single move (or even within the time it takes to crash the game).

 

Even though the only part with potentially mistake ridden code is the DNN networks (because trust me on this, you know when you fuck up Monte Carlo) which once the game starts doesn't even decide anything.

 

Keep going on that...

You do realize the monto carlo method in theory is not the same thing as in code and there can easily be undiscovered bugs in any aspect of the software stack. Studying the training data and databases of AlphaGo can also find errors in the programming/data/implmentation and weaknesses that can be exploited.

 

Google's multibillion dollar search engine systems has plenty of bugs. Not only that their mission critical cloud control layer software also has had outages caused by programming bugs. I've even lost my gmail data from ages ago due to such bugs. Bugs always happen this is why you have multiple backups and don't keep everything with one provider.

 

So your literally going to stake a claim that the AlphaGo software in its current state is error free and no one will ever find a bug in it that would cause it to lose a game if you exploited said bug. No amount of money or reputation is going to write perfect code let alone one containing DNNs. You literally claim it is a perfect system fire all the developers no more Go programming needed no updates, no patches it can learn on its own and patch its own bugs.

 

Keep on going on that...

 

You also going to state that all non-DNN code is trivial to write error free code as well. Wow, why is hangouts so buggy again are they using DNNs there too. The whole point of a bug is that you did not detect it before hand and if someone is exploiting it your only going to see it fuck up the Monte Carlo real fast. It is not like programming is some perfect knowledge system where all bugs hop up and warn you to their existence there is no way to guarantee bug free code in a complex software system. 

[Curufinwe_wins]

11 minutes ago, Roawoao said:

Google's multibillion dollar search engine systems has plenty of bugs. Not only that their mission critical cloud control layer software also has had outages caused by programming bugs. I've even lost my gmail data from ages ago due to such bugs. Bugs always happen this is why you have multiple backups and don't keep everything with one provider.

 

So your literally going to stake a claim that the AlphaGo software in its current state is error free and no one will ever find a bug in it that would cause it to lose a game if you exploited said bug. No amount of money or reputation is going to write perfect code let alone one containing DNNs. It is literally a perfect system fire all the developers no more Go programming needed no updates, no patches.

 

Keep on going on that...

And AlphaGo has redundant computational systems...

 

Error free (in that it can make less than perfect decisions), normal-use fatal error free (in that by inputting moves you cannot cause an infinite unrecoverable hang), and unintended-use fatal error free (just throw random parses of data at it and see if you can force it to crash), are not the same thing.

 

1. It is definitely not error-free (in that it can be beaten and a deeper search even without bugs would result in better performance). Non-infinite hang errors/issues with DNNs fall under this category for example.
2. It is probably not unintended-use fatal error free because there is almost always some random shit you can throw at code that it doesn't handle properly. 
3. It is however effectively guaranteed to be normal-use fatal error free, given the particular way DNNs and MCTS interface. ESP considering the only thing you as an opponent are allowed to do in a match against it is play a piece. A Deepmind Representative then click/plays the identical selection on the GUI.

 

My point is that 2 is not relevant to this discussion, 1 is solved the proposed one word solutions (at least with the additional statement of 2 hour constraints once the game starts), and 3 I am going to stake a claim is true.

[Roawoao]

15 minutes ago, Curufinwe_wins said:

And AlphaGo has redundant computational systems...

 

Error free (in that it can make less than perfect decisions), normal-use fatal error free (in that by inputting moves you cannot cause an infinite unrecoverable hang), and unintended-use fatal error free (just throw random parses of data at it and see if you can force it to crash), are not the same thing.

 

1. It is definitely not error-free (in that it can be beaten and a deeper search even without bugs would result in better performance). Non-infinite hang errors/issues with DNNs fall under this category for example.
2. It is probably not unintended-use fatal error free because there is almost always some random shit you can throw at code that it doesn't handle properly. 
3. It is however effectively guaranteed to be normal-use fatal error free, given the particular way DNNs and MCTS interface. ESP considering the only thing you as an opponent are allowed to do in a match against it is play a piece. A Deepmind Representative then click/plays the identical selection on the GUI.

 

My point is that 2 is not relevant to this discussion, 1 is solved the proposed one word solutions (at least with the additional statement of 2 hour constraints once the game starts), and 3 I am going to stake a claim is true.

Redundant systems doesn't make it error free even in "normal" use. Redundancy can even cause bugs due to the added complexity especially in software. Examples of this include control layer bugs in highly redundant cloud software systems causing cascading failures and unexpected (bugs) control layer actions that literally corrupt the entire system. This is why offline backups are a must.

 

Normal use error free is still impossible. What defines normal use? If a programmer plays a game of Go and it crashes are you going to say it is abnormal use because he is clearly using an exploit and his Go game made no sense?... 

 

Again you stake a claim that AlphaGo in its current state needs no further development, programming, work by human developers and will never have a bug in "normal" use. How effective is your guarantee, sure it is probably well programmed but that doesn't mean there isn't some undiscovered bug that can be used in "normal" use.

[Curufinwe_wins]

10 minutes ago, Roawoao said:

Redundant systems doesn't make it error free. Redundancy can even cause bugs due to the added complexity especially in software. Examples of this include control layer bugs in highly redundant cloud software systems causing cascading failures and unexpected (bugs) control layer actions that literally corrupt the entire system. 

 

Normal use error free is still impossible. What defines normal use? If a programming plays a game of Go and it crashes are you going to say it is abnormal use?... 

Yea bullshit on that one...

 

Normal use in this case would be inputting any selection of moves and allowing it to play it's own moves before playing your next one (AKA playing the game.) Non-normal use would be feeding it random BS or say trying to force it to crash somehow by throwing 10 different moves at it at once (IF THAT were even possible).

 

Again normal use error free and normal use fatal error free are not the same thing... When Intel uncovered a microcode bug that caused it to miscalculate a specific sequence of prime numbers that is a normal use error, but not a normal use fatal error. The program did not crash, it merely gave wrong results. Non-fatal errors are by FAR the most common type of errors in computer programs. And as I said are effectively preventable via the solution that exists.

 

 

Good luck crashing a random non-scientific calculator by asking it to add too many times...

[Roawoao]

18 minutes ago, Curufinwe_wins said:

Yea bullshit on that one...

 

Normal use in this case would be inputting any selection of moves and allowing it to play it's own moves before playing your next one (AKA playing the game.) Non-normal use would be feeding it random BS or say trying to force it to crash somehow by throwing 10 different moves at it at once (IF THAT were even possible).

 

Again normal use error free and normal use fatal error free are not the same thing... When Intel uncovered a microcode bug that caused it to miscalculate a specific sequence of prime numbers that is a normal use error, but not a normal use fatal error. The program did not crash, it merely gave wrong results. Non-fatal errors are by FAR the most common type of errors in computer programs.

 

 

Good luck crashing a random non-scientific calculator by asking it to add too many times...

Yeah clearly you don't follow programming/IT news. Cloud failures and the complexity of the redundant systems can make things unpredictable.

https://aws.amazon.com/message/680342/

Spoiler

The Primary Event and the Impact to Amazon Elastic Block Store (EBS) and Amazon Elastic Compute Cloud (EC2)

At 10:00AM PDT Monday, a small number of Amazon Elastic Block Store (EBS) volumes in one of our five Availability Zones in the US-East Region began seeing degraded performance, and in some cases, became “stuck” (i.e. unable to process further I/O requests). The root cause of the problem was a latent bug in an operational data collection agent that runs on the EBS storage servers. Each EBS storage server has an agent that contacts a set of data collection servers and reports information that is used for fleet maintenance. The data collected with this system is important, but the collection is not time- sensitive and the system is designed to be tolerant of late or missing data. Last week, one of the data collection servers in the affected Availability Zone had a hardware failure and was replaced. As part of replacing that server, a DNS record was updated to remove the failed server and add the replacement server. While not noticed at the time, the DNS update did not successfully propagate to all of the internal DNS servers, and as a result, a fraction of the storage servers did not get the updated server address and continued to attempt to contact the failed data collection server. Because of the design of the data collection service (which is tolerant to missing data), this did not cause any immediate issues or set off any alarms. However, this inability to contact a data collection server triggered a latent memory leak bug in the reporting agent on the storage servers. Rather than gracefully deal with the failed connection, the reporting agent continued trying to contact the collection server in a way that slowly consumed system memory. While we monitor aggregate memory consumption on each EBS Server, our monitoring failed to alarm on this memory leak. EBS Servers generally make very dynamic use of all of their available memory for managing customer data, making it difficult to set accurate alarms on memory usage and free memory. By Monday morning, the rate of memory loss became quite high and consumed enough memory on the affected storage servers that they were unable to keep up with normal request handling processes.

The memory pressure on many of the EBS servers had reached a point where EBS servers began losing the ability to process customer requests and the number of stuck volumes increased quickly. This caused the system to begin to failover from the degraded servers to healthy servers. However, because many of the servers became memory-exhausted at the same time, the system was unable to find enough healthy servers to failover to, and more volumes became stuck. By approximately 11:00AM PDT, a large number of volumes in this Availability Zone were stuck. To remedy this, at 11:10AM PDT, the team made adjustments to reduce the failover rate. These adjustments removed load from the service, and by 11:35AM PDT, the system began automatically recovering many volumes. By 1:40PM PDT, about 60% of the affected volumes had recovered. The team continued to work to understand the issue and restore performance for the remaining volumes. The large surge in failover and recovery activity in the cluster made it difficult for the team to identify the root cause of the event. At 3:10PM PDT, the team identified the underlying issue and was able to begin restoring performance for the remaining volumes by freeing the excess memory consumed by the misbehaving collection agent. At this point, the system was able to recover most of the remaining stuck volumes; and by 4:15PM PDT, nearly all affected volumes were restored and performing normally.

We have deployed monitoring that will alarm if we see this specific memory leak again in any of our production EBS servers, and next week, we will begin deploying a fix for the memory leak issue. We are also modifying our system memory monitoring on the EBS storage servers to monitor and alarm on each process’s memory consumption, and we will be deploying resource limits to prevent low priority processes from consuming excess resources on these hosts. We are also updating our internal DNS configuration to further ensure that DNS changes are propagated reliably, and as importantly, make sure that our monitoring and alarming surface issues more quickly should these changes not succeed. These actions will address the problems that triggered the event. In addition, we are evaluating how to change the EBS failover logic that led to the rapid deterioration early in this event. We believe we can make adjustments to reduce the impact of any similar correlated failure or degradation of EBS servers within an Availability Zone.

 

https://gmail.googleblog.com/2011/02/gmail-back-soon-for-everyone.html

Quote

 Well, in some rare instances software bugs can affect several copies of the data. That’s what happened here. Some copies of mail were deleted, and we’ve been hard at work over the last 30 hours getting it back for the people affected by this issue.

In this case my Gmail data was lost forever on their side but I had an offline backup to restore from.

 

So its forbidden to use undiscovered bugs to win. That is what you define as "normal". You seem to be inventing rules that didn't exist in Go does the AI need a handicap or something. There is no way you can guarantee that there exists no game-play induced bug that will crash the system this is not relying on fuzzing the hardware just "normal" gameplay that you know before hand will cause an error because you studied the code/databases.

 

Your being awfully specific when you say random non-scientific calculator because plenty of calculators have fatal bugs or do not produce the correct results. But as usual your wrong.

 

https://en.wikipedia.org/wiki/HP-12C

Quote

Bugs and problems
By design the HP-12C rounds up the number of payments to the next integer, which produces meaningless results when calculating fractional periods. Consequently, solving for n returns a value that is mathematically incorrect vis-a-vis the standard annuity formula and different from the value returned by other financial calculators, Excel, etc.[22]

 

O look at that a non-scientific calculator that can't add things up properly because it doesn't round correctly. Also almost all cheapo calculators will crash if you overflow them so I don't really know what your talking about many of them even require a reset. (They are dirt cheap after all).

 

You do realize this thing called an errata right you should look it up because it is pretty long for many devices and this is just the known bugs not the undiscovered bugs. 

 

http://techreport.com/news/13721/chip-problem-limits-supply-of-quad-core-opterons

 

AMD has had fatal ones as well. Obviously non-fatal errors are more common but that doesn't mean fatal ones do not ever exist.

 

 

 

[Curufinwe_wins]

Just now, Roawoao said:

So its forbidden to use undiscovered bugs to win. That is what you define as "normal". You seem to be inventing rules that didn't exist in Go does the AI need a handicap or something. There is no way you can guarantee that there exists no game-play induced bug that will crash the system this is not relying on fuzzing the hardware just "normal" gameplay that you know before hand will cause an error because you studied the code/databases.

 

Your being awfully specific when you say random non-scientific calculator because plenty of calculators have fatal bugs or do not produce the correct results. But as usual your wrong.

 

https://en.wikipedia.org/wiki/HP-12C

 

O look at that a non-scientific calculator that can't add things up properly because it doesn't round correctly. 

 

You do realize this thing called an errata right you should look it up because it is pretty long for many devices and this is just the known bugs not the undiscovered bugs. 

 

http://techreport.com/news/13721/chip-problem-limits-supply-of-quad-core-opterons

 

AMD has had fatal ones as well. Obviously non-fatal errors are more common but that doesn't mean fatal ones do not ever exist.

 

 

 

You could in theory discover bugs ANY WAY YOU WANT, but once you start playing (according to the convention that has already been in use for this match, NOT CHANGING ANY RULES AT ALL), you could only apply the bug if it manifested via a specific move set (as you are not allowed direct contact with the machine interface DUH).

 

The reason I say non-scientific calculator is calculators that can provide integrals and derivatives (and certain other things like limitless input array length that are generally associated with scientific calculators) can be forced into positions where they take hours to complete a task (or tell you it cannot be completed). While this is technically not a FATAL error (the calculator did not crash, it was just thinking for a long time), it isn't useful during that time, and such an error with AlphaGo (although since programmed to be on a time limit it almost certainly has safeguards against this) would be EFFECTIVELY the same as a fatal error. 

 

Additionally there are things that calculators just cannot calculate which are not fatal errors if that is intended behavior (saying calling an error message on divide by 0 a fatal error is like calling the close button on chrome a fatal error...)

 

15 minutes ago, Curufinwe_wins said:

Good luck crashing a random non-scientific calculator by asking it to add too many times...

Note that your message on the HP-12C (which would be considered a scientific calculator anyways) is NOT A FATAL ERROR. It is a direct analog to the example I gave which is that it did math wrong but it still functions afterwards and that is sufficient for my proposed solution to render such concerns invalid. It did not CRASH, it did not HANG (as the proper coding term would call it).

 

 

[Roawoao]

17 minutes ago, Curufinwe_wins said:

You could in theory discover bugs ANY WAY YOU WANT, but once you start playing (according to the convention that has already been in use for this match, NOT CHANGING ANY RULES AT ALL), you could only apply the bug if it manifested via a specific move set (as you are not allowed direct contact with the machine interface DUH).

 

The reason I say non-scientific calculator is calculators that can provide integrals and derivatives (and certain other things like limitless input array length that are generally associated with scientific calculators) can be forced into positions where they take hours to complete a task (or tell you it cannot be completed). While this is technically not a FATAL error (the calculator did not crash, it was just thinking for a long time), it isn't useful during that time, and such an error with AlphaGo (although since programmed to be on a time limit it almost certainly has safeguards against this) would be EFFECTIVELY the same as a fatal error. 

 

Additionally there are things that calculators just cannot calculate which are not fatal errors if that is intended behavior (saying calling an error message on divide by 0 a fatal error is like calling the close button on chrome a fatal error...)

 

Note that your message on the HP-12C (which would be considered a scientific calculator anyways) is NOT A FATAL ERROR. It is a direct analog to the example I gave which is that it did math wrong but it still functions afterwards and that is sufficient for my proposed solution to render such concerns invalid. It did not CRASH, it did not HANG (as the proper coding term would call it).

 

 

It doesn't need to be one specific move set just a sequence of actions that cause the bug and there may be many countless move sets that would trigger an unknown bug.

 

If a calculator crashes because it tries to compute something it cannot calculate that is also a fatal bug. It should say it has no resources to do that and refuse to try. Cheapo calculators will happily overflow and then crash if repeatedly adding large integers. The reset button is easy to press so they don't care about such fatal errors and just let it happen. There is no such thing as an infinite input array on normal calculators computers do not have infinite memory let alone the features to allow such entries.

 

A div by zero error message is a handled exception the calculator going blank and refusing to work until you reset it is a crash. Many cheap calculators forgo fixing such bugs or handling even simple known exceptions. More advanced calculators like graphing calculators and many scientific calculators are littered with tons of bugs not related to math even. Again your being awfully specific to try and ignore the fact errors are just normal in programming and hardware.

 

A fatal error also includes producing abnormal results which are fatally wrong. Example a few odd moves causes the AlphaGo system to forfeit the match and conclude it has no possibility of winning or falsely trips protections designed to stop excessive delays and makes it behave in unexpected ways. It doesn't crash hard but it still effectively was crashed. Same for the financial calculator improperly adding numbers is a very bad idea for a financial calculator. If you have a FADEC running an engine and it keeps on running the engine wrong until it makes the main rotor fly out of the housing I'd call that a fatal error.

 

A financial calculator is not a scientific calculator. Two different calculator types.

 

Finally the one thing you still haven't admitted is AlphaGo is not some perfect computer program which is something that should be very logical to state and that any expert programmer who studied it could beat it by exploiting bugs in normal gameplay. Obviously if you open things up to network, physical access things get trivially easy.

[spartaman64]

is it just me or is the caster who is a pro is getting sort of salty at the other caster in the second video lol