Scott Aaronson is one of the main D-Wave skeptics. His most recent post on the subject has a nice overview on the latest works on d-wave "quantumness":
The story of Olivetti is interesting and sad. They had many opportunities to be the Italian Apple (they even owned ARM from 1985 to 1998!), all of them missed because of terrible management choices.
The Programma 101 was a perfect combination of innovative technology, usability and industrial design. When it was introduced at the New York World's Fair it stole the show. However, the management decided not to pursue any more r&d on the project. Some of the reasons:
- They were afraid it would jeopardize their mainframe business (which they sold soon after that anyway)
- They thought it was useless. One of the managers even told Perotto "if nobody is building this, it means nobody needs it"
This gave HP enough time to copy the design and rule the market.
A couple of years ago a documentary was made on the history of the Programma 101, I found it very instructive. Unfortunately only the trailer (http://www.youtube.com/watch?v=noN0zNYFs9I) has English subtitles, the documentary is only in Italian.
As an interesting aside it's also interesting to read about Adriano Olivetti [1]. He advocated revenue sharing, increasing of fringe benefits and reducing of working hours during his time at the helm of the company. This is all the more incredible if you think he managed to do all this during fascism, while also helping the underground resistance.
Some commenters think that even if Programma 101 was designed shortly after Adriano's death, it's the culture he helped build which allowed Olivetti to produce such advanced and beautiful products.
It is also worth noting that Olivetti's attitude towards workers and work-life balance could not be any more anti-Apple…
You're right, I've got the timeline a bit messed up. Anyway, I'm sure that the project met resistance at some point because of the competition with the mainframe business.
Maybe at its inception. I guess that the real problem there was that the project wasn't the pet of any specific big manager in the company - a real pity.
Sounds like a cookie-cutter case of the Innovator's Dilemma. An established company with high-end, high-margin customers ignores or neglects a low-end market due to lower margins and the threat of cannibalizing their high-margin business, allowing for someone else to swoop in and do it instead, again becoming the top of the heap.
It is true that any strong symmetric encryption generates data that it is indistinguishable from random for any (efficiently computable) statistical test, but these tests are extremely weak and don't prove anything.
All but the last two only look at distribution of the bytes, meaning that the string "\0\1\2...\255" repeated many times would give the same values, but it doesn't look random at all. The Monte Carlo computation of Pi also ignores the order (sums are commutative).
The serial correlation coefficient only looks at the correlation between the sequence and itself shifted by one, ignoring higher-distance correlations, so it almost as easy to produce very regular sequences that have give very small coefficients.
A few years ago I wrote a tool to do exactly this [1], which also works for any executable/library, not just Python code.
It works by compiling the code with a unique virtual prefix that is something like /tmp/boxes/4031e76a-6bff-11e3-a3b0-002590a9f2cc so that it can be symlinked to any directory in the filesystem. The tool also generates a script that sets environment variables so that includes, libraries, executables, man pages, etc... are all found in the path. It also allows to install several versions of the same package and instantly switching from a version to another, which is very useful during development.
Unfortunately I didn't have more time to work on it so it is basically unmaintained, but every now and then I still use it, mainly when I need to install software on machines where I don't have administrative privileges, and it works great. I wish I implemented some kind of dependency handling mechanism, it would have made it much more useful.
I'd like to see a variation of this contest where a "typical", valid source code is given as part of the rules, and the objective is to change the code as little as possible to produce the highest amount of compilation errors. For example it could be measured the ratio between the output of the compiler and the edit distance with the reference code.
It would be more representative of all those WTF moments when you have some code that compiles perfectly fine, change a line and suddenly GCC decides to throw up thousands of meaningless messages :)
