All users will need to merge their Minecraft Forum account with a new or existing Twitch account starting October 23rd. You can merge your accounts by clicking here. Have questions? Learn more here.

Wow your progress is so fast especially for being seemingly bug free! You are definitely correct about the circuit board being the simpler method by far. I assume when you click the control box it just processes everything in one go. (I would be interested to see the code in detail even though i do not know enough java to do anything with it. I have enough background to follow along.) Two questions i have, first you mentioned in this video that when you implement a controlled-gate that the other half will appear. but in more then 2 qubit systems how will it know which qubit to put it on? I like the idea of a control block and some wire that goes to the controlled block. Though you technically only need 3 gates for universality I like that you have implemented more then that. Its just convenient not to have to build a Z gate from an X gate and 2 hadamards.The second thing is could you show us how the detectors deal with a qubit coming in that is not in the |0>, |1> basis? say in the |+>,|-> basis? I'm not sure how your detectors work but i assume they measure in the standard basis and when a qubit is in superposition It uses a random number generator to chose in it out puts 1 or 0. and then does the appropriate projection on the other qubit. (assuming they are entangled.) Since they are all measured simultaneously though. there must be some priority as to which one is "technically" measured first. Since the results of other inputs can depend on it.

Ok. To sum things up from your previous posts and the pm.

I will add measure gates to the circuit, that can be placed on individual qubits. It will not be hard.

About the teleportation etc. Do you think it would be a good idea to make the "transmitters" to be of two different types? One could measure and transmit redstone (like it works now), the other could not measure and somehow transmit the qubits?

About the matrices - yes there is a tensor product. At this point every qubit is tensored. If this is a circuit:

0 --x---> qubit 1
0 x---x-> qubit 0

Then the matrix is calculated:

M0 = X tensor I
M1 = I tensor X
M2 = X tensor I

Then the system is calculated by multiplying those. I have pre-calculated matrices for controlled gates and swap and other stuff that can't be made by simple tensoring.

Basically I create the entire "hamiltonian", so that I can study it. I know this isn't practical, and it means extra work but I want to be able to see and classify the matrix (if it's a permutation matrix, and in that case find the cycles etc.). I honestly don't care that much about the quantum stuff, but I'm very interested in the computation stuff so that's why.

This will have to be made more flexible later i suppose.

I understand what you are saying about placing the controls and other gates separately, and thus "compose" them rather then use hard-coded ones. I actually started out like that but it became very hard to keep track of all gates, so I failed, and instead switched to a simpler model. Hard-coded multi-gates solved the matrix issues etc. There's no technical reasons why that shouldn't work afaik, it only failed beacuse I couldn't come up with a good way of managing it.

Multi-gates has to be placed on adjacent "lines" atm. You can't place a swap gate between qubits 1 and 3, for example. Only adjacent qubits can be swapped. You'd have to place 3 ones 1-2, 2-3, 2-1. I figured as long as it's actually possible, tho a bit un-pleasant, it still "works", and can be improved later. Again, this is just a "fail". Not a choice because I thought it'd be better.

I'm glad you are doing the gates that way. It was exactly how i thought would be the best way. What is more it makes multiqubits gates easier to write. I think what you were missing was how to properly represent the control since it is not typical.

lets use this as an example

---X---- qubit 1 ---C--- qubit 0

this gate looks like (|0><0|*I+|1><1|*X)

here i'm using the * to mean tensor product since i can't find a better symbol and the outer product notations |0><0|=

1 0 0 0

|1><1|=

0 0 0 1

the benefit of this is that lets say you have:

----X---- ---------- ----Y---- ----C----

this is easily generated as:

|0><0|*I*I*I+|1><1|*(Y*I*X)

the part i put in brackets is just what the gates for those three qubits would have evaluated to anyways.

I'm still working out how to implement 2 controls in a single column. This would allow implementation of the toffoli. and i'm sure i can figure out the general swap gate too. just need some time to mull it over.

Of course if the second qubit is the control then the |0><0|, |1><1| are now for the second qubit. So that should make it easier to to code in. the 0 will always ignore all the other gates in the column and the 1 will treat them as normal. I feel this would clean up usability tremendously, though it might mess up the blue cross lines...

