What you're describing isn't intelligent self-interest (which is the most basic element of economics). It also isn't either atheism or religion (of whatever kind).
There is in fact a word for what you're describing, and it isn't "Nash efficiency" or "Atheism" or anything like that. It's "Kleptomania", and it's usually considered to be a mental disturbance.
What an absurd diatribe. I'll just say that you just lost any argument you might have had by equivocating atheism with only working in one's own self-interest.
Except that he didn't - he misrepresented intelligent self-interest to mean trying to keep everything to one's self (even if what that person is trying to retain has little marginal utility for them). Everything else went downhill from there, whether it's about religion, atheism, or economics.
In spite of his throwing around a lot of economic and religious terminology, I don't get the impression that he has much actual depth of knowledge in either economics or religion.
even the food would disappear from the local supermarket, as it will be more in the personal interest of the owner to simply keep it himself
It would?! Just how much food can one person (or even one family) eat?! Once you have enough food to sustain life, and maybe a bit more to be able to enjoy it a bit, then you start to want other things - like clothing and shelter. And other nice things.
I think you're trying to argue that religion makes for a "nicer" society, which is at least an arguable position. But it's certainly not necessary in order to make economic self-interest work, which is what you're actually saying.
I suggest that you read up a bit on both religion and economics, and then post back.
That's why the Rosetta stone was so useful: the other two languages on the stone were still known, allowing scholars to realize that they said the same thing and that it was likely that the third, Heiroglyphs, said the same thing.
When the Rosetta Stone was first discovered around 1799, only 1 of the three languages was known. It was however a pretty good guess that the other two said the same thing, and one of them (Demotic Egyptian) was deciphered fairly quickly because of its similarity to Coptic - however it would be a big stretch to say that it was "already known" at the time. At that point it became a pretty safe bet that the tablet had the same message written in hieroglyphs.
Not that I disagree with the main thrust of your argument, which is a good one.
Someone may end up laughing at this post in 300 years, but I really don't think English is going to change much at all in terms of the ability for people in 300-2000 years to understand.
Perhaps, though I think global economic collapse would probably be more likely than nuclear winter to cause cultural separation and language drift, if for no other reason than that things like that have happened so many times before.
English is certainly in a much better position to survive for the long haul than most ancient languages because it's spoken and read by so many people in all parts of the world, either as a first or second language. However I think if we were talking about this subject 2000 years ago, we would both be astounded to hear that few people nowadays can read or understand either Latin or Koine Greek, the two most common and widely-dispersed languages of that era.
Just how do you propose to preserve the language(s) needed to read all of that scientific data?! The intention isn't to provide a scientific archive, but a linguistic archive. It's a pretty safe bet that there will be at least some modern-era text that survives that long, but will anyone still be able to read it? This provides some hope of being able to decipher modern languages at some point in the distant future.
Moreover, what scientific knowledge do you encode? It's constantly changing and improving: consider just how laughable much of pre-Victorian science is to modern readers; even the Victorian scientists sound pretty quaint to the modern ear. The science available in 50 years will most likely be enormously advanced from modern knowledge, but basic linguistic knowledge will most likely still be relatively stable.
I think this is an entirely appropriate project - and I don't think it's that they don't plan to preserve other texts, but rather that something like this is a prerequisite to encoding anything else.
Do you really know the meaning of the words "day" in the original language? No, it's only the Catholic Church and some other prominent so-called "christian" organizations that promote that idea.
I don't believe that the Catholic Church promotes the idea any more that the world was created in 7 literal days - for quite a long time now they've accepted that the story is symbolic and mythological, not literal.
There are a few Christian groups who do believe in 7 literal days of creation - but most of them tend to be fundamentalist Protestants rather than Catholics or "mainline" Protestants.
Naturally there are individual members of each of these groups whose beliefs do not match the "official" beliefs of their respective denominations - but that shouldn't be used as evidence of what the denomination as a whole believes.
Actually English from 300 years ago is quite readable by any educated modern reader (though cursive writing can be difficult because the longhand script has changed a couple of times since then). Think Shakespeare, for example.
However if you start talking about English from, say, 600 years ago, it's quite a bit more difficult (Chaucer), and from over 1000 years ago it's impossible unless you're a specialist (Beowulf).
Many other languages have evolved quite a bit in that amount of time, but a few haven't. For example, written (as opposed to spoken) Greek is much less changed over the last 2000 years than is English - classical Greek is to modern Greek more like Chaucer or Shakespeare is to modern English, rather than like the difference between Beowulf and modern English.
So even though your specific example doesn't hold water, the general sense of what you're saying is quite valid - it's quite possible (even likely) that modern English will be nearly unintelligible in 2000 years.
Among the 13,500 scanned pages are 1,500 different language versions of Genesis 1-3
I'm sure they picked bible passages because the translations were mostly done for them already but I'm a little embarrassed that future generations are going to think how amazingly superstitious we were. I mean, Genesis 2 alone...
And you don't think that future generations of scholars will be at least passingly familiar with Genesis?! Modern scholars are quite familiar with a wide range of mythologies. It is, rather, a useful and widely-known text to translate into a wide number of languages so that future scholars might be able to figure out how to translate those languages. In fact offhand I'm not even sure that I can suggest a better text for the stated purpose, which is to preserve the languages, not to transmit knowledge.
That was, after all, one of the great things about the Rosetta stone - although the text was not one that was already known, one of the languages was (Greek), which allowed scholars to decipher the other two scripts. Having contemporaneous translations of the passage in all of these languages allows you to get a snapshot of all of those languages at the same point in time.
The Romans managed to preserve their language and culture for 2000 years completely by accident. Do you really think all the stuff we're doing today will vanish in the same time span.
It wasn't completely by accident - many early Roman and Greek works were deliberately preserved in the monasteries. Compare for example what happened to ancient Carthaginian culture, which is approximately the same age and which was nearly exterminated: about all that we know about them was written by their opponents.
This depends on the definition of "best possible move" - is your best choice the one that is the best possible move assuming perfect play by both sides or is the one that maximizes your chance of winning (or degree of winning for those games which have multiple levels of "winning") against this opponent?
If the former, it's a fairly standard result of game theory that in every position there exists a move (or a subset of moves) which maximize the player's expected outcome and/or which pose the most difficult problems to the other player assuming perfect play by both sides. If the latter, then what you say is correct, however if you opponent plays better than expected then your expected outcome may suffer.
In Chess your idea works great in the opening and endgame, when the number of choices or positions is greatly restricted. Once you get to the middle game it breaks down because there aren't enough computers in the entire galaxy to store all of the possible positions. (The number of possible Chess positions is roughly 10^60, and there are only about 10^70 atoms in the entire galaxy, the bulk of which are in stars and interstellar gases).
In Go this idea doesn't even get off the ground because just about all of the first few possible moves are actually sort of reasonable, and their number increases extremely rapidly (361x360x359x358 = 16,702,719,120 for each player's first 2 moves. Even after eliminating rotations and reflections you're still left with a lot of moves). So you quickly run out of database storage long before you get to any positions that could be considered "interesting." Likewise with the endgame - there are just too many possible positions.
Random pawn moves are rarely useful even in Chess, because they have irrevocable long-term consequences. If you find yourself in a position where you need to make a waiting move, almost anything else is preferable as long as it doesn't lose a piece.
The only "clever" algorithm is evaluating the positions (rather difficult in Chess).
By and large Chess positions are actually relatively easy to evaluate compared to Go positions. In the typical Chess position encountered in an exhaustive computer search (the most usual way for computer Chess programs to work), most of them will be horribly one-sided (one side or the other having lost a significant amount of material or even having been checkmated). In those positions where material is approximately even, subtlety does enter in and the strength of the program can be greatly affected by how well it evaluates "even-material" positions.
In Go the evaluation is much harder. In general "material" will often appear roughly even (!) since captures are relatively rare compared to Chess. Instead you need to evaluate much larger patterns - so unless you have good pattern recognition, your search will not proceed as efficiently (since efficiency is improved by having a better evaluation function) nor will your predicted line of play necessarily be very strong (since if your evaluation function isn't usually right about the relative merits of the terminal nodes, you're not necessarily doing much better than optimizing your path through a random function).
If there's any advantage in building some kind of per-game "endgame database" it would probably be most useful in the late middle game and early endgame, and would be used for improving move selection in some way (either improving the evaluation of the terminal nodes or improving the Monte Carlo simulation) as the endgame approached - by the time you're actually in the late endgame you're just optimizing the last few moves, and finding optimal paths through a well-defined search space is already something that computers can do well.
Actually I think you may be able to harvest some of the results from the Monte Carlo algorithm itself to put into such a database. I don't have a specific design in mind, but there's certainly some information in there that it may be possible to harvest.
The question also becomes whether something like this might become more practical as you add more and more processors. At some point it might well be worth devoting a few cores to maintaining and searching such a database, if you already have thousands running the Monte Carlo simulations (those cores could only improve the simulation linearly if they were running the Monte Carlo, but might be able to make a significant improvement in overall play if the database had sufficient power).
With 800 cores the architecture they're running might already have enough cores that some of them could be split off to perform other tasks if we knew how they could be utilized most effectively.
Yes, the search space in Go is dauntingly large, even compared to the already large search space in chess. But the raw size of the search space is not your only (or possibly even the primary) problem, but rather the difficulty of writing a terminal node evaluation function.
To take only one simple example, it's easy to construct games related to Nim or the like which have monstrous search spaces, but where the terminal node evaluation function is trivial. Likewise even Go on a smaller board (thereby restricting the search space) is still a daunting problem unless you either restrict the search space sufficiently that you can search it nearly exhaustively or unless you can design a more powerful terminal node evaluation function.
This is indeed an advantage that chess enjoys, however it's more of a second-order effect. In chess the endgame database doesn't really come into play in a significant way until towards the very end of the game, since for the first part of the game the terminal nodes can be adequately evaluated without it even if they are "endgame" nodes from the point of view of the remaining material. Even during the endgame phase the endgame databases often don't come into play in a significant way because the endgame databases only cover the simplest cases. Not that such databases aren't worth having because when the situation does arise where those cases are significant, having access to the database can be decisive.
However as a game of Go progresses, it should be possible to build up a library of possible outcomes for this specific game, especially with a highly parallel system such as this one. This would be most useful if you had some way of recognizing "similar enough" positions in the database, though it would still have some value during the Go endgame if it only recognized exact matches. (As you note, a Go endgame is nothing like a chess endgame so you can't build up a single database that will work for all Go games).
You've got the right idea. (I wrote one of the highly ranked computer chess programs so I do have quite a bit of experience in game programming).
Chess has a relatively low effective branching factor - not simply because many of the pieces have a limited range of motion (resulting in only an average of 30-40 possible moves per turn), but also because many of the moves that are legal get clobbered quickly (put your Queen under attack and you lose your most powerful piece, open your King up to being checkmated and you lose the game immediately, etc).
By contrast Go has a very large search space - starting out with 19x19=361 possible moves per turn which decreases only slowly throughout the game. Moreover most of the time a large number (usually most of them, in fact) of these moves are at least somewhat reasonable - and you have few situations analogous to the possible blunders in chess which result in an immediate and easily computed change in your evaluation function. The evaluation of the terminal positions in your search is much more pattern-based and more difficult because of the complete lack of such overriding considerations that you have in chess.
Go is a very intractable problem that probably cannot be made to yield to the same techniques that work so well with games which have more restricted and more easily evaluated search spaces such as chess and checkers, at least not without a major improvement in pattern recognition for the terminal nodes. Otherwise you have to search dozens or even hundreds of ply before the consequences are visible to a simpler evaluation algorithm; this looks like it will remain well out of reach for the foreseeable future. The Monte Carlo approach mentioned here is very interesting and looks like a promising way to get past the difficulty of applying a traditional Alpha-Beta search algorithm to a problem where the terminal node evaluation (on which Alpha-Beta depends) is poorly understood.
While this is true as far as it goes, the article claims that the exploit has "no workaround". If that's really true (and the details are too sketchy to make any kind of judgment about that), then it would appear that even a "correctly configured" machine still has some degree of vulnerability.
Unfortunately, they take about thirty seconds to retrieve their card from their purse/wallet after the three touches before they can swipe.
Hey, I resemble that remark:). Actually no I don't, I usually have my credit card ready, but then as often as not as soon as I've put it back in my wallet the salesdweeb says something like "I need to get your number from the card" - either the last 4 digits of the credit card number embossed on the card to make sure it matches the mag stripe, or the CVV number from the back of the card.
[rant]But this is bad human factors - if the salesdweeb needs the card in any event, it's going to be more efficient to just give it to them in the first place and let them swipe it in whatever idiosyncratic way the card reader requires. Normally I'd expect that if I'm swiping the card, at most I'll be asked to enter the PIN number, not to hand over the card as well.
Is there a requirement that in order to design credit card terminals you need to have failed your human factors analysis course?[/rant]
It's amazing how many directions are required to teach the public to use something that you think is easily used -- like swiping a credit card.
[rant] The problem with credit card swipers is not that the concept is so hard to understand - it's that every single one is different, and often gratuitously different!! Should the card be oriented left, right, towards the main part of the box, away from it, should it be swiped quickly or slowly, etc, etc. It seems like every developer of such devices has their own idiosyncratic way of doing things. This is deadly when trying to get any kind of consistent behaviour or results from the great unwashed public.
I hate to say it, but it may be time for one of the standards organizations to step in and DICTATE how such things should be designed. We sure can't seem to get any kind of consistency any other way!!
[/rant]
This sounds more like a communications problem than a conceptual problem. Depending on what you're trying to accomplish, 32K may be oceans of memory or just a tiny puddle, and using some standard OOP tools may bloat your code to the point that it's hard to get it to fit. It sounds more like they were talking past each other - using the same words to mean different things - rather than that either side was wrong given their respective assumptions about what the words meant.
This is nothing new - it is, for example, how Xt/Xm and other Xlib toolkits have worked for years. It all ends up looking very "object-oriented" but it's all straight C.
I think if you read the actual proposed regulation that's published at http://www.ftc.gov/ you'll see that that's exactly what happens. This regulation does not appear to apply to businesses who merely accept credit cards, but rather to those who issue credit cards or other forms of credit.
Slashdot Mirror
What you're describing isn't intelligent self-interest (which is the most basic element of economics). It also isn't either atheism or religion (of whatever kind).
There is in fact a word for what you're describing, and it isn't "Nash efficiency" or "Atheism" or anything like that. It's "Kleptomania", and it's usually considered to be a mental disturbance.
What an absurd diatribe. I'll just say that you just lost any argument you might have had by equivocating atheism with only working in one's own self-interest.
Except that he didn't - he misrepresented intelligent self-interest to mean trying to keep everything to one's self (even if what that person is trying to retain has little marginal utility for them). Everything else went downhill from there, whether it's about religion, atheism, or economics.
In spite of his throwing around a lot of economic and religious terminology, I don't get the impression that he has much actual depth of knowledge in either economics or religion.
even the food would disappear from the local supermarket, as it will be more in the personal interest of the owner to simply keep it himself
It would?! Just how much food can one person (or even one family) eat?! Once you have enough food to sustain life, and maybe a bit more to be able to enjoy it a bit, then you start to want other things - like clothing and shelter. And other nice things.
I think you're trying to argue that religion makes for a "nicer" society, which is at least an arguable position. But it's certainly not necessary in order to make economic self-interest work, which is what you're actually saying.
I suggest that you read up a bit on both religion and economics, and then post back.
That's why the Rosetta stone was so useful: the other two languages on the stone were still known, allowing scholars to realize that they said the same thing and that it was likely that the third, Heiroglyphs, said the same thing.
When the Rosetta Stone was first discovered around 1799, only 1 of the three languages was known. It was however a pretty good guess that the other two said the same thing, and one of them (Demotic Egyptian) was deciphered fairly quickly because of its similarity to Coptic - however it would be a big stretch to say that it was "already known" at the time. At that point it became a pretty safe bet that the tablet had the same message written in hieroglyphs.
Not that I disagree with the main thrust of your argument, which is a good one.
Someone may end up laughing at this post in 300 years, but I really don't think English is going to change much at all in terms of the ability for people in 300-2000 years to understand.
Perhaps, though I think global economic collapse would probably be more likely than nuclear winter to cause cultural separation and language drift, if for no other reason than that things like that have happened so many times before.
English is certainly in a much better position to survive for the long haul than most ancient languages because it's spoken and read by so many people in all parts of the world, either as a first or second language. However I think if we were talking about this subject 2000 years ago, we would both be astounded to hear that few people nowadays can read or understand either Latin or Koine Greek, the two most common and widely-dispersed languages of that era.
2000 years is a long time.
Just how do you propose to preserve the language(s) needed to read all of that scientific data?! The intention isn't to provide a scientific archive, but a linguistic archive. It's a pretty safe bet that there will be at least some modern-era text that survives that long, but will anyone still be able to read it? This provides some hope of being able to decipher modern languages at some point in the distant future.
Moreover, what scientific knowledge do you encode? It's constantly changing and improving: consider just how laughable much of pre-Victorian science is to modern readers; even the Victorian scientists sound pretty quaint to the modern ear. The science available in 50 years will most likely be enormously advanced from modern knowledge, but basic linguistic knowledge will most likely still be relatively stable.
I think this is an entirely appropriate project - and I don't think it's that they don't plan to preserve other texts, but rather that something like this is a prerequisite to encoding anything else.
Do you really know the meaning of the words "day" in the original language? No, it's only the Catholic Church and some other prominent so-called "christian" organizations that promote that idea.
I don't believe that the Catholic Church promotes the idea any more that the world was created in 7 literal days - for quite a long time now they've accepted that the story is symbolic and mythological, not literal.
There are a few Christian groups who do believe in 7 literal days of creation - but most of them tend to be fundamentalist Protestants rather than Catholics or "mainline" Protestants.
Naturally there are individual members of each of these groups whose beliefs do not match the "official" beliefs of their respective denominations - but that shouldn't be used as evidence of what the denomination as a whole believes.
Try reading English from 300 years ago.
Actually English from 300 years ago is quite readable by any educated modern reader (though cursive writing can be difficult because the longhand script has changed a couple of times since then). Think Shakespeare, for example.
However if you start talking about English from, say, 600 years ago, it's quite a bit more difficult (Chaucer), and from over 1000 years ago it's impossible unless you're a specialist (Beowulf).
Many other languages have evolved quite a bit in that amount of time, but a few haven't. For example, written (as opposed to spoken) Greek is much less changed over the last 2000 years than is English - classical Greek is to modern Greek more like Chaucer or Shakespeare is to modern English, rather than like the difference between Beowulf and modern English.
So even though your specific example doesn't hold water, the general sense of what you're saying is quite valid - it's quite possible (even likely) that modern English will be nearly unintelligible in 2000 years.
Among the 13,500 scanned pages are 1,500 different language versions of Genesis 1-3
I'm sure they picked bible passages because the translations were mostly done for them already but I'm a little embarrassed that future generations are going to think how amazingly superstitious we were. I mean, Genesis 2 alone...
And you don't think that future generations of scholars will be at least passingly familiar with Genesis?! Modern scholars are quite familiar with a wide range of mythologies. It is, rather, a useful and widely-known text to translate into a wide number of languages so that future scholars might be able to figure out how to translate those languages. In fact offhand I'm not even sure that I can suggest a better text for the stated purpose, which is to preserve the languages, not to transmit knowledge.
That was, after all, one of the great things about the Rosetta stone - although the text was not one that was already known, one of the languages was (Greek), which allowed scholars to decipher the other two scripts. Having contemporaneous translations of the passage in all of these languages allows you to get a snapshot of all of those languages at the same point in time.
The Romans managed to preserve their language and culture for 2000 years completely by accident. Do you really think all the stuff we're doing today will vanish in the same time span.
It wasn't completely by accident - many early Roman and Greek works were deliberately preserved in the monasteries. Compare for example what happened to ancient Carthaginian culture, which is approximately the same age and which was nearly exterminated: about all that we know about them was written by their opponents.
This depends on the definition of "best possible move" - is your best choice the one that is the best possible move assuming perfect play by both sides or is the one that maximizes your chance of winning (or degree of winning for those games which have multiple levels of "winning") against this opponent?
If the former, it's a fairly standard result of game theory that in every position there exists a move (or a subset of moves) which maximize the player's expected outcome and/or which pose the most difficult problems to the other player assuming perfect play by both sides. If the latter, then what you say is correct, however if you opponent plays better than expected then your expected outcome may suffer.
Is there even such a thing as a 24-stone handicap!? The largest handicap I've ever heard of is a 21-stone handicap, which is already huge.
In Chess your idea works great in the opening and endgame, when the number of choices or positions is greatly restricted. Once you get to the middle game it breaks down because there aren't enough computers in the entire galaxy to store all of the possible positions. (The number of possible Chess positions is roughly 10^60, and there are only about 10^70 atoms in the entire galaxy, the bulk of which are in stars and interstellar gases).
In Go this idea doesn't even get off the ground because just about all of the first few possible moves are actually sort of reasonable, and their number increases extremely rapidly (361x360x359x358 = 16,702,719,120 for each player's first 2 moves. Even after eliminating rotations and reflections you're still left with a lot of moves). So you quickly run out of database storage long before you get to any positions that could be considered "interesting." Likewise with the endgame - there are just too many possible positions.
Random pawn moves are rarely useful even in Chess, because they have irrevocable long-term consequences. If you find yourself in a position where you need to make a waiting move, almost anything else is preferable as long as it doesn't lose a piece.
The only "clever" algorithm is evaluating the positions (rather difficult in Chess).
By and large Chess positions are actually relatively easy to evaluate compared to Go positions. In the typical Chess position encountered in an exhaustive computer search (the most usual way for computer Chess programs to work), most of them will be horribly one-sided (one side or the other having lost a significant amount of material or even having been checkmated). In those positions where material is approximately even, subtlety does enter in and the strength of the program can be greatly affected by how well it evaluates "even-material" positions.
In Go the evaluation is much harder. In general "material" will often appear roughly even (!) since captures are relatively rare compared to Chess. Instead you need to evaluate much larger patterns - so unless you have good pattern recognition, your search will not proceed as efficiently (since efficiency is improved by having a better evaluation function) nor will your predicted line of play necessarily be very strong (since if your evaluation function isn't usually right about the relative merits of the terminal nodes, you're not necessarily doing much better than optimizing your path through a random function).
If there's any advantage in building some kind of per-game "endgame database" it would probably be most useful in the late middle game and early endgame, and would be used for improving move selection in some way (either improving the evaluation of the terminal nodes or improving the Monte Carlo simulation) as the endgame approached - by the time you're actually in the late endgame you're just optimizing the last few moves, and finding optimal paths through a well-defined search space is already something that computers can do well.
Actually I think you may be able to harvest some of the results from the Monte Carlo algorithm itself to put into such a database. I don't have a specific design in mind, but there's certainly some information in there that it may be possible to harvest.
The question also becomes whether something like this might become more practical as you add more and more processors. At some point it might well be worth devoting a few cores to maintaining and searching such a database, if you already have thousands running the Monte Carlo simulations (those cores could only improve the simulation linearly if they were running the Monte Carlo, but might be able to make a significant improvement in overall play if the database had sufficient power).
With 800 cores the architecture they're running might already have enough cores that some of them could be split off to perform other tasks if we knew how they could be utilized most effectively.
Yes, the search space in Go is dauntingly large, even compared to the already large search space in chess. But the raw size of the search space is not your only (or possibly even the primary) problem, but rather the difficulty of writing a terminal node evaluation function.
To take only one simple example, it's easy to construct games related to Nim or the like which have monstrous search spaces, but where the terminal node evaluation function is trivial. Likewise even Go on a smaller board (thereby restricting the search space) is still a daunting problem unless you either restrict the search space sufficiently that you can search it nearly exhaustively or unless you can design a more powerful terminal node evaluation function.
This is indeed an advantage that chess enjoys, however it's more of a second-order effect. In chess the endgame database doesn't really come into play in a significant way until towards the very end of the game, since for the first part of the game the terminal nodes can be adequately evaluated without it even if they are "endgame" nodes from the point of view of the remaining material. Even during the endgame phase the endgame databases often don't come into play in a significant way because the endgame databases only cover the simplest cases. Not that such databases aren't worth having because when the situation does arise where those cases are significant, having access to the database can be decisive.
However as a game of Go progresses, it should be possible to build up a library of possible outcomes for this specific game, especially with a highly parallel system such as this one. This would be most useful if you had some way of recognizing "similar enough" positions in the database, though it would still have some value during the Go endgame if it only recognized exact matches. (As you note, a Go endgame is nothing like a chess endgame so you can't build up a single database that will work for all Go games).
You've got the right idea. (I wrote one of the highly ranked computer chess programs so I do have quite a bit of experience in game programming).
Chess has a relatively low effective branching factor - not simply because many of the pieces have a limited range of motion (resulting in only an average of 30-40 possible moves per turn), but also because many of the moves that are legal get clobbered quickly (put your Queen under attack and you lose your most powerful piece, open your King up to being checkmated and you lose the game immediately, etc).
By contrast Go has a very large search space - starting out with 19x19=361 possible moves per turn which decreases only slowly throughout the game. Moreover most of the time a large number (usually most of them, in fact) of these moves are at least somewhat reasonable - and you have few situations analogous to the possible blunders in chess which result in an immediate and easily computed change in your evaluation function. The evaluation of the terminal positions in your search is much more pattern-based and more difficult because of the complete lack of such overriding considerations that you have in chess.
Go is a very intractable problem that probably cannot be made to yield to the same techniques that work so well with games which have more restricted and more easily evaluated search spaces such as chess and checkers, at least not without a major improvement in pattern recognition for the terminal nodes. Otherwise you have to search dozens or even hundreds of ply before the consequences are visible to a simpler evaluation algorithm; this looks like it will remain well out of reach for the foreseeable future. The Monte Carlo approach mentioned here is very interesting and looks like a promising way to get past the difficulty of applying a traditional Alpha-Beta search algorithm to a problem where the terminal node evaluation (on which Alpha-Beta depends) is poorly understood.
While this is true as far as it goes, the article claims that the exploit has "no workaround". If that's really true (and the details are too sketchy to make any kind of judgment about that), then it would appear that even a "correctly configured" machine still has some degree of vulnerability.
Hey, I resemble that remark :). Actually no I don't, I usually have my credit card ready, but then as often as not as soon as I've put it back in my wallet the salesdweeb says something like "I need to get your number from the card" - either the last 4 digits of the credit card number embossed on the card to make sure it matches the mag stripe, or the CVV number from the back of the card.
[rant]But this is bad human factors - if the salesdweeb needs the card in any event, it's going to be more efficient to just give it to them in the first place and let them swipe it in whatever idiosyncratic way the card reader requires. Normally I'd expect that if I'm swiping the card, at most I'll be asked to enter the PIN number, not to hand over the card as well.
Is there a requirement that in order to design credit card terminals you need to have failed your human factors analysis course?[/rant]
[rant] The problem with credit card swipers is not that the concept is so hard to understand - it's that every single one is different, and often gratuitously different!! Should the card be oriented left, right, towards the main part of the box, away from it, should it be swiped quickly or slowly, etc, etc. It seems like every developer of such devices has their own idiosyncratic way of doing things. This is deadly when trying to get any kind of consistent behaviour or results from the great unwashed public.
I hate to say it, but it may be time for one of the standards organizations to step in and DICTATE how such things should be designed. We sure can't seem to get any kind of consistency any other way!! [/rant]
This sounds more like a communications problem than a conceptual problem. Depending on what you're trying to accomplish, 32K may be oceans of memory or just a tiny puddle, and using some standard OOP tools may bloat your code to the point that it's hard to get it to fit. It sounds more like they were talking past each other - using the same words to mean different things - rather than that either side was wrong given their respective assumptions about what the words meant.
This is nothing new - it is, for example, how Xt/Xm and other Xlib toolkits have worked for years. It all ends up looking very "object-oriented" but it's all straight C.
I think if you read the actual proposed regulation that's published at http://www.ftc.gov/ you'll see that that's exactly what happens. This regulation does not appear to apply to businesses who merely accept credit cards, but rather to those who issue credit cards or other forms of credit.