Showing posts with label Cove. Show all posts
Showing posts with label Cove. Show all posts
Tuesday, December 21, 2010
Can override the RNG in Cove's local simulation
I checked in a change to Cove's local simulation yesterday that allows for the random number generator to be overridden in classes derived from the quantum register. This was inspired by some discussions I've been having with Noon Silk. My intention for this is to allow users to swap out the random number generator if desired, not to give the simulation predictable behavior for testing and such.
Thursday, December 16, 2010
Building on top of Cove
Noon Silk is building on top of Cove (my quantum computing framework). Specifically you should check out his "qutils" project here and his blog post about it here. For starters it can generate Cove code from qasm files, which is what I used to create the circuit diagrams in my dissertation.
Here's an example of an input:
Transformed to Cove as the output:
Nice to be this seeing done. At one point I had considered building a tool to allow you to create a circuit diagram in a GUI and generate code from it, but it was low on my list and something I never got around to doing. Nice to see this being done, I see it as an excellent tool- especially for students of quantum computer programming.
Here's an example of an input:
Transformed to Cove as the output:
Nice to be this seeing done. At one point I had considered building a tool to allow you to create a circuit diagram in a GUI and generate code from it, but it was low on my list and something I never got around to doing. Nice to see this being done, I see it as an excellent tool- especially for students of quantum computer programming.
Changes to local simulation implementation of Cove
I've gone through and made some changes to the local simulation of Cove. (Cove is the framework for quantum computing I've developed.) Cove separates the what needs to be provided as interfaces from the how, which is provided by implementations to those interfaces. Currently I've supplied a prototype implementation which I refer to as the local simulation implementation. This simulates a quantum computer on the local PC. This is very much a prototype, with some methods not implemented and plenty of room to improve the efficiency of the simulation, the later which has never been a goal of mine.
The change I've made to the local simulation is that the methods are now virtual. I originally intended implementations to be swapped out from one another and not built on each other. So the change to virtual methods opens up a cleaner derived implementation. There may be other changes I make to further promote building implementations on top of each other. These changes were inspired by some discussions I've been having with Noon Silk.
The change I've made to the local simulation is that the methods are now virtual. I originally intended implementations to be swapped out from one another and not built on each other. So the change to virtual methods opens up a cleaner derived implementation. There may be other changes I make to further promote building implementations on top of each other. These changes were inspired by some discussions I've been having with Noon Silk.
Tuesday, June 22, 2010
Simulating Quantum Computers
Here's a good blog post by Tucci: Best Heavy Duty Quantum Computer Simulators. He basically breaks them down into two categories: super computers and distributed grids (like BOINC). For anything heavy duty that is a simulation on a classical computer, those types of approaches are the only real solutions.
There are some approaches to help on a modern PC, although your still much more limited than the above. A quantum register is represented by 2^n complex numbers, where an operation on that register is a 2^n x 2^n matrix of complex numbers. The simple approach is just that, but as you can see, the memory requirements are large: you'll need 2^n complex numbers for the initial state of the register, the 2^n x 2^n complex matrix for the operation, and 2^n complex numbers for the output. One way to cut down the memory needed is to only do the matrix multiplication one row at a time. Doing so you need only 2^n complex numbers for the matrix instead of the entire thing. This is how the current implementation of Cove, my framework for programming quantum computers, currently works. Of course, there are much more elaborate tricks out there for improving the efficiency of quantum computers.
Another area I've been toying with for some time is to utilize more than one core on a system. The easiest approach with the current implementation of Cove would be just to spawn extra threads to do the matrix multiplication pieces. This would come at the cost of the extra 2^n complex numbers for each thread running. So there is a trade off between memory use and faster execution of the simulation. The execution time has been the bottle neck for a lot of the sets of a few handfuls of qubits I've been playing with, so this is something I'll probably get to eventually.
The previous paragraph being said, my goal has always been the creation of a usable framework for quantum computer programming. The simulation has always been something that will allow me to play with existing code, so my focus has never been on making it incredibly efficient.
Cove is setup where a user writes their code against a set of interfaces. With the current incarnation of Cove, the implementation is this simulation I've been talking about. The idea is however, that the simulation implementation could eventually be swapped out with one that runs on an actual quantum computer. In doing so a users code could switch between various implementations (actual quantum computer, my simulation, super computer, grid, etc) with only switching a reference and using statement.
There are some approaches to help on a modern PC, although your still much more limited than the above. A quantum register is represented by 2^n complex numbers, where an operation on that register is a 2^n x 2^n matrix of complex numbers. The simple approach is just that, but as you can see, the memory requirements are large: you'll need 2^n complex numbers for the initial state of the register, the 2^n x 2^n complex matrix for the operation, and 2^n complex numbers for the output. One way to cut down the memory needed is to only do the matrix multiplication one row at a time. Doing so you need only 2^n complex numbers for the matrix instead of the entire thing. This is how the current implementation of Cove, my framework for programming quantum computers, currently works. Of course, there are much more elaborate tricks out there for improving the efficiency of quantum computers.
Another area I've been toying with for some time is to utilize more than one core on a system. The easiest approach with the current implementation of Cove would be just to spawn extra threads to do the matrix multiplication pieces. This would come at the cost of the extra 2^n complex numbers for each thread running. So there is a trade off between memory use and faster execution of the simulation. The execution time has been the bottle neck for a lot of the sets of a few handfuls of qubits I've been playing with, so this is something I'll probably get to eventually.
The previous paragraph being said, my goal has always been the creation of a usable framework for quantum computer programming. The simulation has always been something that will allow me to play with existing code, so my focus has never been on making it incredibly efficient.
Cove is setup where a user writes their code against a set of interfaces. With the current incarnation of Cove, the implementation is this simulation I've been talking about. The idea is however, that the simulation implementation could eventually be swapped out with one that runs on an actual quantum computer. In doing so a users code could switch between various implementations (actual quantum computer, my simulation, super computer, grid, etc) with only switching a reference and using statement.
Thursday, December 24, 2009
Logically manipulating qubits in Cove
In Cove a collection of qubits is represented by an instance of IQuantumRegister. The logical manipulation of qubits in a register is largely inspired by Python's list manipulating, or slicing as it is called. There are a variety of ways these qubits can be logically manipulated, the following illustration demonstrates a few:
In the above the numbers represent the index is represented by numbers, just like you would with an array. The letters A - D represent specific qubits. So you can see the SliceTo(2) operation obtains indexes 0 to 2, resulting in qubits A, B, C. The SliceSubset() operation slices the current indexes to an arbitrary set. In this case the qubit at index 2 (C) will become the first one and the qubit at index 1 (A) will become the second qubit in the new slice.
It is important to point out that each of the slicing operation returns a new instance of IQuantumRegister. This means that the slices can be independently manipulated. That being said, they all share the same qubits: so the manipulation of one slice may impact another. As an example if we perform a Not operation on qubit A, it will be Not'ed in every slice.
This allows for easy applications of operations. Take a CNot (controlled not) operation for example, this is an operation on two qubits. So if we take the original register of 4 qubits and want to perform the operation on qubits A and D we can just do something like this:
MyRegister.SliceSubset(new int[] {0, 3}).OperationCNot();
The OperationCNot() will also return the slice after the operation is performed. So this example shows how operations can be chained together to manipulate the register, then discarded if needed- leaving MyRegister as the original 4 qubits after the above line of code is executed.
In the above the numbers represent the index is represented by numbers, just like you would with an array. The letters A - D represent specific qubits. So you can see the SliceTo(2) operation obtains indexes 0 to 2, resulting in qubits A, B, C. The SliceSubset() operation slices the current indexes to an arbitrary set. In this case the qubit at index 2 (C) will become the first one and the qubit at index 1 (A) will become the second qubit in the new slice.
It is important to point out that each of the slicing operation returns a new instance of IQuantumRegister. This means that the slices can be independently manipulated. That being said, they all share the same qubits: so the manipulation of one slice may impact another. As an example if we perform a Not operation on qubit A, it will be Not'ed in every slice.
This allows for easy applications of operations. Take a CNot (controlled not) operation for example, this is an operation on two qubits. So if we take the original register of 4 qubits and want to perform the operation on qubits A and D we can just do something like this:
MyRegister.SliceSubset(new int[] {0, 3}).OperationCNot();
The OperationCNot() will also return the slice after the operation is performed. So this example shows how operations can be chained together to manipulate the register, then discarded if needed- leaving MyRegister as the original 4 qubits after the above line of code is executed.
Sunday, November 15, 2009
Reducing Memory Requirements in Cove
With Cove, I've never spent much time on making the simulation efficient. Instead I've been focusing my efforts on creating a usable framework. Furthermore, once we have quantum computers any work spent on efficient simulations is largely a mute point.
Not taking into account tricks for efficient simulation, any simulation of a quantum computer requires exponential memory. This is best illustrated by expressing a quantum register (a collection of qubits) as a matrix. Each cell in the matrix is the probability amplitude of the register collapsing to that state. (These are also complex numbers.) As an example, we can consider a two qubit register:
So that's why we need an exponential number of cells: 1 qubit is expressed by 2 complex numbers, 2 qubits by 4 complex numbers, 3 by 8 complex numbers, and so on.
Operations are expressed by a 2^n x 2^n matrix, when they operate on n qubits. So a controlled not operation is a 4 x 4 matrix. Simple linear algebra shows how the operation is applied, here is an example of performing a not operation:
The math dictates that the operation is that 2^n x 2^n matrix. So what happens when the not operation is applied to a 4 qubit register? In Cove I used explicit matrix expansion [1]. That means that the matrix of the operation is expanded, in this case it would be a 16 x 16 matrix. Obviously this eats up a bunch of memory and this was pretty obvious early on. So to apply an operation on a n qubit register I needed 2n + (2^n)^2 complex numbers: the 2n for the state of the register before and after, and the (2^n)^2 for expanded operation. With this I hit memory limitations with no more than a few handfuls of qubits.
This past week I reduced the memory requirements quite a bit in change set [925]. This is something I've been meaning to do since this past spring. Basically what I did was expand the operation matrix one row at a time instead of all at once. This essentially cut the memory requirements down to 3n for a n qubit matrix. So I should be able to simulate much larger systems now.
References
[1] L. Spector, Automatic Quantum Computer Programming: A Genetic Programming Approach, 1 ed. New York, NY: Springer Science and Business Media, LLC, 2004.
Not taking into account tricks for efficient simulation, any simulation of a quantum computer requires exponential memory. This is best illustrated by expressing a quantum register (a collection of qubits) as a matrix. Each cell in the matrix is the probability amplitude of the register collapsing to that state. (These are also complex numbers.) As an example, we can consider a two qubit register:
So that's why we need an exponential number of cells: 1 qubit is expressed by 2 complex numbers, 2 qubits by 4 complex numbers, 3 by 8 complex numbers, and so on.Operations are expressed by a 2^n x 2^n matrix, when they operate on n qubits. So a controlled not operation is a 4 x 4 matrix. Simple linear algebra shows how the operation is applied, here is an example of performing a not operation:
The math dictates that the operation is that 2^n x 2^n matrix. So what happens when the not operation is applied to a 4 qubit register? In Cove I used explicit matrix expansion [1]. That means that the matrix of the operation is expanded, in this case it would be a 16 x 16 matrix. Obviously this eats up a bunch of memory and this was pretty obvious early on. So to apply an operation on a n qubit register I needed 2n + (2^n)^2 complex numbers: the 2n for the state of the register before and after, and the (2^n)^2 for expanded operation. With this I hit memory limitations with no more than a few handfuls of qubits.This past week I reduced the memory requirements quite a bit in change set [925]. This is something I've been meaning to do since this past spring. Basically what I did was expand the operation matrix one row at a time instead of all at once. This essentially cut the memory requirements down to 3n for a n qubit matrix. So I should be able to simulate much larger systems now.
References
[1] L. Spector, Automatic Quantum Computer Programming: A Genetic Programming Approach, 1 ed. New York, NY: Springer Science and Business Media, LLC, 2004.
Thursday, November 12, 2009
Cove Dissertation Published on arXiv Today
My dissertation on Cove, my framework for quantum computing, was published on arXiv today. Here's the link: http://arxiv.org/abs/0911.2423. I've already posted several other locations it can be obtained from, but arXiv is a pretty well known site for others in the field.
Saturday, October 31, 2009
Ramping up work on Cove again
I really have not spent too much time working on Cove (my quantum computing framework) for a few months while I wrapped up my dissertation and took some time off. I'll be starting to ramp up work on Cove again in the coming weeks. My initial target will be reducing the memory requirements of the simulation so that I can carry out larger ones. (Efficient simulation has never been a goal.) After that I plan to continue the factoring example, followed by work on some papers.
Thursday, September 17, 2009
Cove Dissertation Finished
I've finished my doctoral dissertation at Colorado Technical University, titled "Cove: A Practical Quantum Computer Programming Framework". I'll be pushing it elsewhere onto the net later on, but for now you can down load it from my Cove site here.
Here's the abstract:
While not yet in commercial existence, quantum computers have the ability to solve certain classes of problems that are not efficiently solvable on existing Turing Machine based (classical) computers. For quantum computers to be of use, methods of programming them must exist. Proposals exist for programming quantum computers, but all of the existing ones suffer from flaws that make them impractical in commercial software development environments. Cove is a framework for programming quantum computers that extends existing classical languages to allow for quantum computation, thus providing a quantum computing toolkit for commercial software developers. Since the target users of Cove are commercial developers, it is an object oriented framework that can be used by multiple languages and also places emphasis on complete documentation. The focus of Cove is not so much on the software product, but on the fundamental concepts that make quantum computing practical for common developers.
While a little lengthy, it has a lot of good background information in chapter 2 for quantum computing novices. The circuit diagrams for building up Shor's algorithm in chapter 4 and the complete list of quantum operations should also be interest to some- not to mention the framework itself.
Tuesday, August 25, 2009
Animoto Video of Cove
I was playing around with Animoto, which lets you put together a video to music from images and music. It is pretty simple to use and does a great job of blending the music and video.
I put together a quick little video (30 seconds) using some images from my dissertation on Cove:
Per Dr. Calongne's suggestion I used music from the Animoto site itself to avoid any digital rights problems.
I put together a quick little video (30 seconds) using some images from my dissertation on Cove:
Per Dr. Calongne's suggestion I used music from the Animoto site itself to avoid any digital rights problems.
Sunday, August 16, 2009
Tuesday, July 21, 2009
Cloud Computing
The Horizon Report (2009) lists cloud computing as a technology taking hold in one year or less [1]. I would argue that it has taken hold already, as the article lists several examples.
How does cloud computing play into quantum computer programming? I see it as having the potential for carrying out large simulations of quantum computers. With Cove [2] I ran into memory and computation constraints pretty early on when simulating just a few handfuls of qubits. Taking advantage of multiple cores is an obvious first step, but utilizing the cloud would allow for even larger simulations. Of course the problem has to be decomposed to take advantage of the cloud, but simulations essentially boil down to multiplication between large matrices.
Of course an obvious advantage of using the cloud is the pay as you go model. Instead of building up a lab to run my simulation, I can just take advantage of the cloud and avoid the expense and overhead of setting up this lab.
References
[1] NMC. (2009). Cloud Computing - The Horizon Project, New Media Consortium, 2009. Retrieved July 21, 2009, from http://horizon.nmc.org/wiki/Cloud-Computing
[2] https://cove.purkeypile.com/
Cove Presentation Posted
I did a presentation on Cove (the quantum computer programming framework I've developed) last week at Colorado Technical University. It is the slides that are in the last post, along with my presentation of them and some question and answers.
Friday, July 17, 2009
Cove: A Practical Quantum Computer Programming Framework
My doctoral research at Colorado Technical University has been in quantum computer programming. As part of that I developed a framework for programming quantum computers, called Cove. You can find presentations, source code, etc on the site for Cove.
The slides from my dissertation defense give a pretty good introduction to quantum computers, and how Cove fits in. You can find the slides on the Cove website or on slideshare.net:
The slides from my dissertation defense give a pretty good introduction to quantum computers, and how Cove fits in. You can find the slides on the Cove website or on slideshare.net:
Subscribe to:
Posts (Atom)