Generating the full operation is not really a problem right now... But it might become one with early transmitters (measurement devices). Since measurement devices act probabilistically, the output from them is not determined til the measurement is actually taken. Does that make sense? This would result in what might be a fairly fundamental change to the framework :S each gate would have to be evaluated in turn as the qubit passes through them. In essence when we right click the control box a wave of qubits is generated and they move at a constant rate down the blue wire At each step the matrix being applied is calculated based on where all the qubits are. I guess a sort of example would be like redstone, it has to find all connected redstone at each step and perform some operation. The only difference is that we have to keep track of the states of all qubits simultaneously. :S

I do feel like that is the next logical step for the mod though because it gives us so much flexibility. The downside is the realtime matrix computations. I suspect that since some qubits may not be entangled with other we could preform some sort of dimension shrinking idea to speed this up. But that's more of an optimization problem for after it actually works.

The transmitters... The kind that output redstone is a must. It possibly should also output a qubit in the measured state. Just to be consistent. We would then also need to be able to control whether or not a gate is "active" by applying a redstone signal. I figure that part should be fairly easy for you considering that the qubit creators at the beginning are redstone responsive. My worry if it might be counter-intuitive, We would need to power a gate in order to de-activate it. Maybe that isn't so bad.

Anyways that's all I have for now, I will continue working on the general Swap and multiple controls gates.

This is great. Your work is much appreciated. I understand what you do with the outer products, and will be able to add it. This "finer grained" system will replace the current one, but it will take me some time. Also I agree - lets postpone optimization until everything is in place and we know how it will work.

The newest mod version has Toffoli and Fredkin gates and some more "hard coded" 2 qubit ones in it btw. Gonna compile that soon and put it up. It can at least work as a temporary solution.

I have decided to prepare for the new system by multi-threading the calculations. Large matrix multiplies, tensor products etc. will be processed on multiple threads, and when the circuit is run, the calculations will be done on a separate thread.

I'm adding a light to the circuit board. It will be green when the circuit is done and ready to go. When calculations is taking place it will be another color (i think yellow), and if there are errors on the board it will be red. I think it will be possible to mess up the circuit with all the new freedom that comes with free gate composition, so the light could be used to indicate that the board cannot be used in its current state. If the light is red (circuit is broken) or yellow (busy), it will not be possible to run the circuit.

This has the benefit of utilizing more cpu cores, and lengthy calculations will not freeze the game but run in the background. I think I'll add a maximum running time option to the interface as well, so people can set "max runtime 60 seconds" as a safety, in case they happen to create an enormous matrix by misstake that would take minutes/hours to process.

Input is welcome.

Also, I am having computer/networking issues, so I don't put up new versions. I'm installing windows 8 instead of linux on my powerful computer, but I'm waiting on a new dvd rom. When it arrives (in a few days), i will be able to do everything on that one, instead of passing stuff between it an my laptop. Gonna put up new versions then.

I figured out a general swap. I don't really like it but it works. The swap gate is equivalent to

--C--X--C-- --X--C--X--

this can be verified on paper easily enough. I'm having trouble figuring out how to directly construct it because I can't write it in separable subspaces

I will keep looking but i'm not too hopeful. Its not that bad in the end though. It just means that when the two swaps are placed they perform the general c-not calculation i told you before three times. That being said...

Programming wise there might be a simpler solution. this wouldn't be available to us quantum mechanically because it involves copying the unknown state (violating the no cloning theorem) but we can fudge it since we are only simulating a quantum system.

just do

copy b to temp copy a to b copy temp to a

Problem with this is that it requires that the operations are carried out one by one since this isn't a matrix operation which we haven't implemented yet. so....

the constructed swap method will work right now. so i guess that is the best one to go with. Only two swap gates can go in a single column otherwise we won't know which ones are switching with which other ones (unless you can find a work around for that, some kind of linker)

Sorry this response isn't as helpful as previous ones. I have been hindered by poor internet speeds over the past two days.

I should mention that since X, Y, Z, phase pi/8 and CNOT are universal, any other gate can be constructed as some combination of them. for example the toffoli is

now that V would also have to be constructed from one qubit gates. so it starts to get messy. Luckily the fredkin is just controlled swap so once we have the previous two we also have that one.

toffoli is going to be tough. More thinking required. But once that is complete we will have a unified gate method with no hard coded gates necessary

Hey so I think i might have a solution for the multicontrol gate construction. Its relatively simple, but recursive (shouldn't be a big deal) the idea is that at a particular column in the circuit, the qubits are checked in order for a control gate, once one is found, the remainder of the gate is passed back to the same function and it looks for another. This should happen at most the number of qubits in the circuit so it shouldn't hinder the processing. This method would basically completely replace the current technique. and if i can integrate swaps in to... there will only be one case. However Since this is rather complicated I would like to try and code it up in Matlab so at least you will have some code to go off of and just have to make the necessary adjustments for use in Java. But I don't know if you have Matlab, if not you should still be able to read the code with a text editor. I just want to make this as easy as possible for you to implement. Sometimes just describing the code isn't clear enough right? Plus I can test to make sure it works.

I'm glad you've got your computer all up and running! Also (i know its a bit delayed) but I like the multi-threading Idea. I know its kind of silly to ask these days but what happens if someone tries to run it on a processor without multiple cores? or can Minecraft even do that? Regardless good luck. I spent most of this weekend learning how to program with CUDA. Its fun. but the memory allocation between global and shared gave me a headache, especially because of the large size of my data set. Best of luck!

I still haven't got Forge installed. I have had 0 internet connection for 2 days so I couldn't download anything. I might try it tonight and then I can actually try this out for myself!

I guess that's all for now. Let me know how the new version comes. Also what are these new hardcoded 2 qubit gates? I want to make sure I can handle them. I should get the Matlab file to you by tomorrow with luck.

This seems good. I did some Matlab in school and can probably understand. Don't waste time tho your research work must be a lot more important :D. In fact it kind of stresses me out that you take time from it. Sorry hehe.

That aside, if you wanna do code, C would be just as good as Matlab. Since you mention CUDA im guessing you know it. C is my first language so no problems.

If there is just one processor with one core and you run multiple threads, basically the processor jumps back and forth between the threads, so it's still as if they're run in parallell. It might be a (slight) performance penalty when running multiple threads, and it will still lag when run on one single core, but I feel it's still worth it just so the game doesn't completely freeze. Any potential performance increase is just a bonus.

Also, since you mentioned CUDA, I don't think GPU calculations are possible, but I may be wrong. LWJGL has openCL bindings, and technically it is possible to stick a few calculations in between the rendering stuff (there is cl/gl interop), but I'm pretty sure you can't create an openCL context from an already existing openGL context and just start using it. I think it has to be done in a different way. And of course all the graphics hardware incompatibility issues would be hell (I'm looking at you Intel..). Maybe it would be a good goal for the future tho, or at least worth looking in to.

I have finished a first working version of the new matrix generation technique. I did end up writing it in Matlab only because while learning CUDA definitely refreshed my C proficiency I'm nowhere near where i use to be. Also Matlab makes matrices really easy and the interface allows me to rapidly "prototype" the logic behind the code. All in all it took me about an hour or two to whip this up. Its not particularly difficult. But the handling of particular cases can be sensitive. Especially because almost any time there is a control gate one of the partitions ends up "Bottoming out" to an empty vector which needs special attention. There is extensive comments in the .m file itself. Let me know if there are any troubles understanding it.

Its not done yet though. As I was working through it I noticed a particular problem with Swap gates the example is

-----SWAP----
--------C-------
-----SWAP----

With the partitioning method if I try to calculate the swaps after the controls i run into problems since the swaps appear in separate paritions. I have a solution but the details haven't quite been hashed out yet basically i will need to turn the above into the equivalent of

This will have to be implemented above the level of what I am sending you. So in all likely hood that code will not change but it might be called from a separate function that deals with your 2-qubit gates. Its up to you if you would rather wait til the final product or get a start on transforming this code into something use able.

Don't be stressed about the amount of time i spend on this. It really isn't all that much. And its fun! So its kind of a treat to me. I am worried that I come across as sending down commandments from on high I like to get my hands dirty but I sadly do not have the skills you do.

I agree with you. Multi-threading good. CUDA/GPU... maybe later? I'm not sure we need that extreme level of multi threading yet. Plus I'm not sure the functions are particularly well suited for it except on the level of performing the tensor products and matrix multiplication. If its something we have troubles with in the future. It might be worth looking into. I was learning CUDA for my research. What I learned is, Unless you REALLY need it, Its probably not worth the effort.

By the way. I'll send the matlab file through a PM (if i can)

I have the .m file and started working already. I have a few questions though.

1) Is it really neccessary to allow every single possible combination of gates? It would be a simple thing to disallow controls to be placed "inside" of a swap gate, etc.

2) If I want to place gates like this:

X = X gate.
C = Control gate.

▷---X---▢
▷---C---▢
▷---X---▢

I want the upper X to be controlled, but the lower X to be independent of the other qubits. How would the algorithm know that?

Short answer: It doesn't.
long answer: I have set it up so that if there is a control gate in a column, It applies to ALL of the gates in that column. This is what allows for the tofolli gate to be implemented since 2 controls have to simultaneously act on a not gate.

Basically its identical to saying. in order to the operations in the rest of the column to be implemented all of these control conditions must be met. I set it up this way because while yes it might make the circuits a little longer to implement in physical space. It is much simpler code wise to implement. The only way i can see around this is if you had some kind of "correlator" but even then how would it know when you wanted a single gate to be controlled by two gates. Also when you want to produce a controlled unitary on many qubits. It is simple to do so. Over all i figured this was the most intuitive way to do for the user. As long as they understand if a conrtol is in a column. that column only implemented if the control is 1. If you don't like it please let me know. we can brainstorm alternatives that have the same flexibility.

Number 1
While I agree handling EVERY gate combination would be necessary I feel like disallowing controls to be in between swaps is an artificial constraint that will not be at all intuitive why its not working. Unlike the other case where you can't have two swap operations (4 swap gates) in a single column which will also be impossible. The reason for that constraint is that if you put down 2 sets of swaps or maybe even just 3 swap gates what is it you are really trying to do? I feel like the user will understand why you can't do that.

My final reason is that ultimately its going to be just as hard to try to incorporate swap gates only appearing on one side of a control as it will be to have then on both sides. the only difference if how you handle the cases. In order to handle the swap gates being anywhere we need to deal with them first (translating them into their control and not counterparts and then use the function. In the end it will be more unified. I only haven't implemented it yet because It requires a more delicate handling. I probably can get you the modified .m file that can handle swap in one or two hours. I took a break to let it coalesce.

Sending you an updated gen_matrix function. The op_gen function has not changed. i just added in the pre-processing capabilities to handle swaps. Turned out easier then i thought.

I have done some testing. I have verified that the fredkin gate is implementable (code [8,7,7])

I should note. throughout i have been passing around a variable called "err" I think i have covered all the cases. For instance it now sets err to 1 if there are too many swaps in a column. Mostly i have included it so that it might fit into the framework of the status block for you. If one of thiese matrix gen functions returns an err=1 then the circuit is broken. all calculations should be terminated because i haven't been too careful with what M is in these cases

Would you like to learn how to build quantum circuits?This is a quantum computing mod. It lets you build quantum circuits.

FeaturesIf you want to include this mod in amodpack, just include it and add a link to this page somewhere, so that people can find us. Thanks.Artistic interpretation of superposition andquantum teleportaiton by Byamarro.JamtlandOutdoors(Andreas, QCBot)To Be UpdatedJamtlandOutdoors(Andreas, QCBot)JamtlandOutdoors(Andreas, QCBot)I will add measure gates to the circuit, that can be placed on individual qubits. It will not be hard.

About the teleportation etc. Do you think it would be a good idea to make the "transmitters" to be of two different types? One could measure and transmit redstone (like it works now), the other could not measure and somehow transmit the qubits?

About the matrices - yes there is a tensor product. At this point every qubit is tensored. If this is a circuit:

0 --x---> qubit 1

0 x---x-> qubit 0

Then the matrix is calculated:

M0 = X tensor I

M1 = I tensor X

M2 = X tensor I

Then the system is calculated by multiplying those. I have pre-calculated matrices for controlled gates and swap and other stuff that can't be made by simple tensoring.

Basically I create the entire "hamiltonian", so that I can study it. I know this isn't practical, and it means extra work but I want to be able to see and classify the matrix (if it's a permutation matrix, and in that case find the cycles etc.). I honestly don't care that much about the quantum stuff, but I'm very interested in the computation stuff so that's why.

This will have to be made more flexible later i suppose.

I understand what you are saying about placing the controls and other gates separately, and thus "compose" them rather then use hard-coded ones. I actually started out like that but it became very hard to keep track of all gates, so I failed, and instead switched to a simpler model. Hard-coded multi-gates solved the matrix issues etc. There's no technical reasons why that shouldn't work afaik, it only failed beacuse I couldn't come up with a good way of managing it.

Multi-gates has to be placed on adjacent "lines" atm. You can't place a swap gate between qubits 1 and 3, for example. Only adjacent qubits can be swapped. You'd have to place 3 ones 1-2, 2-3, 2-1. I figured as long as it's actually possible, tho a bit un-pleasant, it still "works", and can be improved later. Again, this is just a "fail". Not a choice because I thought it'd be better.

JamtlandOutdoors(Andreas, QCBot)lets use this as an example

---X---- qubit 1

---C--- qubit 0

this gate looks like (|0><0|*I+|1><1|*X)

here i'm using the * to mean tensor product since i can't find a better symbol and the outer product notations

|0><0|=

1 0

0 0

|1><1|=

0 0

0 1

the benefit of this is that lets say you have:

----X----

----------

----Y----

----C----

this is easily generated as:

|0><0|*I*I*I+|1><1|*(Y*I*X)

the part i put in brackets is just what the gates for those three qubits would have evaluated to anyways.

I'm still working out how to implement 2 controls in a single column. This would allow implementation of the toffoli. and i'm sure i can figure out the general swap gate too. just need some time to mull it over.

Of course if the second qubit is the control then the |0><0|, |1><1| are now for the second qubit. So that should make it easier to to code in. the 0 will always ignore all the other gates in the column and the 1 will treat them as normal. I feel this would clean up usability tremendously, though it might mess up the blue cross lines...

Generating the full operation is not really a problem right now... But it might become one with early transmitters (measurement devices). Since measurement devices act probabilistically, the output from them is not determined til the measurement is actually taken. Does that make sense? This would result in what might be a fairly fundamental change to the framework :S each gate would have to be evaluated in turn as the qubit passes through them. In essence when we right click the control box a wave of qubits is generated and they move at a constant rate down the blue wire At each step the matrix being applied is calculated based on where all the qubits are. I guess a sort of example would be like redstone, it has to find all connected redstone at each step and perform some operation. The only difference is that we have to keep track of the states of all qubits simultaneously. :S

I do feel like that is the next logical step for the mod though because it gives us so much flexibility. The downside is the realtime matrix computations. I suspect that since some qubits may not be entangled with other we could preform some sort of dimension shrinking idea to speed this up. But that's more of an optimization problem for after it actually works.

The transmitters... The kind that output redstone is a must. It possibly should also output a qubit in the measured state. Just to be consistent. We would then also need to be able to control whether or not a gate is "active" by applying a redstone signal. I figure that part should be fairly easy for you considering that the qubit creators at the beginning are redstone responsive. My worry if it might be counter-intuitive, We would need to power a gate in order to de-activate it. Maybe that isn't so bad.

Anyways that's all I have for now, I will continue working on the general Swap and multiple controls gates.

The newest mod version has Toffoli and Fredkin gates and some more "hard coded" 2 qubit ones in it btw. Gonna compile that soon and put it up. It can at least work as a temporary solution.

I have decided to prepare for the new system by multi-threading the calculations. Large matrix multiplies, tensor products etc. will be processed on multiple threads, and when the circuit is run, the calculations will be done on a separate thread.

I'm adding a light to the circuit board. It will be green when the circuit is done and ready to go. When calculations is taking place it will be another color (i think yellow), and if there are errors on the board it will be red. I think it will be possible to mess up the circuit with all the new freedom that comes with free gate composition, so the light could be used to indicate that the board cannot be used in its current state. If the light is red (circuit is broken) or yellow (busy), it will not be possible to run the circuit.

This has the benefit of utilizing more cpu cores, and lengthy calculations will not freeze the game but run in the background. I think I'll add a maximum running time option to the interface as well, so people can set "max runtime 60 seconds" as a safety, in case they happen to create an enormous matrix by misstake that would take minutes/hours to process.

Input is welcome.

Also, I am having computer/networking issues, so I don't put up new versions. I'm installing windows 8 instead of linux on my powerful computer, but I'm waiting on a new dvd rom. When it arrives (in a few days), i will be able to do everything on that one, instead of passing stuff between it an my laptop. Gonna put up new versions then.

JamtlandOutdoors(Andreas, QCBot)JamtlandOutdoors(Andreas, QCBot)JamtlandOutdoors(Andreas, QCBot)--C--X--C--

--X--C--X--

this can be verified on paper easily enough. I'm having trouble figuring out how to directly construct it because I can't write it in separable subspaces

I will keep looking but i'm not too hopeful. Its not that bad in the end though. It just means that when the two swaps are placed they perform the general c-not calculation i told you before three times. That being said...

Programming wise there might be a simpler solution. this wouldn't be available to us quantum mechanically because it involves copying the unknown state (violating the no cloning theorem) but we can fudge it since we are only simulating a quantum system.

just do

copy b to temp

copy a to b

copy temp to a

Problem with this is that it requires that the operations are carried out one by one since this isn't a matrix operation which we haven't implemented yet. so....

the constructed swap method will work right now. so i guess that is the best one to go with. Only two swap gates can go in a single column otherwise we won't know which ones are switching with which other ones (unless you can find a work around for that, some kind of linker)

Sorry this response isn't as helpful as previous ones. I have been hindered by poor internet speeds over the past two days.

I should mention that since X, Y, Z, phase pi/8 and CNOT are universal, any other gate can be constructed as some combination of them. for example the toffoli is

http://physics.stack...d-1-qubit-gates

now that V would also have to be constructed from one qubit gates. so it starts to get messy. Luckily the fredkin is just controlled swap so once we have the previous two we also have that one.

toffoli is going to be tough. More thinking required. But once that is complete we will have a unified gate method with no hard coded gates necessary

ttyl

I'm glad you've got your computer all up and running! Also (i know its a bit delayed) but I like the multi-threading Idea. I know its kind of silly to ask these days but what happens if someone tries to run it on a processor without multiple cores? or can Minecraft even do that? Regardless good luck. I spent most of this weekend learning how to program with CUDA. Its fun. but the memory allocation between global and shared gave me a headache, especially because of the large size of my data set. Best of luck!

I still haven't got Forge installed. I have had 0 internet connection for 2 days so I couldn't download anything. I might try it tonight and then I can actually try this out for myself!

I guess that's all for now. Let me know how the new version comes. Also what are these new hardcoded 2 qubit gates? I want to make sure I can handle them. I should get the Matlab file to you by tomorrow with luck.

That aside, if you wanna do code, C would be just as good as Matlab. Since you mention CUDA im guessing you know it. C is my first language so no problems.

If there is just one processor with one core and you run multiple threads, basically the processor jumps back and forth between the threads, so it's still as if they're run in parallell. It might be a (slight) performance penalty when running multiple threads, and it will still lag when run on one single core, but I feel it's still worth it just so the game doesn't completely freeze. Any potential performance increase is just a bonus.

Also, since you mentioned CUDA, I don't think GPU calculations are possible, but I may be wrong. LWJGL has openCL bindings, and technically it is possible to stick a few calculations in between the rendering stuff (there is cl/gl interop), but I'm pretty sure you can't create an openCL context from an already existing openGL context and just start using it. I think it has to be done in a different way. And of course all the graphics hardware incompatibility issues would be hell (I'm looking at you Intel..). Maybe it would be a good goal for the future tho, or at least worth looking in to.

JamtlandOutdoors(Andreas, QCBot)JamtlandOutdoors(Andreas, QCBot)There are lists in the main post of blocks and items, and info on what to do.

SMP seems to work (do try it), but I want to do some more testing before officially labeling it a multiplayer mod.

JamtlandOutdoors(Andreas, QCBot)I have finished a first working version of the new matrix generation technique. I did end up writing it in Matlab only because while learning CUDA definitely refreshed my C proficiency I'm nowhere near where i use to be. Also Matlab makes matrices really easy and the interface allows me to rapidly "prototype" the logic behind the code. All in all it took me about an hour or two to whip this up. Its not particularly difficult. But the handling of particular cases can be sensitive. Especially because almost any time there is a control gate one of the partitions ends up "Bottoming out" to an empty vector which needs special attention. There is extensive comments in the .m file itself. Let me know if there are any troubles understanding it.

Its not done yet though. As I was working through it I noticed a particular problem with Swap gates the example is

-----SWAP----

--------C-------

-----SWAP----

With the partitioning method if I try to calculate the swaps after the controls i run into problems since the swaps appear in separate paritions. I have a solution but the details haven't quite been hashed out yet basically i will need to turn the above into the equivalent of

-----C-----X------C-----

-----C-----C------C-----

-----X------C------X-----

This will have to be implemented above the level of what I am sending you. So in all likely hood that code will not change but it might be called from a separate function that deals with your 2-qubit gates. Its up to you if you would rather wait til the final product or get a start on transforming this code into something use able.

Don't be stressed about the amount of time i spend on this. It really isn't all that much. And its fun! So its kind of a treat to me. I am worried that I come across as sending down commandments from on high I like to get my hands dirty but I sadly do not have the skills you do.

I agree with you. Multi-threading good. CUDA/GPU... maybe later? I'm not sure we need that extreme level of multi threading yet. Plus I'm not sure the functions are particularly well suited for it except on the level of performing the tensor products and matrix multiplication. If its something we have troubles with in the future. It might be worth looking into. I was learning CUDA for my research. What I learned is, Unless you REALLY need it, Its probably not worth the effort.

By the way. I'll send the matlab file through a PM (if i can)

Thats all for now!

1) Is it really neccessary to allow every single possible combination of gates? It would be a simple thing to disallow controls to be placed "inside" of a swap gate, etc.

2) If I want to place gates like this:

X = X gate.

C = Control gate.

▷---X---▢

▷---C---▢

▷---X---▢

I want the upper X to be controlled, but the lower X to be independent of the other qubits. How would the algorithm know that?

JamtlandOutdoors(Andreas, QCBot)Short answer: It doesn't.

long answer: I have set it up so that if there is a control gate in a column, It applies to ALL of the gates in that column. This is what allows for the tofolli gate to be implemented since 2 controls have to simultaneously act on a not gate.

Basically its identical to saying. in order to the operations in the rest of the column to be implemented all of these control conditions must be met. I set it up this way because while yes it might make the circuits a little longer to implement in physical space. It is much simpler code wise to implement. The only way i can see around this is if you had some kind of "correlator" but even then how would it know when you wanted a single gate to be controlled by two gates. Also when you want to produce a controlled unitary on many qubits. It is simple to do so. Over all i figured this was the most intuitive way to do for the user. As long as they understand if a conrtol is in a column. that column only implemented if the control is 1. If you don't like it please let me know. we can brainstorm alternatives that have the same flexibility.

Number 1

While I agree handling EVERY gate combination would be necessary I feel like disallowing controls to be in between swaps is an artificial constraint that will not be at all intuitive why its not working. Unlike the other case where you can't have two swap operations (4 swap gates) in a single column which will also be impossible. The reason for that constraint is that if you put down 2 sets of swaps or maybe even just 3 swap gates what is it you are really trying to do? I feel like the user will understand why you can't do that.

My final reason is that ultimately its going to be just as hard to try to incorporate swap gates only appearing on one side of a control as it will be to have then on both sides. the only difference if how you handle the cases. In order to handle the swap gates being anywhere we need to deal with them first (translating them into their control and not counterparts and then use the function. In the end it will be more unified. I only haven't implemented it yet because It requires a more delicate handling. I probably can get you the modified .m file that can handle swap in one or two hours. I took a break to let it coalesce.

Hope that explains why i did it the way i did.

I have done some testing. I have verified that the fredkin gate is implementable (code [8,7,7])

I should note. throughout i have been passing around a variable called "err" I think i have covered all the cases. For instance it now sets err to 1 if there are too many swaps in a column. Mostly i have included it so that it might fit into the framework of the status block for you. If one of thiese matrix gen functions returns an err=1 then the circuit is broken. all calculations should be terminated because i haven't been too careful with what M is in these cases

Hope this is helpful. (see PM for the code)

I'm gonna edit the minecraft stuff also (placement etc.) which is going to take some time. I think this will take at least a few days.

JamtlandOutdoors(Andreas, QCBot)