10 Temmuz 2012 Salı
9 Temmuz 2012 Pazartesi
Mountain Lion: new update version released
To contact us Click HERE
Mountain Lion, A new update has been released for Apple Mountain Lion. Apple is advising testers to upgrade to the latest version conduct. The update is about 1 GB in size, and how "9to5Mac 'reports, it contains settings for the Facebook integration - for example, Facebook notifications -. Thus the user can set whether they can be alerted in the central message of the latest news will be posted but must continue through the browser.
Mountain Lion in the final version to appear in July and are mainly sold through the App Store. The price for the OS X is located at 15.99 €.
Widget by Hoctro | Jack Book
Mountain Lion in the final version to appear in July and are mainly sold through the App Store. The price for the OS X is located at 15.99 €.
Related Posts by Categories
Widget by Hoctro | Jack Book
Peeking Under the Hood
To contact us Click HERE
Back in the day, if you asked a computer programmer (because that is what we were called way back then) what language they programmed in you'd get answers like FORTRAN, COBOL, and for the proud few maybe assembler. Today, when you ask that question, it's anybody's guess what the answer might be, but there's a good chance it would be a domain specific language I've never heard of.
Both then and now, if you asked a random software developer how did their language perform execution synchronization among multiple threads of control (or tasks, or processes, or execution contexts, or whatever damn thing their problem domain wants to call it), the typical answer would be "I dunno" or "isn't that the operating system's job?" or "what's a task?".
But most developers at least understand the basic problem in the abstract. The classic pedagogical example is your checking account. If two people are each independently trying to cash checks for $100 that you wrote when your account contains just $150, somehow the action of reading your balance to check for sufficient funds and then modifying your balance to withdraw the money has to be indivisible. Otherwise person A could check for sufficient funds, then person B could check, then person A gets their money, then person B, even though your account doesn't actually have of enough cash to cover both checks.
This wasn't a problem when there was only one bank, in one building, with one ledger book. The ledger was the final arbiter of how much money you had. But as soon as your bank had more than one teller, then more than one building, then maybe not even in the same city, suddenly the instantaneous balance of your checking account was a little more ambiguous than either your bank or your creditors were comfortable with. Even with modern communications, speed of light being what it is.
This classic pedagogical example is actually pretty crappy, because in real-life it happens all the time. Either the bank overdraws your account and then sends some leg breakers to your house, or in the case of electronic transfers, the transfer is held pending until the bank's central computer can figure out whether or not you're a deadbeat writing cold checks. In the former case the bank tries to fix the problem after the fact. In the latter case they're deferring the problem until they've had some time to ponder it. (This is also why you can order something online from Amazon.com but get email later saying "Oops, sorry, it's actually out of stock.") But in principle anyway, the example points out the issue in a context that is pretty easily understood.
So when developers understand this problem in the abstract (and most do), and if they've done some development in a language like Java that natively supports multithreading, their answer regarding execution synchronization might be "use the synchronize keyword". If they have used a POSIX thread library, it might be "use a mutex" (where "mutex" is used by those in the know as shorthand for mutual exclusion). If they know what SQL stands for, they might say "use a lock" or "a transaction". If they are really really old (but not as old as me) they might say "use a semaphore" or even "a monitor".
These are all software mechanisms that prevent more than one thread of control from executing a function or reading and modifying a variable simultaneously, or (as those in the know like to say) concurrently. In our canonical pedagogical example, each teller checking your bank balance was a separate thread of control operating concurrently.
But those answers just beg the question. When asked "how does the synchronize keyword (or semaphore, etc.) work?" typically we're back to "I dunno" or "it's the operating system's problem". If you keep asking "How?", peeling back layers and layers of software, down through the application, through the programming language, the library, the operating system, eventually you will discover that there is some mechanism down near the level of bare metal, often a single machine instruction, that actually does the heavy lifting of execution synchronization, insuring that two threads of control can't read and modify the same location location in memory by each reading it and then each modifying it, just like the checking account. All those other software synchronization mechanisms are ultimately built on top of this one low level hardware synchronization mechanism.
It was not always thus. I remember stories in the 1970s, when I first started having to worry about this stuff, about how the IBM mainframe development folks who were looking at the very earliest multiprocessor designs figured out they needed what generically became known as a test and set instruction. Test and set was a machine instruction that simultaneously remembered what the value of a memory location was and changed its value, and it did those two operations indivisibly, or (by those in the know) atomically. It was the machine instruction equivalent to the checking account example, checking the balance and deducting if funds were sufficient, except it was operating on just a byte or word of memory. This machine instruction was used to insure that, many layers of software above, code that was in fact checking your bank balance and deducting funds did so safely by allowing only one thread of control to do so at a time.
Eventually on the IBM mainframe the test and set instruction was replaced with the compare and swap instruction because it solved a larger class of execution synchronization problems. But to this day, decades later, machine instructions or their equivalents, on widely different processor architectures, used for implementing mutual exclusion operators like semaphores, are referred to as test and set, compare and swap, or something similar.
(Above: Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual", Volume 1, 325462-043US, May 2012, pages 7-6 through 7-7)
(Above: Freescale Semiconductor, "Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture", Revision 3, MPCFPE32B, September 2005, page D-3)
(Above: ARM, "ARM Architecture Reference Manual", ARM v7-A and ARM V7-R Edition, ID120611, 2011, page A8-432)
Recent versions of the GNU C compiler even have a built-in function called
__sync_lock_test_and_set()
that attempts to generate code for the underlying processor using whatever that hardware's native mechanism is at the machine code level, in a kind of homage to this decades old invention, now in a portable open source form.
Sometimes there is an otherwise innocuous machine instruction that just happens to be perfectly useful as test and set. For example, the DEC PDP-11 minicomputer had a decrement or dec instruction which atomically altered memory and set the condition code bits in the global hardware status register. You could set a memory location representing a lock to a value larger than zero to represent "unlocked", the value zero to represent "just locked", and a negative number to mean "already locked by someone else". You would use the dec instruction to decrement a word in memory and afterwards check the condition code by using a branch on condition instruction; if the result was zero, that meant the value had been positive before your decrement, hence you now own the resource that it represents; if the result was negative, someone had already locked it. You unlocked the memory location by using the increment or inc instruction. The value of the word in memory could be interpreted as a count of the number of resources available, so values larger than one could be used to implement a counting semaphore instead of just a mutex semaphore, representing, say, a pool of buffers. I have no idea if the PDP-11 hardware architects intended for inc and dec to be used this way, but it seems likely.
Sometimes there is no hardware execution synchronization mechanism at all. The IBM folks really only needed the test and set instruction when they started looking at multiprocessor systems. Before then, the only concurrency that could occur within a uniprocessor system was with an interrupt service routine or ISR. A hardware signal interrupts the normal flow of instruction execution and control is automatically passed to a special function or ISR that handles whatever the signal represents, like "a character is available because someone typed it on the keyboard". It is essentially a case of the hardware calling a subroutine. It is how input and output (and lots of other asynchronous and real-time stuff) is handled in most modern hardware architectures. This could result in the same kinds of concurrency issues if both the ISR and the code it interrupted read and modified the same variable in memory. In the uniprocessor cases, it was merely necessary to temporarily disable interrupts when the software knew it was in section of code in which it was critical that a sequence of operations, like reading and modifying a particular variable, be done atomically. Such a segment of code is called (those in the know again) a critical section.
This technique persists today in, for example on the tiny Atmel megaAVR microcontrollers I've been noodling with recently. Since they are uniprocessors, it is enough to disable interrupts going into a critical section using the cli machine instruction that clears the system-wide interrupt enable bit (the I-bit) in the system status register (SREG), and to reenable interrupts when exiting the critical section by using the sei machine instruction that sets the system-wide interrupt enable bit.
But that's not typically what megaAVR code does. If you have nested critical sections (easily done when you're calling subroutines from inside a critical section and they too have their own critical sections), you don't want to reenable interrupts when you exit the inner critical section because they weren't enabled when you first entered the inner critical section. You want to return the interrupt state to whatever it was before you entered your critical section, understanding that it might have already been disabled by whoever called you. So most megaAVR code (including mine) implements critical sections in C like this:
unsigned char temp = SREG;
cli();
/* Critical section code goes here. */
SREG = temp;
Entering the critical section, we read and store SREG (which is memory mapped, meaning hardware allows us to access it like a memory location; other processor architectures have a special machine instruction just to do this) containing the I-bit in a temporary variable, and then we disable interrupts by clearing the I-bit in SREG using cli(). Exiting the critical section, we don't enable interrupts by setting the I-bit using sei(). We instead restore SREG using the saved copy in our temporary variable, returning the I-bit to whatever its prior value was. It will have been a one (1) if the caller was not already in a critical section, zero (0) if it was.
So, are we good?
No, not really. You may have noticed that there's actually an issue here. If an ISR were to interrupt this code snippet after the SREG has been read, but before cli() disables interrupts -- which is entirely possible, because by definition we haven't disabled interrupts yet -- the ISR could change the value of SREG (there are after all seven other bits in SREG that mean other things). When we restore the value of SREG as we exit our critical section, we're restoring it to its value before we read it, not the value to which the ISR modified it after we read it. This is known as a race condition: two separate threads of control coming into conflict over the value of a shared variable because their use of it was not properly synchronized. Ironically, though, this race condition occurs in our synchronization mechanism, the very mechanism intended to prevent race conditions from occurring. (It's called a race condition because the outcome is timing dependent and hence non-deterministic: it depends on which thread of control wins the data race to change the variable.)
How does the megaAVR solve this problem? I don't think it does. In practice, this typically isn't an issue. I've never had a reason for an ISR to modify the value of SREG. Although I should point out that every ISR implicitly modifies SREG: the megaAVR hardware automatically clears the I-flag when entering an ISR, and the return from interrupt (reti) machine instruction automatically sets the I-flag when the ISR exits. This is so an ISR cannot itself be interrupted. Unlike other architectures (like my beloved PDP-11) this is not done by saving and restoring SREG on the stack, but by actually altering the I-bit in the SREG. This is possible because the ISR could not have been entered in the first place had the I-bit not already been set. But it still behooves the developer not to otherwise alter SREG inside the ISR lest wackiness ensue.
When you've spent enough time writing code close to bare metal like I have, you too will begin to look with skepticism at even the lowest level of operations of whatever processor you are using, asking yourself "how does this really work under the hood?" You will find yourself spending hours peering at eight hundred page processor reference manuals. I call that a good thing. Your mileage may vary.
Both then and now, if you asked a random software developer how did their language perform execution synchronization among multiple threads of control (or tasks, or processes, or execution contexts, or whatever damn thing their problem domain wants to call it), the typical answer would be "I dunno" or "isn't that the operating system's job?" or "what's a task?".
But most developers at least understand the basic problem in the abstract. The classic pedagogical example is your checking account. If two people are each independently trying to cash checks for $100 that you wrote when your account contains just $150, somehow the action of reading your balance to check for sufficient funds and then modifying your balance to withdraw the money has to be indivisible. Otherwise person A could check for sufficient funds, then person B could check, then person A gets their money, then person B, even though your account doesn't actually have of enough cash to cover both checks.
This wasn't a problem when there was only one bank, in one building, with one ledger book. The ledger was the final arbiter of how much money you had. But as soon as your bank had more than one teller, then more than one building, then maybe not even in the same city, suddenly the instantaneous balance of your checking account was a little more ambiguous than either your bank or your creditors were comfortable with. Even with modern communications, speed of light being what it is.
This classic pedagogical example is actually pretty crappy, because in real-life it happens all the time. Either the bank overdraws your account and then sends some leg breakers to your house, or in the case of electronic transfers, the transfer is held pending until the bank's central computer can figure out whether or not you're a deadbeat writing cold checks. In the former case the bank tries to fix the problem after the fact. In the latter case they're deferring the problem until they've had some time to ponder it. (This is also why you can order something online from Amazon.com but get email later saying "Oops, sorry, it's actually out of stock.") But in principle anyway, the example points out the issue in a context that is pretty easily understood.
So when developers understand this problem in the abstract (and most do), and if they've done some development in a language like Java that natively supports multithreading, their answer regarding execution synchronization might be "use the synchronize keyword". If they have used a POSIX thread library, it might be "use a mutex" (where "mutex" is used by those in the know as shorthand for mutual exclusion). If they know what SQL stands for, they might say "use a lock" or "a transaction". If they are really really old (but not as old as me) they might say "use a semaphore" or even "a monitor".
These are all software mechanisms that prevent more than one thread of control from executing a function or reading and modifying a variable simultaneously, or (as those in the know like to say) concurrently. In our canonical pedagogical example, each teller checking your bank balance was a separate thread of control operating concurrently.
But those answers just beg the question. When asked "how does the synchronize keyword (or semaphore, etc.) work?" typically we're back to "I dunno" or "it's the operating system's problem". If you keep asking "How?", peeling back layers and layers of software, down through the application, through the programming language, the library, the operating system, eventually you will discover that there is some mechanism down near the level of bare metal, often a single machine instruction, that actually does the heavy lifting of execution synchronization, insuring that two threads of control can't read and modify the same location location in memory by each reading it and then each modifying it, just like the checking account. All those other software synchronization mechanisms are ultimately built on top of this one low level hardware synchronization mechanism.
It was not always thus. I remember stories in the 1970s, when I first started having to worry about this stuff, about how the IBM mainframe development folks who were looking at the very earliest multiprocessor designs figured out they needed what generically became known as a test and set instruction. Test and set was a machine instruction that simultaneously remembered what the value of a memory location was and changed its value, and it did those two operations indivisibly, or (by those in the know) atomically. It was the machine instruction equivalent to the checking account example, checking the balance and deducting if funds were sufficient, except it was operating on just a byte or word of memory. This machine instruction was used to insure that, many layers of software above, code that was in fact checking your bank balance and deducting funds did so safely by allowing only one thread of control to do so at a time.
Eventually on the IBM mainframe the test and set instruction was replaced with the compare and swap instruction because it solved a larger class of execution synchronization problems. But to this day, decades later, machine instructions or their equivalents, on widely different processor architectures, used for implementing mutual exclusion operators like semaphores, are referred to as test and set, compare and swap, or something similar.
(Above: Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual", Volume 1, 325462-043US, May 2012, pages 7-6 through 7-7)
(Above: Freescale Semiconductor, "Programming Environments Manual for 32-bit Implementations of the PowerPC Architecture", Revision 3, MPCFPE32B, September 2005, page D-3)
(Above: ARM, "ARM Architecture Reference Manual", ARM v7-A and ARM V7-R Edition, ID120611, 2011, page A8-432)
Recent versions of the GNU C compiler even have a built-in function called
__sync_lock_test_and_set()
that attempts to generate code for the underlying processor using whatever that hardware's native mechanism is at the machine code level, in a kind of homage to this decades old invention, now in a portable open source form.
Sometimes there is an otherwise innocuous machine instruction that just happens to be perfectly useful as test and set. For example, the DEC PDP-11 minicomputer had a decrement or dec instruction which atomically altered memory and set the condition code bits in the global hardware status register. You could set a memory location representing a lock to a value larger than zero to represent "unlocked", the value zero to represent "just locked", and a negative number to mean "already locked by someone else". You would use the dec instruction to decrement a word in memory and afterwards check the condition code by using a branch on condition instruction; if the result was zero, that meant the value had been positive before your decrement, hence you now own the resource that it represents; if the result was negative, someone had already locked it. You unlocked the memory location by using the increment or inc instruction. The value of the word in memory could be interpreted as a count of the number of resources available, so values larger than one could be used to implement a counting semaphore instead of just a mutex semaphore, representing, say, a pool of buffers. I have no idea if the PDP-11 hardware architects intended for inc and dec to be used this way, but it seems likely.
Sometimes there is no hardware execution synchronization mechanism at all. The IBM folks really only needed the test and set instruction when they started looking at multiprocessor systems. Before then, the only concurrency that could occur within a uniprocessor system was with an interrupt service routine or ISR. A hardware signal interrupts the normal flow of instruction execution and control is automatically passed to a special function or ISR that handles whatever the signal represents, like "a character is available because someone typed it on the keyboard". It is essentially a case of the hardware calling a subroutine. It is how input and output (and lots of other asynchronous and real-time stuff) is handled in most modern hardware architectures. This could result in the same kinds of concurrency issues if both the ISR and the code it interrupted read and modified the same variable in memory. In the uniprocessor cases, it was merely necessary to temporarily disable interrupts when the software knew it was in section of code in which it was critical that a sequence of operations, like reading and modifying a particular variable, be done atomically. Such a segment of code is called (those in the know again) a critical section.
This technique persists today in, for example on the tiny Atmel megaAVR microcontrollers I've been noodling with recently. Since they are uniprocessors, it is enough to disable interrupts going into a critical section using the cli machine instruction that clears the system-wide interrupt enable bit (the I-bit) in the system status register (SREG), and to reenable interrupts when exiting the critical section by using the sei machine instruction that sets the system-wide interrupt enable bit.
But that's not typically what megaAVR code does. If you have nested critical sections (easily done when you're calling subroutines from inside a critical section and they too have their own critical sections), you don't want to reenable interrupts when you exit the inner critical section because they weren't enabled when you first entered the inner critical section. You want to return the interrupt state to whatever it was before you entered your critical section, understanding that it might have already been disabled by whoever called you. So most megaAVR code (including mine) implements critical sections in C like this:
unsigned char temp = SREG;
cli();
/* Critical section code goes here. */
SREG = temp;
Entering the critical section, we read and store SREG (which is memory mapped, meaning hardware allows us to access it like a memory location; other processor architectures have a special machine instruction just to do this) containing the I-bit in a temporary variable, and then we disable interrupts by clearing the I-bit in SREG using cli(). Exiting the critical section, we don't enable interrupts by setting the I-bit using sei(). We instead restore SREG using the saved copy in our temporary variable, returning the I-bit to whatever its prior value was. It will have been a one (1) if the caller was not already in a critical section, zero (0) if it was.
So, are we good?
No, not really. You may have noticed that there's actually an issue here. If an ISR were to interrupt this code snippet after the SREG has been read, but before cli() disables interrupts -- which is entirely possible, because by definition we haven't disabled interrupts yet -- the ISR could change the value of SREG (there are after all seven other bits in SREG that mean other things). When we restore the value of SREG as we exit our critical section, we're restoring it to its value before we read it, not the value to which the ISR modified it after we read it. This is known as a race condition: two separate threads of control coming into conflict over the value of a shared variable because their use of it was not properly synchronized. Ironically, though, this race condition occurs in our synchronization mechanism, the very mechanism intended to prevent race conditions from occurring. (It's called a race condition because the outcome is timing dependent and hence non-deterministic: it depends on which thread of control wins the data race to change the variable.)
How does the megaAVR solve this problem? I don't think it does. In practice, this typically isn't an issue. I've never had a reason for an ISR to modify the value of SREG. Although I should point out that every ISR implicitly modifies SREG: the megaAVR hardware automatically clears the I-flag when entering an ISR, and the return from interrupt (reti) machine instruction automatically sets the I-flag when the ISR exits. This is so an ISR cannot itself be interrupted. Unlike other architectures (like my beloved PDP-11) this is not done by saving and restoring SREG on the stack, but by actually altering the I-bit in the SREG. This is possible because the ISR could not have been entered in the first place had the I-bit not already been set. But it still behooves the developer not to otherwise alter SREG inside the ISR lest wackiness ensue.
When you've spent enough time writing code close to bare metal like I have, you too will begin to look with skepticism at even the lowest level of operations of whatever processor you are using, asking yourself "how does this really work under the hood?" You will find yourself spending hours peering at eight hundred page processor reference manuals. I call that a good thing. Your mileage may vary.
Updates
To contact us Click HERE
When I followup on a past project about which I've written, I always face the quandary whether to update the original article or write a new one. Neither is a perfect solution. The former means folks who have bookmarked that article for future reference or folks finding the article for the first time via a search engine will see the new material. The latter means folks using an RSS feed will see the update. I tend to choose the former, updating the article, and if the update is separated from the original by a long time, I date stamp the new material so as to not confuse the elderly (like me). But to accommodate the folks who depend on their RSS reader, here's some articles I've recently updated.
The C++ Pointer to Member Operators: Based on feedback from readers, I added a short paragraph at the end to explain why one would want to use these operators. These operators, which really don't use pointers to an object but instead offsets into a class, are better than the most likely alternative.
Small Town Big City: I added a section at the end on running Amigo, my FreeRTOS-based interrupt-driven multitasking platform written in C++, to an Arduino Mega ADK with an Ethernet shield and a FreeRTOS EtherTen Uno-clone. Yes, I got a multitasking system running on the ATmega328p-based EtherTen with it's severe resource constraints. It wasn't pretty. I don't recommend it. Co-routines or state machines are likely to be a better solution; they are less scalable, and probably more expensive in the long-run to maintain, but scalability isn't likely to be an issue for the tiny ATmega328p with it's scant two kilobytes of SRAM.
Sunshine On My Arduino Makes Me Happy: I've documented several additional iterations on my solar powered Arduino Uno. The latest version uses a solar charge regulator and a sealed 12V gel cell battery in addition to the solar panel. I'm skeptical that my small battery and solar panel (I definitely went the inexpensive route) are sufficient to keep this system running indefinitely, particularly when the solar panel is just sitting in a south-facing window. But so far it's has run for the past nineteen hours, since about 14:00MDT yesterday. And Colorado has more sunny days than any other state in the Union. Sorry, California.
The C++ Pointer to Member Operators: Based on feedback from readers, I added a short paragraph at the end to explain why one would want to use these operators. These operators, which really don't use pointers to an object but instead offsets into a class, are better than the most likely alternative.
Small Town Big City: I added a section at the end on running Amigo, my FreeRTOS-based interrupt-driven multitasking platform written in C++, to an Arduino Mega ADK with an Ethernet shield and a FreeRTOS EtherTen Uno-clone. Yes, I got a multitasking system running on the ATmega328p-based EtherTen with it's severe resource constraints. It wasn't pretty. I don't recommend it. Co-routines or state machines are likely to be a better solution; they are less scalable, and probably more expensive in the long-run to maintain, but scalability isn't likely to be an issue for the tiny ATmega328p with it's scant two kilobytes of SRAM.
Sunshine On My Arduino Makes Me Happy: I've documented several additional iterations on my solar powered Arduino Uno. The latest version uses a solar charge regulator and a sealed 12V gel cell battery in addition to the solar panel. I'm skeptical that my small battery and solar panel (I definitely went the inexpensive route) are sufficient to keep this system running indefinitely, particularly when the solar panel is just sitting in a south-facing window. But so far it's has run for the past nineteen hours, since about 14:00MDT yesterday. And Colorado has more sunny days than any other state in the Union. Sorry, California.
The Developer's Dilemma
To contact us Click HERE
The police arrest you and your buddy. They place you in separate interrogation rooms. They suspect you both of a crime but don't have enough evidence to convict you. The cop questioning you offers you a deal: you rat out your accomplish and you get a reduced sentence. Of course, you know another cop is making the same offer to your buddy. If only one of you confesses, the stool pigeon is charged with a misdemeanor and goes free while the other guy is sentenced to a full year in the big house. If you both confess, you'll each do six months. If neither of you confesses, the best they can do on the evidence they have is charge you both with a lesser crime for which you'll each do one month.
This scenario is familiar to anyone to watches crime shows on television, reads police procedurals, or sees pretty much any movie by Martin Scorsese. It is also an example of one of the fundamental games of game theory called the prisoner's dilemma. As the police well know, the dominant strategy is for you to confess: it's the strategy that has the best outcome for you without having to depend on what the other guy does or doesn't do. It allows you to be indifferent to his strategy.
But that doesn't mean it's the best outcome, period. It is also unfortunately the dominant strategy for your buddy. If you both confess, you'll both do six months. It would be far better if both of you kept your mouths shut. The dominant strategy is inefficient because it motivates you both to achieve a sub-optimal outcome. But to do better requires cooperation and trust in your accomplice. This is tough because, as they say, there is no honor among thieves. The prisoner's dilemma is one of the reasons for omertà , the Mafia's code of silence: it alters the payout for both parties to make it more likely that they will not betray one another. The stool pigeon's life isn't worth a plug nickel.
The prisoner's dilemma is widely discussed because it occurs so frequently in real life. The classic example is the nuclear arms race. The dominant strategy for each adversary is to launch a pre-emptive nuclear strike. But if both follow their dominant strategies, to say the outcome is sub-optimal is putting it mildly. Game theory played an important role in framing the strategy of nuclear deterrence for the United States and, one must assume, the Soviet Union. It is probably no coincidence that Merrill Flood and Melvin Dresher of the RAND Corporation first formally framed the prisoner's dilemma the year after the Soviets detonated their first atomic bomb. [1]
There are lots of other real life example. Like the one you may find yourself in right now as a software developer. Don't think so? Consider this: the company you work for probably has a fixed raise or bonus pool to distribute amongst you and your peers. Every dollar the person next to you gets is one dollar you won't get. There are only so many slots into which people may be promoted. Every slot filled with someone else is a slot that is no longer available to you. Many companies use a strategy of forced ranking, where a manager must rank a certain percentage of his employees into the lowest rating tier for use when the layoffs inevitably occur. Someone has to go in that tier no matter that their actual performance in absolute terms may be. This is called a zero-sum game: everyone's gain is balanced by someone else's loss. [2] Like it or not, your employer's human resources polices force you to compete with the developer sitting across from you. Your dominant strategy is to betray him.
But that's not the optimal strategy. Even though your company's incentive program is tragically designed to motivate you to do otherwise, both you and your fellow developer will do better if you cooperate and work together. Your joint efforts will produce a product that will be more successful, the customers will be happier, and your employer will make more money. All this because you chose to cooperate instead of compete, and despite the fact that your company is telling you to act otherwise.
I spent several years working in an organization in which our director thought competition is good (his exact words) and encouraged it among the various groups under his management. This, despite the fact that each group played a different role, and to succeed we all had to work together to support one another. Treating his groups like interchangeable commodities drove tremendous dysfunction into that organization, and highly politicized the work environment. As a manager I spent most of my time trying to shield my troops from this while attempting to get my peer managers to actually fulfill their official responsibilities. I don't miss it. Later I worked in an organization that used forced ranking. It was interesting to watch developers attempt to game the system, occasionally by screwing one another. I don't miss that, either.
How does one escape from the prisoner's dilemma? Much of game theory is about techniques and strategies to encourage cooperation among the players. Robert Axelrod of the University of Michigan held a prisoner's dilemma competition: entries were computer programs that played against one another for multiple rounds, deciding in each round whether to defect (betray or confess), or cooperate (stay silent). The winning algorithm was tit-for-tat: the program always began by cooperating; if its opponent defected, the program defected in the next round, but immediately returned to cooperating in the following round. [3]
Avinash Dixit and Barry Nalebuff illustrate the problem with this strategy: when it plays against itself, and its opponent defects just once, it falls into a perpetual pattern of alternating defection with cooperation. How can its opponent defect just once? Because in real-life, honest mistakes happen, due to misunderstandings and miscommunication. A better strategy, according to Dixit and Nalebuff, is to base your decision on both short-term and long-term memory of your opponent's past decisions, a version of which Scott Stevens has called tit-for-two-tats.
But regardless of the specifics, Stevens points out that tit-for-tat-like strategies that perform well in the repeated prisoner's dilemma game all have four characteristics:
I first became interested in game theory back in the 1990s when I was working on very large real-time distributed telecommunications systems. The game trees (for sequential games) and game tables (for simultaneous games) from game theory gave me a more structured way to think about error detection and recovery, particularly with regards to communication channels to other systems. I was surprised to find, when I started looking at incentive programs for software developers, that game theory played a key role there as well. Game theory is a topic that once you begin to read about it, you see it everywhere. It is a social science that studies strategic decision making. And the games that it studies permeate our lives.
Once I realized that I was routinely caught in a developer's dilemma, the tit-for-tat strategies gave me a useful approach to deal with it. Studying game theory has led me to be nicer, more provokable, more forgiving (that was the hard one, for me), and more straightforward. I'm not exaggerating when I say it's made me a better person.
Footnotes
[1] The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy.
[2] Strictly speaking, forced ranking isn't zero-sum. For a game to be zero-sum, not only does every win have to be offset by a loss of equal value, but there must be no way for all players to come out ahead. But if all employees who are ranked relative to one another could enter into an enforceable collective agreement in which they each agreed to work less hard, their forced ranking relative to one another would remain unchanged while they each applied the absolute minimum amount of effort necessary to keep their jobs. While it is hard to believe that this is what their employer intended, it is in fact the most efficient outcome for the forced ranking game.
[3] The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality.
Sources
Wikipedia, Game theory, 2012
Wikipedia, Prisoner's dilemma, 2012
Wikipedia, Fermi paradox, 2012
Avinash K. Dixit and Barry J. Nalebuff, The Art of Strategy, W. W. Norton, 2008
Scott P. Stevens, Games People Play, The Teaching Company, 2008
Robert D. Austin, Measuring and Managing Performance in Organizations, Dorset House, 1996
Avinash K. Dixit and Barry J. Nalebuff, Thinking Strategically, W. W. Norton, 1991
Lawrence Lasker et al., WarGames, MGM, 1983
James Bridges, D. F. Jones, Colossus: The Forbin Project, Universal Pictures, 1970
This scenario is familiar to anyone to watches crime shows on television, reads police procedurals, or sees pretty much any movie by Martin Scorsese. It is also an example of one of the fundamental games of game theory called the prisoner's dilemma. As the police well know, the dominant strategy is for you to confess: it's the strategy that has the best outcome for you without having to depend on what the other guy does or doesn't do. It allows you to be indifferent to his strategy.
But that doesn't mean it's the best outcome, period. It is also unfortunately the dominant strategy for your buddy. If you both confess, you'll both do six months. It would be far better if both of you kept your mouths shut. The dominant strategy is inefficient because it motivates you both to achieve a sub-optimal outcome. But to do better requires cooperation and trust in your accomplice. This is tough because, as they say, there is no honor among thieves. The prisoner's dilemma is one of the reasons for omertà , the Mafia's code of silence: it alters the payout for both parties to make it more likely that they will not betray one another. The stool pigeon's life isn't worth a plug nickel.
The prisoner's dilemma is widely discussed because it occurs so frequently in real life. The classic example is the nuclear arms race. The dominant strategy for each adversary is to launch a pre-emptive nuclear strike. But if both follow their dominant strategies, to say the outcome is sub-optimal is putting it mildly. Game theory played an important role in framing the strategy of nuclear deterrence for the United States and, one must assume, the Soviet Union. It is probably no coincidence that Merrill Flood and Melvin Dresher of the RAND Corporation first formally framed the prisoner's dilemma the year after the Soviets detonated their first atomic bomb. [1]
There are lots of other real life example. Like the one you may find yourself in right now as a software developer. Don't think so? Consider this: the company you work for probably has a fixed raise or bonus pool to distribute amongst you and your peers. Every dollar the person next to you gets is one dollar you won't get. There are only so many slots into which people may be promoted. Every slot filled with someone else is a slot that is no longer available to you. Many companies use a strategy of forced ranking, where a manager must rank a certain percentage of his employees into the lowest rating tier for use when the layoffs inevitably occur. Someone has to go in that tier no matter that their actual performance in absolute terms may be. This is called a zero-sum game: everyone's gain is balanced by someone else's loss. [2] Like it or not, your employer's human resources polices force you to compete with the developer sitting across from you. Your dominant strategy is to betray him.
But that's not the optimal strategy. Even though your company's incentive program is tragically designed to motivate you to do otherwise, both you and your fellow developer will do better if you cooperate and work together. Your joint efforts will produce a product that will be more successful, the customers will be happier, and your employer will make more money. All this because you chose to cooperate instead of compete, and despite the fact that your company is telling you to act otherwise.
I spent several years working in an organization in which our director thought competition is good (his exact words) and encouraged it among the various groups under his management. This, despite the fact that each group played a different role, and to succeed we all had to work together to support one another. Treating his groups like interchangeable commodities drove tremendous dysfunction into that organization, and highly politicized the work environment. As a manager I spent most of my time trying to shield my troops from this while attempting to get my peer managers to actually fulfill their official responsibilities. I don't miss it. Later I worked in an organization that used forced ranking. It was interesting to watch developers attempt to game the system, occasionally by screwing one another. I don't miss that, either.
How does one escape from the prisoner's dilemma? Much of game theory is about techniques and strategies to encourage cooperation among the players. Robert Axelrod of the University of Michigan held a prisoner's dilemma competition: entries were computer programs that played against one another for multiple rounds, deciding in each round whether to defect (betray or confess), or cooperate (stay silent). The winning algorithm was tit-for-tat: the program always began by cooperating; if its opponent defected, the program defected in the next round, but immediately returned to cooperating in the following round. [3]
Avinash Dixit and Barry Nalebuff illustrate the problem with this strategy: when it plays against itself, and its opponent defects just once, it falls into a perpetual pattern of alternating defection with cooperation. How can its opponent defect just once? Because in real-life, honest mistakes happen, due to misunderstandings and miscommunication. A better strategy, according to Dixit and Nalebuff, is to base your decision on both short-term and long-term memory of your opponent's past decisions, a version of which Scott Stevens has called tit-for-two-tats.
But regardless of the specifics, Stevens points out that tit-for-tat-like strategies that perform well in the repeated prisoner's dilemma game all have four characteristics:
- They are nice: they always begin by trusting.
- They are provokable: they always punish by betraying if they themselves are betrayed.
- They are forgiving: even though betrayed, they can eventually return to cooperating.
- They are straightforward: their strategy is rational, transparent, and easily understood.
I first became interested in game theory back in the 1990s when I was working on very large real-time distributed telecommunications systems. The game trees (for sequential games) and game tables (for simultaneous games) from game theory gave me a more structured way to think about error detection and recovery, particularly with regards to communication channels to other systems. I was surprised to find, when I started looking at incentive programs for software developers, that game theory played a key role there as well. Game theory is a topic that once you begin to read about it, you see it everywhere. It is a social science that studies strategic decision making. And the games that it studies permeate our lives.
Once I realized that I was routinely caught in a developer's dilemma, the tit-for-tat strategies gave me a useful approach to deal with it. Studying game theory has led me to be nicer, more provokable, more forgiving (that was the hard one, for me), and more straightforward. I'm not exaggerating when I say it's made me a better person.
Footnotes
[1] The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy.
[2] Strictly speaking, forced ranking isn't zero-sum. For a game to be zero-sum, not only does every win have to be offset by a loss of equal value, but there must be no way for all players to come out ahead. But if all employees who are ranked relative to one another could enter into an enforceable collective agreement in which they each agreed to work less hard, their forced ranking relative to one another would remain unchanged while they each applied the absolute minimum amount of effort necessary to keep their jobs. While it is hard to believe that this is what their employer intended, it is in fact the most efficient outcome for the forced ranking game.
[3] The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality.
Sources
Wikipedia, Game theory, 2012
Wikipedia, Prisoner's dilemma, 2012
Wikipedia, Fermi paradox, 2012
Avinash K. Dixit and Barry J. Nalebuff, The Art of Strategy, W. W. Norton, 2008
Scott P. Stevens, Games People Play, The Teaching Company, 2008
Robert D. Austin, Measuring and Managing Performance in Organizations, Dorset House, 1996
Avinash K. Dixit and Barry J. Nalebuff, Thinking Strategically, W. W. Norton, 1991
Lawrence Lasker et al., WarGames, MGM, 1983
James Bridges, D. F. Jones, Colossus: The Forbin Project, Universal Pictures, 1970
The Prisoner's Dilemma, the Fermi Paradox, and War Games
To contact us Click HERE
I have enough life experience and self-knowledge to recognize when I'm being totally intellectually obsessive on some topic. And for sure, when I start to quote myself I've reached some critical threshold of narcissism. But never the less, here are some footnotes that I added to a recent blog article (which was only peripherally on this topic) that I'm reposting here because I'm so enamored with these ideas.
"The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy."
"The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality."
Let's all hope I get over this once I've finished reading Dixit and Nalebuff''s book Thinking Strategically.
"The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy."
"The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality."
Let's all hope I get over this once I've finished reading Dixit and Nalebuff''s book Thinking Strategically.
8 Temmuz 2012 Pazar
The Developer's Dilemma
To contact us Click HERE
The police arrest you and your buddy. They place you in separate interrogation rooms. They suspect you both of a crime but don't have enough evidence to convict you. The cop questioning you offers you a deal: you rat out your accomplish and you get a reduced sentence. Of course, you know another cop is making the same offer to your buddy. If only one of you confesses, the stool pigeon is charged with a misdemeanor and goes free while the other guy is sentenced to a full year in the big house. If you both confess, you'll each do six months. If neither of you confesses, the best they can do on the evidence they have is charge you both with a lesser crime for which you'll each do one month.
This scenario is familiar to anyone to watches crime shows on television, reads police procedurals, or sees pretty much any movie by Martin Scorsese. It is also an example of one of the fundamental games of game theory called the prisoner's dilemma. As the police well know, the dominant strategy is for you to confess: it's the strategy that has the best outcome for you without having to depend on what the other guy does or doesn't do. It allows you to be indifferent to his strategy.
But that doesn't mean it's the best outcome, period. It is also unfortunately the dominant strategy for your buddy. If you both confess, you'll both do six months. It would be far better if both of you kept your mouths shut. The dominant strategy is inefficient because it motivates you both to achieve a sub-optimal outcome. But to do better requires cooperation and trust in your accomplice. This is tough because, as they say, there is no honor among thieves. The prisoner's dilemma is one of the reasons for omertà , the Mafia's code of silence: it alters the payout for both parties to make it more likely that they will not betray one another. The stool pigeon's life isn't worth a plug nickel.
The prisoner's dilemma is widely discussed because it occurs so frequently in real life. The classic example is the nuclear arms race. The dominant strategy for each adversary is to launch a pre-emptive nuclear strike. But if both follow their dominant strategies, to say the outcome is sub-optimal is putting it mildly. Game theory played an important role in framing the strategy of nuclear deterrence for the United States and, one must assume, the Soviet Union. It is probably no coincidence that Merrill Flood and Melvin Dresher of the RAND Corporation first formally framed the prisoner's dilemma the year after the Soviets detonated their first atomic bomb. [1]
There are lots of other real life example. Like the one you may find yourself in right now as a software developer. Don't think so? Consider this: the company you work for probably has a fixed raise or bonus pool to distribute amongst you and your peers. Every dollar the person next to you gets is one dollar you won't get. There are only so many slots into which people may be promoted. Every slot filled with someone else is a slot that is no longer available to you. Many companies use a strategy of forced ranking, where a manager must rank a certain percentage of his employees into the lowest rating tier for use when the layoffs inevitably occur. Someone has to go in that tier no matter that their actual performance in absolute terms may be. This is called a zero-sum game: everyone's gain is balanced by someone else's loss. [2] Like it or not, your employer's human resources polices force you to compete with the developer sitting across from you. Your dominant strategy is to betray him.
But that's not the optimal strategy. Even though your company's incentive program is tragically designed to motivate you to do otherwise, both you and your fellow developer will do better if you cooperate and work together. Your joint efforts will produce a product that will be more successful, the customers will be happier, and your employer will make more money. All this because you chose to cooperate instead of compete, and despite the fact that your company is telling you to act otherwise.
I spent several years working in an organization in which our director thought competition is good (his exact words) and encouraged it among the various groups under his management. This, despite the fact that each group played a different role, and to succeed we all had to work together to support one another. Treating his groups like interchangeable commodities drove tremendous dysfunction into that organization, and highly politicized the work environment. As a manager I spent most of my time trying to shield my troops from this while attempting to get my peer managers to actually fulfill their official responsibilities. I don't miss it. Later I worked in an organization that used forced ranking. It was interesting to watch developers attempt to game the system, occasionally by screwing one another. I don't miss that, either.
How does one escape from the prisoner's dilemma? Much of game theory is about techniques and strategies to encourage cooperation among the players. Robert Axelrod of the University of Michigan held a prisoner's dilemma competition: entries were computer programs that played against one another for multiple rounds, deciding in each round whether to defect (betray or confess), or cooperate (stay silent). The winning algorithm was tit-for-tat: the program always began by cooperating; if its opponent defected, the program defected in the next round, but immediately returned to cooperating in the following round. [3]
Avinash Dixit and Barry Nalebuff illustrate the problem with this strategy: when it plays against itself, and its opponent defects just once, it falls into a perpetual pattern of alternating defection with cooperation. How can its opponent defect just once? Because in real-life, honest mistakes happen, due to misunderstandings and miscommunication. A better strategy, according to Dixit and Nalebuff, is to base your decision on both short-term and long-term memory of your opponent's past decisions, a version of which Scott Stevens has called tit-for-two-tats.
But regardless of the specifics, Stevens points out that tit-for-tat-like strategies that perform well in the repeated prisoner's dilemma game all have four characteristics:
I first became interested in game theory back in the 1990s when I was working on very large real-time distributed telecommunications systems. The game trees (for sequential games) and game tables (for simultaneous games) from game theory gave me a more structured way to think about error detection and recovery, particularly with regards to communication channels to other systems. I was surprised to find, when I started looking at incentive programs for software developers, that game theory played a key role there as well. Game theory is a topic that once you begin to read about it, you see it everywhere. It is a social science that studies strategic decision making. And the games that it studies permeate our lives.
Once I realized that I was routinely caught in a developer's dilemma, the tit-for-tat strategies gave me a useful approach to deal with it. Studying game theory has led me to be nicer, more provokable, more forgiving (that was the hard one, for me), and more straightforward. I'm not exaggerating when I say it's made me a better person.
Footnotes
[1] The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy.
[2] Strictly speaking, forced ranking isn't zero-sum. For a game to be zero-sum, not only does every win have to be offset by a loss of equal value, but there must be no way for all players to come out ahead. But if all employees who are ranked relative to one another could enter into an enforceable collective agreement in which they each agreed to work less hard, their forced ranking relative to one another would remain unchanged while they each applied the absolute minimum amount of effort necessary to keep their jobs. While it is hard to believe that this is what their employer intended, it is in fact the most efficient outcome for the forced ranking game.
[3] The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality.
Sources
Wikipedia, Game theory, 2012
Wikipedia, Prisoner's dilemma, 2012
Wikipedia, Fermi paradox, 2012
Avinash K. Dixit and Barry J. Nalebuff, The Art of Strategy, W. W. Norton, 2008
Scott P. Stevens, Games People Play, The Teaching Company, 2008
Robert D. Austin, Measuring and Managing Performance in Organizations, Dorset House, 1996
Avinash K. Dixit and Barry J. Nalebuff, Thinking Strategically, W. W. Norton, 1991
Lawrence Lasker et al., WarGames, MGM, 1983
James Bridges, D. F. Jones, Colossus: The Forbin Project, Universal Pictures, 1970
This scenario is familiar to anyone to watches crime shows on television, reads police procedurals, or sees pretty much any movie by Martin Scorsese. It is also an example of one of the fundamental games of game theory called the prisoner's dilemma. As the police well know, the dominant strategy is for you to confess: it's the strategy that has the best outcome for you without having to depend on what the other guy does or doesn't do. It allows you to be indifferent to his strategy.
But that doesn't mean it's the best outcome, period. It is also unfortunately the dominant strategy for your buddy. If you both confess, you'll both do six months. It would be far better if both of you kept your mouths shut. The dominant strategy is inefficient because it motivates you both to achieve a sub-optimal outcome. But to do better requires cooperation and trust in your accomplice. This is tough because, as they say, there is no honor among thieves. The prisoner's dilemma is one of the reasons for omertà , the Mafia's code of silence: it alters the payout for both parties to make it more likely that they will not betray one another. The stool pigeon's life isn't worth a plug nickel.
The prisoner's dilemma is widely discussed because it occurs so frequently in real life. The classic example is the nuclear arms race. The dominant strategy for each adversary is to launch a pre-emptive nuclear strike. But if both follow their dominant strategies, to say the outcome is sub-optimal is putting it mildly. Game theory played an important role in framing the strategy of nuclear deterrence for the United States and, one must assume, the Soviet Union. It is probably no coincidence that Merrill Flood and Melvin Dresher of the RAND Corporation first formally framed the prisoner's dilemma the year after the Soviets detonated their first atomic bomb. [1]
There are lots of other real life example. Like the one you may find yourself in right now as a software developer. Don't think so? Consider this: the company you work for probably has a fixed raise or bonus pool to distribute amongst you and your peers. Every dollar the person next to you gets is one dollar you won't get. There are only so many slots into which people may be promoted. Every slot filled with someone else is a slot that is no longer available to you. Many companies use a strategy of forced ranking, where a manager must rank a certain percentage of his employees into the lowest rating tier for use when the layoffs inevitably occur. Someone has to go in that tier no matter that their actual performance in absolute terms may be. This is called a zero-sum game: everyone's gain is balanced by someone else's loss. [2] Like it or not, your employer's human resources polices force you to compete with the developer sitting across from you. Your dominant strategy is to betray him.
But that's not the optimal strategy. Even though your company's incentive program is tragically designed to motivate you to do otherwise, both you and your fellow developer will do better if you cooperate and work together. Your joint efforts will produce a product that will be more successful, the customers will be happier, and your employer will make more money. All this because you chose to cooperate instead of compete, and despite the fact that your company is telling you to act otherwise.
I spent several years working in an organization in which our director thought competition is good (his exact words) and encouraged it among the various groups under his management. This, despite the fact that each group played a different role, and to succeed we all had to work together to support one another. Treating his groups like interchangeable commodities drove tremendous dysfunction into that organization, and highly politicized the work environment. As a manager I spent most of my time trying to shield my troops from this while attempting to get my peer managers to actually fulfill their official responsibilities. I don't miss it. Later I worked in an organization that used forced ranking. It was interesting to watch developers attempt to game the system, occasionally by screwing one another. I don't miss that, either.
How does one escape from the prisoner's dilemma? Much of game theory is about techniques and strategies to encourage cooperation among the players. Robert Axelrod of the University of Michigan held a prisoner's dilemma competition: entries were computer programs that played against one another for multiple rounds, deciding in each round whether to defect (betray or confess), or cooperate (stay silent). The winning algorithm was tit-for-tat: the program always began by cooperating; if its opponent defected, the program defected in the next round, but immediately returned to cooperating in the following round. [3]
Avinash Dixit and Barry Nalebuff illustrate the problem with this strategy: when it plays against itself, and its opponent defects just once, it falls into a perpetual pattern of alternating defection with cooperation. How can its opponent defect just once? Because in real-life, honest mistakes happen, due to misunderstandings and miscommunication. A better strategy, according to Dixit and Nalebuff, is to base your decision on both short-term and long-term memory of your opponent's past decisions, a version of which Scott Stevens has called tit-for-two-tats.
But regardless of the specifics, Stevens points out that tit-for-tat-like strategies that perform well in the repeated prisoner's dilemma game all have four characteristics:
- They are nice: they always begin by trusting.
- They are provokable: they always punish by betraying if they themselves are betrayed.
- They are forgiving: even though betrayed, they can eventually return to cooperating.
- They are straightforward: their strategy is rational, transparent, and easily understood.
I first became interested in game theory back in the 1990s when I was working on very large real-time distributed telecommunications systems. The game trees (for sequential games) and game tables (for simultaneous games) from game theory gave me a more structured way to think about error detection and recovery, particularly with regards to communication channels to other systems. I was surprised to find, when I started looking at incentive programs for software developers, that game theory played a key role there as well. Game theory is a topic that once you begin to read about it, you see it everywhere. It is a social science that studies strategic decision making. And the games that it studies permeate our lives.
Once I realized that I was routinely caught in a developer's dilemma, the tit-for-tat strategies gave me a useful approach to deal with it. Studying game theory has led me to be nicer, more provokable, more forgiving (that was the hard one, for me), and more straightforward. I'm not exaggerating when I say it's made me a better person.
Footnotes
[1] The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy.
[2] Strictly speaking, forced ranking isn't zero-sum. For a game to be zero-sum, not only does every win have to be offset by a loss of equal value, but there must be no way for all players to come out ahead. But if all employees who are ranked relative to one another could enter into an enforceable collective agreement in which they each agreed to work less hard, their forced ranking relative to one another would remain unchanged while they each applied the absolute minimum amount of effort necessary to keep their jobs. While it is hard to believe that this is what their employer intended, it is in fact the most efficient outcome for the forced ranking game.
[3] The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality.
Sources
Wikipedia, Game theory, 2012
Wikipedia, Prisoner's dilemma, 2012
Wikipedia, Fermi paradox, 2012
Avinash K. Dixit and Barry J. Nalebuff, The Art of Strategy, W. W. Norton, 2008
Scott P. Stevens, Games People Play, The Teaching Company, 2008
Robert D. Austin, Measuring and Managing Performance in Organizations, Dorset House, 1996
Avinash K. Dixit and Barry J. Nalebuff, Thinking Strategically, W. W. Norton, 1991
Lawrence Lasker et al., WarGames, MGM, 1983
James Bridges, D. F. Jones, Colossus: The Forbin Project, Universal Pictures, 1970
The Prisoner's Dilemma, the Fermi Paradox, and War Games
To contact us Click HERE
I have enough life experience and self-knowledge to recognize when I'm being totally intellectually obsessive on some topic. And for sure, when I start to quote myself I've reached some critical threshold of narcissism. But never the less, here are some footnotes that I added to a recent blog article (which was only peripherally on this topic) that I'm reposting here because I'm so enamored with these ideas.
"The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy."
"The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality."
Let's all hope I get over this once I've finished reading Dixit and Nalebuff''s book Thinking Strategically.
"The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy."
"The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality."
Let's all hope I get over this once I've finished reading Dixit and Nalebuff''s book Thinking Strategically.
Going Gentle Into That Good Night
To contact us Click HERE
My master's thesis was published in 1983. The text of the digital version was written using a word processing program called WordStar that ran on a microcomputer using a Motorola 6800 processor running the CP/M operating system and stored on eight-inch floppy disks. The source code for my software that I was writing about was stored on eight-inch floppies in RT-11 format and ran on a Digital Equipment Corporation PDP-11 running the RSX-11M operating system. I'm pretty sure none of that exists now.
If you absolutely had to recover that digital information, it would require tens or even hundreds of thousands of dollars, in terms of hardware, software, and time, if it could be done at all. You'd have to find eight-inch floppy drives, devise a way to hook them up to some modern computer, track down the description of the CP/M and RT-11 file system formats and the WordStar and RSX-11M file formats, implement both their documented behavior and the undocumented behavior, pray that the floppies were still readable nearly thirty years later, and hope that I didn't use some compression and/or encryption algorithm that was in vogue at the time.
The effort would be made somewhat more complicated by the fact that I threw away those eight-inch floppy disks years ago. But I do have a hardcopy of my thesis, which includes the text and the complete source listings, printed on acid free paper, and hardbound. If this tome were to survive fires, floods, and the inevitable collapse of civilization, it would likely still be readable a thousand years from now. If anyone cared. Which is highly unlikely.
So it is with preservation of digital information. While I can actually read an original book by Galileo, and make out the icons on a shard of four thousand year old Greek pottery, digital data are ephemeral. My enormous collection of motion picture and television soundtrack music on compact disk, about two thousand of them, has a shelf life. Estimates range from 100 years to as few as two years. And what are my chances of buying a new CD player twenty years from now? Let's ask the people who invested in eight-track tapes, cassette tapes, or any number of other media technologies that have gone by the wayside. It is a similar story for DVDs, nine-track magnetic tape, flash memory, and anything else that stores bits magnetically, optically, or electronically.
What's worse, it's not just the physical bits, it's what the bits mean: encryption, compression, application file format, operating system file system format, all have something to do with how the ones and zeros are interpreted. So the problem just gets exponentially complicated, because information about all that stuff is stored digitally too. How much of it do you need to read the digital copy of my thesis? All of it.
The general consensus is that there are two approaches to solving the long-term digital preservation problem: migration and emulation.
Migration is the act of more or less continually copying all archived digital information to the latest and greatest formats and technologies. This can work. Sorta. I once worked at a place that had to purchase every single used tape drive of the discontinued model they were using in order to keep enough working for long enough so that they could move their enormous tape archive containing the sole copies of historical climate data and archived output from climate simulations to a format and technology that might buy them another decade before panic sat in again. When you do this you hope you can get the migration competed before the new technology is obsolete.
Emulation is building a system using new technology that acts like old technology. This is non-trivial, for the reasons stated above: the documentation you need, if it exists at all, is also stored digitally. And there's the matter of the physical media and the devices to read it. This approach is the reason I was once tasked with writing UNIX code that grokked files stored in a variety of IBM VM/370 file formats. My software, which I designed by reverse engineering the original VM/370 system software written in IBM assembler, was used to access hundreds of thousands of files. Successfully, I'm told.
Barry Karafin, formerly the head of Bell Labs, once observed that most high technologies have a half-life of about five years. Some technologies, like C and TCP/IP, have done better. But for most of it, there is no long term. The need to migrate or emulate is, like adaptive maintenance, a continuous on-going process that never ends.
The definitive work on this topic in my opinion is
a digital copy of which, so far, can be found here, providing its still readable and you have software that understands Adobe's Portable Document Format. Just today I read another article on this topic written more recently
that I also recommend, and which, at least for now, can be found here. If the links are broken, or your browser can't render the text, well, then, welcome to the information age.
This is serious stuff. I'm not kidding. The value of information often can only be ascertained in hindsight once its historical context is known. We are contemporaneously the worst judges of the value of the data that we produce. We can still read the original letters John Adams wrote to his wife. But the chances that two hundred years from now anything that any of us may have written, important or not, will still exist and be readable are vanishingly slim.
If you absolutely had to recover that digital information, it would require tens or even hundreds of thousands of dollars, in terms of hardware, software, and time, if it could be done at all. You'd have to find eight-inch floppy drives, devise a way to hook them up to some modern computer, track down the description of the CP/M and RT-11 file system formats and the WordStar and RSX-11M file formats, implement both their documented behavior and the undocumented behavior, pray that the floppies were still readable nearly thirty years later, and hope that I didn't use some compression and/or encryption algorithm that was in vogue at the time.
The effort would be made somewhat more complicated by the fact that I threw away those eight-inch floppy disks years ago. But I do have a hardcopy of my thesis, which includes the text and the complete source listings, printed on acid free paper, and hardbound. If this tome were to survive fires, floods, and the inevitable collapse of civilization, it would likely still be readable a thousand years from now. If anyone cared. Which is highly unlikely.
So it is with preservation of digital information. While I can actually read an original book by Galileo, and make out the icons on a shard of four thousand year old Greek pottery, digital data are ephemeral. My enormous collection of motion picture and television soundtrack music on compact disk, about two thousand of them, has a shelf life. Estimates range from 100 years to as few as two years. And what are my chances of buying a new CD player twenty years from now? Let's ask the people who invested in eight-track tapes, cassette tapes, or any number of other media technologies that have gone by the wayside. It is a similar story for DVDs, nine-track magnetic tape, flash memory, and anything else that stores bits magnetically, optically, or electronically.
What's worse, it's not just the physical bits, it's what the bits mean: encryption, compression, application file format, operating system file system format, all have something to do with how the ones and zeros are interpreted. So the problem just gets exponentially complicated, because information about all that stuff is stored digitally too. How much of it do you need to read the digital copy of my thesis? All of it.
The general consensus is that there are two approaches to solving the long-term digital preservation problem: migration and emulation.
Migration is the act of more or less continually copying all archived digital information to the latest and greatest formats and technologies. This can work. Sorta. I once worked at a place that had to purchase every single used tape drive of the discontinued model they were using in order to keep enough working for long enough so that they could move their enormous tape archive containing the sole copies of historical climate data and archived output from climate simulations to a format and technology that might buy them another decade before panic sat in again. When you do this you hope you can get the migration competed before the new technology is obsolete.
Emulation is building a system using new technology that acts like old technology. This is non-trivial, for the reasons stated above: the documentation you need, if it exists at all, is also stored digitally. And there's the matter of the physical media and the devices to read it. This approach is the reason I was once tasked with writing UNIX code that grokked files stored in a variety of IBM VM/370 file formats. My software, which I designed by reverse engineering the original VM/370 system software written in IBM assembler, was used to access hundreds of thousands of files. Successfully, I'm told.
Barry Karafin, formerly the head of Bell Labs, once observed that most high technologies have a half-life of about five years. Some technologies, like C and TCP/IP, have done better. But for most of it, there is no long term. The need to migrate or emulate is, like adaptive maintenance, a continuous on-going process that never ends.
The definitive work on this topic in my opinion is
Jeff Rothenberg, "Ensuring the Longevity of Digital Documents", Scientific American, vol. 272, no. 1, January 1995
a digital copy of which, so far, can be found here, providing its still readable and you have software that understands Adobe's Portable Document Format. Just today I read another article on this topic written more recently
David Anderson, "Historical Reflections: The Future of the Past", Communications of the ACM, vol. 55, no. 5, May 2012
that I also recommend, and which, at least for now, can be found here. If the links are broken, or your browser can't render the text, well, then, welcome to the information age.
This is serious stuff. I'm not kidding. The value of information often can only be ascertained in hindsight once its historical context is known. We are contemporaneously the worst judges of the value of the data that we produce. We can still read the original letters John Adams wrote to his wife. But the chances that two hundred years from now anything that any of us may have written, important or not, will still exist and be readable are vanishingly slim.
ODROID-A4, Mac OS X, USB, ADB
To contact us Click HERE
The latest Digital Aggregates project to show up on my radar screen uses the ODROID-A4, an Android reference and development platform from Hardkernel for mobile devices based on the Samsung Exynos family of processors. The A4 uses an Exynos 4210 system-on-a-chip that features dual one gigahertz ARM Cortex-A9 cores, has one gigabyte of memory, and a microSD card slot for its persistent storage. As you can see in the photograph below, the A4 is a handheld battery-powered mobile device the size of a largish smartphone or a smallish tablet. (I believe it's form factor is the same as the Samsung Galaxy S Android smartphone.)
This project is code-named Conestoga. This project is so new, there's no web page for it yet.
(Update 2012-07-06: the Conestoga web page exists now and has a link to the tarball for what I'm working on. Warning: it's definitely a work in progress.)
Here's a photograph of the A4 on my development bench fixture. Clockwise from top: amplified speakers (because my ears are old), blue HDMI cable to an external display (because my eyes are old), the ODROID-A4 and an unconnected accessory I/O board just above it, the debug board with TTA20 debug cable, USB cable, and DB9 serial cable, and a powered USB hub.
I'm no stranger to Android, having previously worked with several different releases of it on a couple of BeagleBoards for my Contraption project in which I ran a GNU software stack along side the Android software stack on a common Linux kernel. I'm a big believer in working as high as you can on the abstraction ladder even on embedded systems, which makes frameworks like Android of interest in me in a broader context than just mobile devices like smartphones and tablets.
But I blew nearly half a day trying to get the USB-based Android Debug Bridge (adb) to recognize the A4 on my Mac Mini desktop system running OS X 10.6.8.
I found some useful background on the web on Stack Overflow, Intohand, and this discussion on Goggle Code. As usual, software development is a team effort, even when you've never met any of the other team members.
What finally worked for me was two-fold.
To be clear, here's a photograph of both of the A4 and the debug board on the left with all three cables connected, which did not work.
Here's a photograph of just the debug cable and the serial cable, which did work.
Here's a screen snapshot of how the device enumerates on OS X.
And here's the results of asking the Android Debug Bridge to list all the visible devices.
$ adb devices
List of devices attached
BABABEEFBABABEEF device
Here's hoping this saves others some time.
Update (2012-06-03)
While adb on the Mac works just fine, I've had no consistent success getting fastboot, the interface that allows you to communicate with the U-Boot boot loader over USB, to work on the Mac. Web perusal has led me to believe this is a common issue with later versions of Mac OS X. (I'm running 10.6.8 a.k.a. "Snow Leopard".)
After blowing an entire day trying various strategies including enabling USB debugging on OS X and writing my own OS X codeless kernel extension, I finally gave up and attached the A4 to my Ubuntu server (which, for unrelated reasons, I had recently moved from the vast subterranean catacombs to my office on the second floor of the Palatial Overclock Estate), where within an hour or two everything worked just fine.
The weird part is that fastboot devices on the Mac actually worked once out of dozens of tries. What I saw logged by the USB stack in OS X smells like some kind of race condition.
For now I'm sticking with Ubuntu for platform work on the A4, and will return to the Mac (which now entails just a cable swap at the powered USB hub) when and if I do application development in Java on the A4 using the Eclipse Android plug-in.
This project is code-named Conestoga. This project is so new, there's no web page for it yet.
(Update 2012-07-06: the Conestoga web page exists now and has a link to the tarball for what I'm working on. Warning: it's definitely a work in progress.)
Here's a photograph of the A4 on my development bench fixture. Clockwise from top: amplified speakers (because my ears are old), blue HDMI cable to an external display (because my eyes are old), the ODROID-A4 and an unconnected accessory I/O board just above it, the debug board with TTA20 debug cable, USB cable, and DB9 serial cable, and a powered USB hub.
I'm no stranger to Android, having previously worked with several different releases of it on a couple of BeagleBoards for my Contraption project in which I ran a GNU software stack along side the Android software stack on a common Linux kernel. I'm a big believer in working as high as you can on the abstraction ladder even on embedded systems, which makes frameworks like Android of interest in me in a broader context than just mobile devices like smartphones and tablets.
But I blew nearly half a day trying to get the USB-based Android Debug Bridge (adb) to recognize the A4 on my Mac Mini desktop system running OS X 10.6.8.
I found some useful background on the web on Stack Overflow, Intohand, and this discussion on Goggle Code. As usual, software development is a team effort, even when you've never met any of the other team members.
What finally worked for me was two-fold.
- I used a separate powered USB hub (visible in the photograph above) instead of connecting the A4 to the hub built into the Cinema Display on my Mac Mini (no clue why, but that's what worked for others too).
- I did not use a USB cable to the mini-USB port on the debug board, connecting only the USB-to-TTA20 debug cable and a DB9 serial cable. The TTA20 port on the debug board provides USB access for the Android Debug Bridge. The DB9 port provides console access with a root shell.
To be clear, here's a photograph of both of the A4 and the debug board on the left with all three cables connected, which did not work.
Here's a photograph of just the debug cable and the serial cable, which did work.
Here's a screen snapshot of how the device enumerates on OS X.
And here's the results of asking the Android Debug Bridge to list all the visible devices.
$ adb devices
List of devices attached
BABABEEFBABABEEF device
Here's hoping this saves others some time.
Update (2012-06-03)
While adb on the Mac works just fine, I've had no consistent success getting fastboot, the interface that allows you to communicate with the U-Boot boot loader over USB, to work on the Mac. Web perusal has led me to believe this is a common issue with later versions of Mac OS X. (I'm running 10.6.8 a.k.a. "Snow Leopard".)
After blowing an entire day trying various strategies including enabling USB debugging on OS X and writing my own OS X codeless kernel extension, I finally gave up and attached the A4 to my Ubuntu server (which, for unrelated reasons, I had recently moved from the vast subterranean catacombs to my office on the second floor of the Palatial Overclock Estate), where within an hour or two everything worked just fine.
The weird part is that fastboot devices on the Mac actually worked once out of dozens of tries. What I saw logged by the USB stack in OS X smells like some kind of race condition.
For now I'm sticking with Ubuntu for platform work on the A4, and will return to the Mac (which now entails just a cable swap at the powered USB hub) when and if I do application development in Java on the A4 using the Eclipse Android plug-in.
Welcome to the Major Leagues
To contact us Click HERE
I'm not the only person to have recognized that the skill sets for doing embedded development are the same as for developing for large distributed systems and multicore/multiprocessor architectures. And I'm sure I'm not the only one to have built a career on that common skill set based on dealing with concurrency and parallelism (and understanding why those are two different things), frequently working close to bare metal, developing scalable solutions, worrying about real-time and emergent behavior, and needing to understand what goes on under the hood.
But despite having spent decades on and off doing it, when I'm asked to define embedded development, I'm at a bit of a loss. Ask this question in an internet forum, and you will be surprised to find that there is no real consensus even among those who describe themselves as embedded developers.
Part of this is because the hardware target for which an embedded developer writes software ranges from a tiny inexpensive low-power eight-bit microcontrollers (which in fact may not even be independent chips themselves but cores implemented inside of another chip like an FPGA or some other surface-mounted device) with kilobytes of memory to a thirty-two-bit microprocessor with multiple cores and megabytes or even gigabytes of memory. The developer may code in assembler, C, C++, Java, or even scripting languages like Python and Perl. The underlying software platform that runs on the so-called embedded system ranges from none (remarkably, it is not uncommon to have no OS-like layer at all), to a simple task scheduler like FreeRTOS or even home grown, to a large commercial RTOS like VxWorks, to a full blown multi-user GNU/Linux or even Windows operating system.
This uncertainty about how to describe what we do for a living to our friends, children, spouses, and even colleagues is just going to get worse.
Yesterday I successfully built the entire Android "Ice Cream Sandwich" (a.k.a. ICS) software stack for my ODROID-A4 platform as part of my Conestoga project. It took awhile. I'm used to that, having built other Android releases like "Frozen Yogurt" and "Gingerbread" for the BeagleBoard as part of Contraption. While I was watching the build process scroll along in a window, I began to idly wonder just how big this software distribution was. So in another window I unloosed some of my favorite commands like find, wc, and awk.
ICS consists of 25,410 files ending in .java containing 5,325,103 lines of what is presumably Java code. It also includes 62,861 files ending in .cpp, .c, .hpp, or .h, containing 13,225,200 lines of presumed C or C++ code. This is just the Android stack. The same statistics for the Linux kernel and the U-Boot boot loader would make these numbers significantly larger.
To be fair, the ICS counts include some stuff that may not run on the Android target itself. Much of the code that does run on the target is what we would normally associate with the standard underlying C and C++ libraries on any other system. And one of the reasons not to count the Linux and U-Boot code bases is that they each contain vast amounts of code for targets completely unrelated to Android or the ODROID-A4 target. But even so, those are still big numbers, and developers working in the lower levels of Android close to bare metal may still end up indexing and searching all those unrelated files because there is no easy way to exclude them.
So just a naive census of the Android ICS code base for the ODROID-A4 yields 18,550,303 lines of code in 88,271 source files.
Surprised? Do you think those numbers are too big or too small? The answer may depend on whether or not you see Android as an embedded system. The A4 runs on a battery, connects wirelessly to a network, fits in my shirt pocket, and has tightly integrated hardware components. Any embedded developer would be completely at home perusing its circuit board. But it implements a complex user-facing graphical user interface and a bunch of applications. So desktop developers see a lot of stuff they recognize as well.
It's a floor wax and a dessert topping.
For sure these are pretty naive numbers. And I would be the first to say that lines of code is a kind of useless metric of just about anything. But if you are a developer tasked with working in this code base, then part of your job may be to reverse engineer portions of this code to understand it and to integrate with it, which means you'll be indexing, searching through, and reading this code, whether it's blank lines, comments, or the implementation of a cryptographic hash function.
What does this mean? I'm not sure. But I do believe that product and project managers who are looking at using Android, whether it's for a small embedded device or a large complex system, may need to recalibrate the mental models they carry around in their heads regarding the complexity of the tasks they are asking developers to take on. If you spend most of your time in the embedded world, or if you don't but you see shirt-pocket-sized mobile wireless devices as embedded systems, then the idea of a code base of more than eighteen million lines of code might seem surprising, not to mention a little daunting.
It's not as bad as I may make it sound. The Android APIs are well documented (albeit a moving target with each new release), and tools like the Android SDK and its Eclipse plug-in are very good.
But Android is not Minor League.
But despite having spent decades on and off doing it, when I'm asked to define embedded development, I'm at a bit of a loss. Ask this question in an internet forum, and you will be surprised to find that there is no real consensus even among those who describe themselves as embedded developers.
Part of this is because the hardware target for which an embedded developer writes software ranges from a tiny inexpensive low-power eight-bit microcontrollers (which in fact may not even be independent chips themselves but cores implemented inside of another chip like an FPGA or some other surface-mounted device) with kilobytes of memory to a thirty-two-bit microprocessor with multiple cores and megabytes or even gigabytes of memory. The developer may code in assembler, C, C++, Java, or even scripting languages like Python and Perl. The underlying software platform that runs on the so-called embedded system ranges from none (remarkably, it is not uncommon to have no OS-like layer at all), to a simple task scheduler like FreeRTOS or even home grown, to a large commercial RTOS like VxWorks, to a full blown multi-user GNU/Linux or even Windows operating system.
This uncertainty about how to describe what we do for a living to our friends, children, spouses, and even colleagues is just going to get worse.
Yesterday I successfully built the entire Android "Ice Cream Sandwich" (a.k.a. ICS) software stack for my ODROID-A4 platform as part of my Conestoga project. It took awhile. I'm used to that, having built other Android releases like "Frozen Yogurt" and "Gingerbread" for the BeagleBoard as part of Contraption. While I was watching the build process scroll along in a window, I began to idly wonder just how big this software distribution was. So in another window I unloosed some of my favorite commands like find, wc, and awk.
ICS consists of 25,410 files ending in .java containing 5,325,103 lines of what is presumably Java code. It also includes 62,861 files ending in .cpp, .c, .hpp, or .h, containing 13,225,200 lines of presumed C or C++ code. This is just the Android stack. The same statistics for the Linux kernel and the U-Boot boot loader would make these numbers significantly larger.
To be fair, the ICS counts include some stuff that may not run on the Android target itself. Much of the code that does run on the target is what we would normally associate with the standard underlying C and C++ libraries on any other system. And one of the reasons not to count the Linux and U-Boot code bases is that they each contain vast amounts of code for targets completely unrelated to Android or the ODROID-A4 target. But even so, those are still big numbers, and developers working in the lower levels of Android close to bare metal may still end up indexing and searching all those unrelated files because there is no easy way to exclude them.
So just a naive census of the Android ICS code base for the ODROID-A4 yields 18,550,303 lines of code in 88,271 source files.
Surprised? Do you think those numbers are too big or too small? The answer may depend on whether or not you see Android as an embedded system. The A4 runs on a battery, connects wirelessly to a network, fits in my shirt pocket, and has tightly integrated hardware components. Any embedded developer would be completely at home perusing its circuit board. But it implements a complex user-facing graphical user interface and a bunch of applications. So desktop developers see a lot of stuff they recognize as well.
It's a floor wax and a dessert topping.
For sure these are pretty naive numbers. And I would be the first to say that lines of code is a kind of useless metric of just about anything. But if you are a developer tasked with working in this code base, then part of your job may be to reverse engineer portions of this code to understand it and to integrate with it, which means you'll be indexing, searching through, and reading this code, whether it's blank lines, comments, or the implementation of a cryptographic hash function.
What does this mean? I'm not sure. But I do believe that product and project managers who are looking at using Android, whether it's for a small embedded device or a large complex system, may need to recalibrate the mental models they carry around in their heads regarding the complexity of the tasks they are asking developers to take on. If you spend most of your time in the embedded world, or if you don't but you see shirt-pocket-sized mobile wireless devices as embedded systems, then the idea of a code base of more than eighteen million lines of code might seem surprising, not to mention a little daunting.
It's not as bad as I may make it sound. The Android APIs are well documented (albeit a moving target with each new release), and tools like the Android SDK and its Eclipse plug-in are very good.
But Android is not Minor League.
7 Temmuz 2012 Cumartesi
Raspberry Pi Kernel Image
To contact us Click HERE
At the end of my last post I needed a Debian Linux Image package. I posted on the forums but didn't get anywhere. A bit of googling turned up a couple of useful pages which talked about how to build a Debian Linux image package. Based on these pages I ran the following commands.
cd /lib/modules/3.1.9+/build
time make-kpkg kernel_imageThis ended with an error:
arm-Linux-gnueabi-ld: not foundI ran the following command and spotted that there were some existing symlinks for other gnueabi tools:
ls -l /usr/bin/arm-linux-gnueabi*I therefore tried adding a symlink for ld. A couple of hours later the build failed and in the end (after several more multi hour builds) I needed all of these links:
sudo ln -s /usr/bin/ld /usr/bin/arm-linux-gnueabi-ld
sudo ln -s /usr/bin/ar /usr/bin/arm-linux-gnueabi-ar
sudo ln -s /usr/bin/nm /usr/bin/arm-linux-gnueabi-nm
sudo ln -s /usr/bin/objcopy /usr/bin/arm-linux-gnueabi-objcopy
sudo ln -s /usr/bin/objdump /usr/bin/arm-linux-gnueabi-objdump
sudo ln -s /usr/bin/strip /usr/bin/arm-linux-gnueabi-stripWith these links in place I cleaned the build point and rebuilt the kernel.
time fakeroot make-kpkg clean
gzip -dc /proc/config.gz > .config
time fakeroot make-kpkg kernel_imageSadly after 6 hours of building the Debian package failed to be created due to permissions issues. Cue restarting with sudo.
time sudo fakeroot make-kpkg clean
gzip -dc /proc/config.gz > .config
time sudo fakeroot make-kpkg kernel_imageAttempting to install the resulting Debian package prompted a warning that I already had a kernel in /lib/modules/3.1.9+. I moved the existing kernel out of the way and installed the new kernel package. I then copied the kernel headers back into place.
sudo mv /lib/modules/3.1.9+ /lib/modules/3.1.9+.old
sudo dpkg -i linux-image-3.1.9+_3.1.9+-10.00.Custom_armel.deb
sudo cp -r /lib/modules/3.1.9+.old/build /lib/modules/3.1.9+/buildWith all of this in place I could finally try again to build and install my ar5523 module.
cd ~/ar5523
sudo m-a a-i ar5523
sudo cp ../uath-ar5523.bin /usr/local/lib/firmware/
sudo modprobe ar5523
sudo shutdown -r nowAfter all this I plugged in my WG111T and sadly it didn't work! The following errors show up in dmesg while the WG111T is plugged in:
usb 1-1.3.4: new high speed USB device number 49 using dwc_otgusb 1-1.3.4: New USB device found, idVendor=1385, idProduct=4250usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3usb 1-1.3.4: Product: WG111Tusb 1-1.3.4: Manufacturer: Atheros Communications Incusb 1-1.3.4: SerialNumber: 1.0usb 1-1.3.4: MAC/BBP AR5523, RF AR2112ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKusb 1-1.3.4: timeout waiting for command replyusb 1-1.3.4: could not send read command 07hDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKusb 1-1.3.4: timeout waiting for command replyusb 1-1.3.4: could not send read command 07hDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKusb 1-1.3.4: timeout waiting for command replyusb 1-1.3.4: could not send read command 07hDEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACKDEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
Exciting Components
To contact us Click HERE
I haven't been spending much time on electronics recently but I have been seeing some really interesting components.
HackHD (http://hackhd.com/)
I think this is a very recent project but I can't see any dates on the HackHD site. This simple PCB features a 1080P 30FPS camera which can be controlled electronically and records to an SD card. The website is very bare with some details about the PCB but no example videos. Thankfully there are some good examples and comparisons on Youtube.
The site offers to sell you a starter kit including PCB, battery, memory card and some other components for US $140 (about £90) which seems pretty reasonable.
808 Car Key Micro Camera (http://chucklohr.com/808/)
While Googling for reviews of the HackHD I came across a thread on a paintballing forum which was discussing the HackHD. One poster in this thread suggested that they would prefer to use an 808 Camera which supposedly only costs USD $38 for 720P video. A bit more Googling turned up the link above which describes the 808 camera as a line of cheap HD cameras out of China. The most recent edition is the #18 model which supports 720P 30FPS video and is available for around USD $36 on ebay.
The same ebay sellers are offering a cheap 1080P video camera but this thread suggests that the video capture is unreliable.
Electric Imp (http://www.electricimp.com/)
Electric Imp is a micro controller with a wifi connection in a standard SD card form factor.
The card will retail for USD $25 and there are several interesting development kits which cost between USD $7 and $25. This is a very recent project so the products haven't actually been released yet but are due very soon.
I'm particularly interested in this as it is impressively cheap for a wifi solution.
HackHD (http://hackhd.com/)
I think this is a very recent project but I can't see any dates on the HackHD site. This simple PCB features a 1080P 30FPS camera which can be controlled electronically and records to an SD card. The website is very bare with some details about the PCB but no example videos. Thankfully there are some good examples and comparisons on Youtube.
The site offers to sell you a starter kit including PCB, battery, memory card and some other components for US $140 (about £90) which seems pretty reasonable.
808 Car Key Micro Camera (http://chucklohr.com/808/)
While Googling for reviews of the HackHD I came across a thread on a paintballing forum which was discussing the HackHD. One poster in this thread suggested that they would prefer to use an 808 Camera which supposedly only costs USD $38 for 720P video. A bit more Googling turned up the link above which describes the 808 camera as a line of cheap HD cameras out of China. The most recent edition is the #18 model which supports 720P 30FPS video and is available for around USD $36 on ebay.
The same ebay sellers are offering a cheap 1080P video camera but this thread suggests that the video capture is unreliable.
Electric Imp (http://www.electricimp.com/)
Electric Imp is a micro controller with a wifi connection in a standard SD card form factor.
The card will retail for USD $25 and there are several interesting development kits which cost between USD $7 and $25. This is a very recent project so the products haven't actually been released yet but are due very soon.
I'm particularly interested in this as it is impressively cheap for a wifi solution.
Quadrocopters
To contact us Click HERE
I have recently upgraded my Parrot AR Drone to the new 2.0 version. The new version features a number of upgrades but there are two in particular which are really standing out so far.
The front facing camera has been upgraded to 720P HD quality. This is much better than the first Parrot drone which had a camera which really wasn't great. Unfortunately the new camera uses a rolling shutter which means that at times the video can be quite wobbly but mostly the video quality is good enough to still be impressive.
The other big upgrade in the 2.0 is the addition of an "Absolute Control" mode where control is done relative to the pilot rather than relative to the drone. For example, this means that when you tilt your iPad towards you the drone will move towards you rather than simply moving backwards. This makes flying the drone much easier!
Here are a couple of videos from some flights which I did today.
The Parrot 2.0 delivers impressive performance for a relatively low price tag. However, it is interesting to see what can be achieved if you have a (much) higher budget. The OktoKopter-XL costs >£5K-£10K for the drone + camera + other necessary parts and can produce some really impressive videos such as the following.
MikroKopter - Zoom from Holger Buss on Vimeo.
MikroKopter - Wind turbine from Holger Buss on Vimeo.
The front facing camera has been upgraded to 720P HD quality. This is much better than the first Parrot drone which had a camera which really wasn't great. Unfortunately the new camera uses a rolling shutter which means that at times the video can be quite wobbly but mostly the video quality is good enough to still be impressive.
The other big upgrade in the 2.0 is the addition of an "Absolute Control" mode where control is done relative to the pilot rather than relative to the drone. For example, this means that when you tilt your iPad towards you the drone will move towards you rather than simply moving backwards. This makes flying the drone much easier!
Here are a couple of videos from some flights which I did today.
The Parrot 2.0 delivers impressive performance for a relatively low price tag. However, it is interesting to see what can be achieved if you have a (much) higher budget. The OktoKopter-XL costs >£5K-£10K for the drone + camera + other necessary parts and can produce some really impressive videos such as the following.
MikroKopter - Zoom from Holger Buss on Vimeo.
MikroKopter - Wind turbine from Holger Buss on Vimeo.
Making Something From Nothing
To contact us Click HERE
Here's the latest on my homebrew solar-powered Arduino-based remote sensor platform.
The basic parts manifest, clockwise from top left, includes a solar battery charger regulator, an Arduino Uno board with an XBee radio shield and a Xbee Series 1 radio module, a 12V gel cell rechargeable lead-acid battery, and a solar panel designed to recharge 12V batteries. I bought the regulator and solar panel at my local Harbor Freight hardware store in Westminster Colorado. I purchased the Arduino, Xbee radio shield, and Xbee radios over the web from SparkFun Electronics in nearby Boulder Colorado (who are very nice folks, BTW). I also bought some miscellaneous parts and connectors at my local Radio Shack at the Colorado Mills outlet mall in Lakewood Colorado (who know me quite well by now, and have been known to whip out a multimeter when I have a question).
Everything except the solar panel fits nicely into a five dollar plastic box I bought at the local Office Depot office supply store in Wheat Ridge Colorado. The box isn't intended to be water tight, just to keep the worst of the elements off the electrical bits.
Here's a closeup of what gets stuffed into the box. The battery, purchased at my local Interstate Battery store in Arvada Colorado, is the largest and heaviest item, and the most expensive single component as well. What would I do without my Brother thermal label maker?
I used my Dremel tool to cut a tiny slot in the plastic box through which I feed the cable to the solar panel. I also used the Dremel to drill holes in the bottom of the box, which has a bit of a lip around its bottom, so if any moisture does seep into the box it might have a chance of draining out. No air vents though, so we'll see if things get too warm. The box itself will sit in the shade of the roof over my rear deck.
With the lid on you can see that the slot for the cable is conveniently protected by the lip of the lid.
I sat what I am now calling the "Instrument Pod" on a table on my back deck just to make it less likely that I won't trip over it or kick it over. You can easily see the LEDs on the Arduino, the Xbee shield, and the regulator through the transparent plastic.
The solar panel sits on a couple of zinc-coated nails on the conveniently angled open lattice portion of the south-facing roof over my back deck where it's not shaded by any of the nearby trees. It's pretty secure but can be easily lifted off the nails with a little jiggling. Did I mention that Colorado gets more sunny days than any other state in the U.S.? Sorry, California. I have no idea how weather proof this solar panel is, the instruction sheet wasn't helpful in this regard.
Stepping back a little bit, here's what it all looks like: solar panel above, instrument pod below. I've since moved the table a little further back under the roof to the left where it's more consistently shaded.
The test software on the Arduino logs how long it's been running since it's last reset. If the board loses power, the application will restart automatically if and when power is restored. It's talking over a wireless serial channel using the Zigbee (IEEE 802.15.4) protocol to a similar tiny little radio hooked up to my Mac desktop in my office on the second floor. I use the Mac screen utility with a little script that prepends a timestamp to each line it receives from the instrument pod, and logs it all to a file.
My goal at this phase is to see whether I can get enough sunlight to run the Arduino and keep a small battery charged during the day, and to run the Arduino on battery power at night. I'm guessing I'll need a larger solar panel (or at least use this as an excuse to buy one) but this is a cost effective way to get some empirical data.
The ever helpful folks at Office Depot asked me what I was going to store in the plastic box. When I explained it was a microcontroller, radio, battery, and solar charge regulator, they backed away slowly. I get similar strange looks from most (but not all) of the handymen and women my local Lowes hardware store when I explain that "I'm making something from nothing".
The basic parts manifest, clockwise from top left, includes a solar battery charger regulator, an Arduino Uno board with an XBee radio shield and a Xbee Series 1 radio module, a 12V gel cell rechargeable lead-acid battery, and a solar panel designed to recharge 12V batteries. I bought the regulator and solar panel at my local Harbor Freight hardware store in Westminster Colorado. I purchased the Arduino, Xbee radio shield, and Xbee radios over the web from SparkFun Electronics in nearby Boulder Colorado (who are very nice folks, BTW). I also bought some miscellaneous parts and connectors at my local Radio Shack at the Colorado Mills outlet mall in Lakewood Colorado (who know me quite well by now, and have been known to whip out a multimeter when I have a question).
Everything except the solar panel fits nicely into a five dollar plastic box I bought at the local Office Depot office supply store in Wheat Ridge Colorado. The box isn't intended to be water tight, just to keep the worst of the elements off the electrical bits.
Here's a closeup of what gets stuffed into the box. The battery, purchased at my local Interstate Battery store in Arvada Colorado, is the largest and heaviest item, and the most expensive single component as well. What would I do without my Brother thermal label maker?
I used my Dremel tool to cut a tiny slot in the plastic box through which I feed the cable to the solar panel. I also used the Dremel to drill holes in the bottom of the box, which has a bit of a lip around its bottom, so if any moisture does seep into the box it might have a chance of draining out. No air vents though, so we'll see if things get too warm. The box itself will sit in the shade of the roof over my rear deck.
With the lid on you can see that the slot for the cable is conveniently protected by the lip of the lid.
I sat what I am now calling the "Instrument Pod" on a table on my back deck just to make it less likely that I won't trip over it or kick it over. You can easily see the LEDs on the Arduino, the Xbee shield, and the regulator through the transparent plastic.
The solar panel sits on a couple of zinc-coated nails on the conveniently angled open lattice portion of the south-facing roof over my back deck where it's not shaded by any of the nearby trees. It's pretty secure but can be easily lifted off the nails with a little jiggling. Did I mention that Colorado gets more sunny days than any other state in the U.S.? Sorry, California. I have no idea how weather proof this solar panel is, the instruction sheet wasn't helpful in this regard.
Stepping back a little bit, here's what it all looks like: solar panel above, instrument pod below. I've since moved the table a little further back under the roof to the left where it's more consistently shaded.
The test software on the Arduino logs how long it's been running since it's last reset. If the board loses power, the application will restart automatically if and when power is restored. It's talking over a wireless serial channel using the Zigbee (IEEE 802.15.4) protocol to a similar tiny little radio hooked up to my Mac desktop in my office on the second floor. I use the Mac screen utility with a little script that prepends a timestamp to each line it receives from the instrument pod, and logs it all to a file.
My goal at this phase is to see whether I can get enough sunlight to run the Arduino and keep a small battery charged during the day, and to run the Arduino on battery power at night. I'm guessing I'll need a larger solar panel (or at least use this as an excuse to buy one) but this is a cost effective way to get some empirical data.
The ever helpful folks at Office Depot asked me what I was going to store in the plastic box. When I explained it was a microcontroller, radio, battery, and solar charge regulator, they backed away slowly. I get similar strange looks from most (but not all) of the handymen and women my local Lowes hardware store when I explain that "I'm making something from nothing".
The Prisoner's Dilemma, the Fermi Paradox, and War Games
To contact us Click HERE
I have enough life experience and self-knowledge to recognize when I'm being totally intellectually obsessive on some topic. And for sure, when I start to quote myself I've reached some critical threshold of narcissism. But never the less, here are some footnotes that I added to a recent blog article (which was only peripherally on this topic) that I'm reposting here because I'm so enamored with these ideas.
"The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy."
"The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality."
Let's all hope I get over this once I've finished reading Dixit and Nalebuff''s book Thinking Strategically.
"The prisoner's dilemma also applies to the Fermi Paradox, which frames the contradiction between the statistical likelihood of technological extraterrestrial civilizations with the fact that so far there is no evidence of such. The dominant but sub-optimal strategy is for each civilization to try to wipe out all the others before someone does it to them. I'm voting for weaponized von Neumann machines. It's interesting (to me anyway) that John von Neumann, the inventor of game theory, also invented the idea of self-replicating automata. I'd like to think that weaponized von Neumann machines of extraterrestrial origin are the untold backstory to books and movies about the zombie apocalypse. Or of the Borg race from the Star Trek universe. The central theme, in my opinion, of the Borg story arc in Star Trek is that the Borg applied the dominant strategy of betrayal to the prisoner's dilemma while the members of the United Federation of Planets chose the cooperative optimal strategy."
"The WOPR U.S. automated defense computer learns the inefficiency of nuclear war by playing tic-tac-toe in the movie WarGames. But a much better game, and one that likely actually came from nuclear strategists, would be to have it play a repeated prisoner's dilemma game where it would learn the benefit of cooperation over betrayal. On the other hand, this is exactly the plot of the movie Colossus: The Forbin Project, and that didn't turn out so well due to what economists would call an externality."
Let's all hope I get over this once I've finished reading Dixit and Nalebuff''s book Thinking Strategically.
5 Temmuz 2012 Perşembe
JBL'DEN AKILLILARA ÖZEL SES SİSTEMİ...ONBEAT XTREME...
To contact us Click HERE
Kaliteli ve yüksek performanslı ses sistemleri ile tanınan JBL; iPad, iPhone, iPod Touch, tabletler, bluetooth özellikli akıllı telefonlar ve bilgisayarlarla uyumlu çalışabilen dock cihazı OnBeat Xtreme ile hem kulaklara hemde şık tasarımıyla gözlere hitap ediyor.Bluetooth üzerinden kablosuz olarak cihazınızı bağlayabileceğiniz OnBeat Xtreme ile oturduğunuz yerden müzik dinleme ve video izleme keyfi yaşayabilirsiniz
OnBeat Xtreme de dönen docklu aparat ile üzerine yerleştireceğiniz iPad'inizi ister dikey ister yatay şekilde konumlandırabiliyorsunuz.Cihaz, Skype ve Apple Face Time üzerinden yapacağınız videolu tele-konferans görüşmelerinizde rahatlık ve kullanım kolaylığı sağlıyor.
Ses akışı için Apple IOS tabanlı cihazları, Sony ve Nintendo gibi oyun konsollarını, Android tabanlı akıllı telefonlar tarafından desteklenen yüksek kalitede AAC kod çözücülerini kullanan OnBeat Xtreme, dahili 30 pin konnektör ve diğer müzik çalarlarla bağlantı kurmayı sağlayan 3.5 mm stereo jack bulunduruyor.OnBeat Xtreme ayrıca akıllı telefonlar, iTunes senkronizasyonu ve firmware güncellemeleri için USB bağlantı noktasına da ev sahipliği yapıyor.
Kaliteli ve yüksek performanslı ses sistemleri ile tanınan JBL; iPad, iPhone, iPod Touch, tabletler, bluetooth özellikli akıllı telefonlar ve bilgisayarlarla uyumlu çalışabilen dock cihazı OnBeat Xtreme ile hem kulaklara hemde şık tasarımıyla gözlere hitap ediyor.Bluetooth üzerinden kablosuz olarak cihazınızı bağlayabileceğiniz OnBeat Xtreme ile oturduğunuz yerden müzik dinleme ve video izleme keyfi yaşayabilirsiniz
OnBeat Xtreme de dönen docklu aparat ile üzerine yerleştireceğiniz iPad'inizi ister dikey ister yatay şekilde konumlandırabiliyorsunuz.Cihaz, Skype ve Apple Face Time üzerinden yapacağınız videolu tele-konferans görüşmelerinizde rahatlık ve kullanım kolaylığı sağlıyor.
Ses akışı için Apple IOS tabanlı cihazları, Sony ve Nintendo gibi oyun konsollarını, Android tabanlı akıllı telefonlar tarafından desteklenen yüksek kalitede AAC kod çözücülerini kullanan OnBeat Xtreme, dahili 30 pin konnektör ve diğer müzik çalarlarla bağlantı kurmayı sağlayan 3.5 mm stereo jack bulunduruyor.OnBeat Xtreme ayrıca akıllı telefonlar, iTunes senkronizasyonu ve firmware güncellemeleri için USB bağlantı noktasına da ev sahipliği yapıyor.
Kaydol:
Yorumlar (Atom)