Quantum Information Processing with Adversarial Devices

I just came across this on arXiv: Quantum Information Processing with Adversarial Devices. This is a thesis by Matthew McKague out of the University of Waterloo.

I only skimmed the first part of it so far, but seems like some interesting work. Most quantum programming methods proposed make use of Knill's QRAM model, either explicitly or implicitly. Knill's QRAM model essentially states that a quantum computer is a slave device controlled by a classical computer. Given this, I've always pondered the possibility that something could get in between and tweak the input or output of the quantum computer. So along those lines, interesting to see this.

An Overview of Quantum Computing for Technology Managers

I came across this paper on arXiv: An Overview of Quantum Computing for Technology Managers by Eleanor G. Rieffel. It provides a good overview of nearly all aspects of quantum computing. Unfortunately the one area missing was quantum computer programming. It is great to have algorithms and physical implementations, but we still need a way to write code to carry those algorithms out. The closest was the coverage of quantum circuit diagrams. If it were to be expanded in the future to cover quantum computer programming, I would imagine that Knill's QRAM model [1] would play a big part since it is used (sometimes implicitly) in many programming proposals.

This paper is also part of Wiley's Handbook of Technology Management.

References
[1] E. Knill, "Conventions for Quantum Pseudocode," Los Alamos National Laboratory LAUR-96-2724, 1996.

Why we should program quantum computers with frameworks

I knew when I started my doctoral research at Colorado Tech that I wanted to do it in quantum computing. I work on software for a living, so I was thinking it would be good if I could combine the two somehow. It didn't take me long in my literature review to come across and settle on quantum computer programming as a research area as a way to blend on these two areas.

One thing really stood out to me at first: most of the existing proposals for quantum computers were languages designed for quantum computing. However, I think there are very strong reasons for creating frameworks on top of existing classical languages instead of creating new languages:

1. Over 8500 programming languages have been created [1], but in reality only a few see any sort of wide spread use. In my opinion, it is highly unlikely that we'll adopt new languages solely for the purpose of quantum computing.
   
2. By creating a new language the designer(s) must tackle not only the quantum issues, which are hard enough, but all the classical ones as well. We've spent years on classical languages, the focus of quantum programming design efforts should be on quantum computation, not rehashing classical problems. Tackling the classical issues as well distracts from the goal at hand.
   
3. Quantum computing is only typically utilized for part of the computation. Take Shor's algorithm for factoring [2] as an example: a quantum computer is utilized only for part of the algorithm, the rest is classical. Put that in the bigger picture of whatever software is doing the factoring and it becomes clear that quantum computing really does fit into Knill's QRAM model [3] where the quantum computer is a resource of the classical computer.
4. Frameworks are meant to be extended, perhaps in ways the designer didn't envision. Frameworks are much easier to extend (through hot spots [4]) by their very nature than languages are. Extending the framework can lead to more elegant solutions and more readable code as opposed to trying the bend a language to accomplish something the designer didn't intend or want to allow.
   

These were some of the factors that really motivated me to create Cove as a framework instead of creating yet another language. (Cove is a quantum computing framework developed as part of my Doctoral research.) That isn't to say that there aren't a lot of good lessons to be learned from languages- I drew a lot from Omer's QCL [5] as an example. I also drew a lot from Bettelli [6, 7], who also made the point that we should program quantum computers by expanding classical languages.

(I've written about this previously in my dissertation on Cove to a certain degree, this just makes it more explicit in a more condensed blog format.)

References
[1] T. J. Bergin, "A History of the History of Programming Languages," Communications. ACM, vol. 50, p. 5, May 2007 2007.

[2] P. W. Shor, "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer," SIAM Journal on Computing, vol. 26, p. 25, October 1997 1997.

[3] E. Knill, "Conventions for Quantum Pseudocode," Los Alamos National Laboratory LAUR-96-2724, 1996.

[4] H. C. Cunningham, L. Yi, and T. Pallavi, "Framework design using function generalization: a binary tree traversal case study," in Proceedings of the 44th annual Southeast regional conference Melbourne, Florida: ACM, 2006.

[5] B. Omer, "A Procedural Formalism for Quantum Computing," in Theoretical Physics. vol. Masters Vienna: Technical University of Viena, 1998, p. 93.

[6] S. Bettelli, "Towards an architecture for quantum programming," in Mathematics. vol. Ph.D. Trento, Italy: University of Trento, 2002, p. 115.

[7] S. Bettelli, T. Calarco, and L. Serafini, "Toward an architecture for quantum programming," The European Physical Journal D - Atomic, Molecular, Optical and Plasma Physics, vol. 25, p. 19, August 2003 2003.

More Thoughts on Quantum Computers Becoming a Reality

I wrote a few weeks ago in a previous post about William Halal [1] and when we'll have quantum computers. To summarize: the best guess he's gathered from consulting a bunch of experts is 2021 plus or minus 5 years- which seems reasonable to me.

Current computers where an expensive resource when we first had them. It took decades until they were cheap and practical enough where you could have one at home. I think the same will be true with quantum computers, they'll be very expensive at first. For this reason I see them being a shared resource at first. In other words it will be something that multiple classical computers share. That sharing could be at the institution level, such as a university having some available much like early computers. It also isn't unreasonable to think that processing time could be rented out on it, much like Amazon's EC2.

One obvious question is how the classical computers will interact with the quantum computer. Nearly all proposals for programming quantum computers explicitly or implicitly make use of Knill's QRAM model [2]. In Knill's QRAM model the classical computer is the master and the quantum computer is the slave:

Things get a little more complicated when you throw in multiple classical computers for a single quantum resource. Each of them cannot have full control of the quantum resource and have it function correctly. However, Knill's QRAM model can be expanded to include a "quantum controller" between the classical computer(s) and quantum resource:
This has the advantage that all the logic to deal with the clients can be built into the quantum controller. The controller could also talk to the clients through a standardized protocol, meaning that different physical implementations of quantum computers could still be utilized through the same interface. The controller could also do some other things:

• Queue up requests for operations from a client and execute them at once.
  
• On the fly optimization?
• Deal with disconnected clients at any stage in the computation.
  

The list goes on. Obviously the implementation of this is hard. How exactly do the controller and classical computers communicate for instance? A lot of work would have to go into this, which is why I've listed it as an area for future research in my dissertation. Like programming quantum computers, I think we're best off tackling this issue before quantum computers become a reality outside the lab. Doing so will allow us to hit the ground running with quantum computers instead of stumbling along like we did in the early days of classical computing.

References
[1] W. E. Halal, Technology's Promise: Expert Knowledge on the Transformation of Business and Society, 1 ed. New York, NY: Palgrave Macmillan, 2008.
[2] E. Knill, "Conventions for Quantum Pseudocode," Los Alamos National Laboratory LAUR-96-2724, 1996.