Quantum Bayesian Networks

September 30, 2008

Evolution of Quantum Computer Software – Pixar Analogy

Filed under: Uncategorized — rrtucci @ 1:28 am

Suppose commercial quantum computers are 10 years away. Should we wait until then to start developing QC software? No! The software must be ready at the same time as the hardware. It will take many years to invent and refine the software that powers QCs. A good analogy is Pixar. It took many years to invent and refine the computer graphics software that powers Pixar.

Pixar Timeline

  • 1973- Dick Shoup begins writing SuperPaint. Shoup eventually fired from Xerox PARC for working on SuperPaint.
  • 1974- Alvy Ray Smith collaborates with Shoup on Superpaint.
  • 1975- Alex Schure, eccentric millionaire, hires Smith and Ed Catmull to work on graphics software (for Tubby the Tuba) at NYIT (New York Institute of Technology).
  • 1979- George Lucas hires Smith and Catmull to start new computer division (Graphics Group) of LucasFilm
  • 1984- John Lasseter, artistic genius, leaves Disney to join Graphics Group.
  • 1986- Steve Jobs buys Graphics Group for $10 million.
  • 2006- Disney acquires Pixar for $7.4 billion

Moral for investors: Gathering and nurturing a cohesive talent pool for a worthy endeavor takes time and patience, but it pays off handsomely.

Advertisements

5 Comments »

  1. Hi Bob

    One issue I have with this is that it is not likely that quantum computers will look anything like universal gate model systems for the foreseeable future. While I agree that most researchers in QC don’t get the point you’re making (which is a good one), if you build programming models assuming a particular model of computation or level of control at the device level you’re baking in assumptions prematurely. Not that this is necessarily bad, just has to be kept in mind. None of the “programming languages” I’ve seen for QCs are remotely relevant to our systems for example.

    Comment by Geordie — April 1, 2009 @ 5:08 pm

  2. Geordie, I think at present we should write quantum software in terms of qubit circuits. Can’t go too wrong that way. Qubit circuits are extremely general. All they are is Dirac notation applied to N qubits. The choice of which gates are considered primitive is arbitrary and easily changed. I don’t doubt that in the future we will invent higher order “languages” more convenient for special purposes (like adiabatic programming) than qubit circuits, but we will also invent software that translates between those languages and qubit circuits.

    Comment by rrtucci — April 1, 2009 @ 11:26 pm

  3. Here is another way of looking at the programming issue. There are limited numbers of known quantum algorithms, a good list is at the quantum algorithms zoo. One way you could imagine a programming interface to a QC is just provide users functions that (probably remotely) call all the known algorithms, where a team of specialists has figured out the details of how to translate the algorithm into its compiled representation in whatever hardware you’ve got available. The number of people who can do the latter step is always going to be very limited, but nearly everybody who would actually use the system will only care about using a quantum algorithm as a black box function call in whatever application they are developing. In our case the function call is SolveISING(h,J) where h is a vector and J is a matrix, that’s all the computer does, so most users don’t need a programming language, they just need to know how to call the system to compute the solution to an optimization problem. For a more abstract example, let’s say I build a universal gate model system, most people will rather have a library of functions they can call from Python or something (like Factor(N)) than want to compile some quantum algorithm to machine language. I suspect that the people willing and able to understand how to compile a high level language into machine code for a quantum computer are always going to be few and far between. Doesn’t mean you don’t need good tools to do it, just that it is possible to profile the types of people and situations relevant to this. My view is that since these machines really can only be developed in industrial environments each producer will have its own team doing this and will likely use custom-built tools developed for the specific hardware under development.

    Comment by Geordie — April 2, 2009 @ 1:04 am

  4. Geordie,

    Respectfully, I disagree. I think with any language as it develops you get more “primatives” that can be joined together. It may start off with very specific interfaces into the model, but as we learn how to do more, it seems fairly natural to think that there will be unique and interesting ways of linking up functionality and operating on data (i.e. the purpose of a programming language; to facilitate this).

    ( I realise this post is almost 2 years old, so perhaps views have changed 😛 )

    Comment by Noon Silk — November 26, 2010 @ 6:59 am

  5. Recall that Pixar was a hardware company first. they sold specialized turnkey graphics boxes with software. The evolution as a purely software company was a downsizing in effect. I think as an example it may be more applicable than you first thought.

    Comment by JG — October 9, 2014 @ 12:19 am


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: