So,
What are some reasonable semantics to use for visualizing QC operations?
; -- starts a comment
#output "file" -- specify the destination of the image,
where "file" can also be a string variable
#state clockvec -- indicate the Qubits state should be shown by an angular pointing vec;
#state vec2 -- indicate the Qubits state should be shown by to angular vectors
#state color -- indicate the Qubits state should be indicated by it's color
#state light -- indicate the Qubits state should be indicated by the
direction from which it is lit
#nstates n -- set the number of possible states
str vname -- create a null string variable
int vname -- create an integer variable
float vname -- create a floating point variable
Qfile[n,m] qname -- indicate a `register file' of Qubits n wide, and m high;
Qubit[i,j] where index (i) starts from zero,
indicating the leftmost qubit,
and index (j) indicates the topmost row of Qubits;
Qubit[i] = Qubit[i'] The Qubit at i receives the state from i';
Qubit[i,j] = Qubit[i',j']
The Qubit at i,j receives the state from i', j';
The implication is that simple programs might look as follows:
; A simple carry visualizer?
#nstates 2
int f
f = 1
int w
int h
w = 6 ; 6 bits wide
h = 2 ; 2 lines
Qfile q1[w, h]
q1[0] = 0 ; Set all values in first line to zero
q1[5,0] = 1 ; except low order bit
q1[0,1] = q1[1,1] = q1[5,1] = 0
q1[2,1] = q1[4,1] = 1
#output "frame_" + f ; Display the current (initial state)
f = f + 1
for x in range(1, w):
q1[x-1,0] = state(carry_add,q1[x,1],q1[x,0])
q1[x,1] = state(add,q1[x,1],q1[x,0])
link(q1[x,1],q1[x-1,0])
#output "frame_" + f ; display the relationships after the add
Yeah, I think I'll build this on top of Python...
Dexter
1 week ago
4 comments:
Shouldn't the #output at the end be inside the for loop, so we see the action take place?
I've gotta noodle over your proposal to represent state by one or more of a vector, color, and light direction.
Part of the problem is that the total quantum state of the computer is 2^n dimensional for an n-qubit quantum register. You can represent the state of a single qubit as a unit vector, but you can't represent two qubits as two unit vectors. You can represent two qubits (or more) as a set of points around a circle on the unit sphere; this is called the Majorana representation.
What I'm representing in my animations is the physical layout of the qubits (more precisely, the qubit carriers, such as ions), which qubits are being acted on (by the rotating arrows and the golden arches that fly by), and how long it has been since a qubit was acted on (color, fading from red to blue).
There are any number of things about the quantum computer you might want to represent; we should figure out which ones are most important - or, better yet, how to make multiple animations from a single circuit that show different characteristics. Those animations then might be separate files, or might be shown in quadrants of the screen.
As the number of qubits scales up, resolution becomes a problem. My spheres are already too small when the computation gets large.
One characteristic of the quantum state that I think is useful (or maybe just cool) to represent is which qubits are entangled. I was thinking of doing this by texture-mapping them all with the same stripe pattern, or possibly changing the shape from sphere to cube, or maybe connecting entangled qubits with a coiled spring, or somesuch. The problem is that entanglement is not immediately obvious from the circuit description; you have to actually calculate some things using the unitary transforms to figure it out. (Entanglement is also a continuous variable, not a Boolean, but for most of my purposes Boolean would be adequate.)
Decoherence could also use a good visual representation; maybe a qubit goes up in flames when it accidentally gets measured?
The scalable ion trap architecture is one of the hottest things going, and there are many groups working on it: Dave Wineland's at NIST, Ike Chuang's at MIT, Fred Chong's at UC Davis, Chris Monroe's at Michigan, and Jungsang Kim's at Duke, to name just a few. Several of them have done rendered images and even animations of the physical state, showing the ions in motion through the trap and the laser beams firing at them and whatnot. I'll see if I can dig up some pointers.
btw, rendering time per se has never been my problem. Ray tracing might be overkill, but I don't care. My problems have been combining individual frames into animations of an acceptable file size, and having decent tools to display those animations either directly, or in OpenOffice or on a web page. The ImageMagick tools are great, but begin to barf at moderate-length animations, and OpenOffice chugs insanely while trying to display a large animated GIF.
I read over your blog, and i found it inquisitive, you may find My Blog interesting. My blog is just about my day to day life, as a park ranger. So please Click Here To Read My Blog
Post a Comment