Re: Macro help/strategy for writing a tiny DSL for circuit-model quantum computing?
My general advice would be not to start with macros. 1. Start with data - what are the entities (bits? gates?), and how do you represent them? It's ok (actually better) for these to be verbose. Plan for extension (maps are open, which is why they're so common in representing data in Clojure). 2. Create functions that manipulate that take and return that data. 3. Decide what you actually want to write to capture the domain operations - how do you represent these in "function-like" forms. 4. Write macros that translate #3 into #2 using #1. 5. Bask in the warm glow of a job well done. On Wednesday, May 15, 2019 at 1:56:30 PM UTC-5, Vic Putz wrote: > > ...which sounds a LOT more complex than it is. I don't care about > simulation--there are great Python-based packages for that. I don't even > care about verification or optimization yet; I just want to generate a data > structure that's exportable in, say, EDN that I can write a parser for in > Python. > > So... I'm dabbling in quantum computing, and the way these things work, > loosely, is that you have a fairly small address space (Google's > Bristlecone has 72 bits, and that's HUGE), and you basically apply "gates" > (atomic operations) to one, two, or occasionally three bits at a time. > That's basically it--you can have larger operations, but at the end of they > day they get broken down into 1/2/3-qubit gates. > > Right now the available kits use python to create these, and it just feels > clunky... not even like writing assembler, but like writing Python code to > write assembler, and there's no separation of data structure from execution > environment. I figure at the end of the day you're just making lists of > operations; if only there was a language suited for list processing! :) > > Example: here's Python code for a "bell pair" (when measured, both bits > are either 0 or 1), from ProjectQ, one of the Python libraries: > > # The H operator is defined as an object elsewhere > # because ProjectQ mixes the construction of the quantum > # code with its execution: > # create a main compiler engine > eng = MainEngine() > > # allocate one qubit > b1 = eng.allocate_qubit() > b2 = eng.allocate_qubit() > > # put it in superposition > H | b1 > CNOT | (b1, b2) > > # measure > Measure | q1 > Measure | q2 > > eng.flush() > # print the result: > print("Measured: {}{}".format(int(q1),int(q2))) > > > What I'd like to see is something more like > > ;; declare H to be a 1-bit gate and CNOT to be a 2-bit gate > ;; note these don't have to DO anything here as long as they can > ;; be interpreted in the Python backends > (defgate H 1) > (defgate CNOT 2) > > (defq-fn bell-pair [b1 b2] > (H b1) > (CNOT b1 b2)) > > (defq-pgm run-bell-pair [] > (let [b1 (allocate-bit 1) ;; variable of one qubit > b2 (allocate-bit 1)] ;; same > (bell-pair b1 b2) > (measure b1 b2)) > > ...where gates behave like functions (so you can use partial, map, etc, > like (map (partial CNOT 1) [b1 b2 b3]) > > And doing say (bell-pair 1 2) would spit out EDN > > ((:H 1) > (:CNOT 1 2)) > > and (run-bell-pair) might parse everything, include extra data about the > necessary machine, and reassign variables to allocated bits > > {:machine {:bitsize 2} ; calculated because only two bits were allocated > in all the subsidiary code > :code ((:block {:name bell-pair > :code (:H 0) (:CNOT 0 1) (:measure 0 1)}))} > > That sort of thing (the ":block" idea is mostly to delineate "where you > are" in the output program, and to group operations for display). Then I > could write a parser in Python for the simulators and such (or rewrite the > Clojure code for Hylang, which is its own exercise, but I could use the > Python libs directly then). There are other things I'd like (allocate > multi-bit variables, and apply gates to individual bits of those, like to > have the idea of reusing bits once they're measured and done with, that > sort of thing) but this is a start. > > On the surface, this looks really easy--you're just generating and > traversing data structures--but it's funny how hard I'm finding it because > it's key that you can execute proper computational code within (to do > things like determine angles for parameterized gates, apply gates in > complex ways to sequences, etc). > > I created a defgate macro that generated function stubs for gates that > created EDN for gates; that was easy. But properly doing the "defq-fn" > macro is eluding me. I want it to return a list of the gates' data > structures, but if I just eval the given form, I'll only get the last > result and (do...) to get a sequence is tricky because we're mixing gates > and clojure code. I tried a solution where the generated "gate" functions > would call an "emit" function which appended to a module-level variable, > and that srta worked, but it's not elegant (and not threadsafe). > > Ideally the defq-fn macro would create a function
Macro help/strategy for writing a tiny DSL for circuit-model quantum computing?
...which sounds a LOT more complex than it is. I don't care about simulation--there are great Python-based packages for that. I don't even care about verification or optimization yet; I just want to generate a data structure that's exportable in, say, EDN that I can write a parser for in Python. So... I'm dabbling in quantum computing, and the way these things work, loosely, is that you have a fairly small address space (Google's Bristlecone has 72 bits, and that's HUGE), and you basically apply "gates" (atomic operations) to one, two, or occasionally three bits at a time. That's basically it--you can have larger operations, but at the end of they day they get broken down into 1/2/3-qubit gates. Right now the available kits use python to create these, and it just feels clunky... not even like writing assembler, but like writing Python code to write assembler, and there's no separation of data structure from execution environment. I figure at the end of the day you're just making lists of operations; if only there was a language suited for list processing! :) Example: here's Python code for a "bell pair" (when measured, both bits are either 0 or 1), from ProjectQ, one of the Python libraries: # The H operator is defined as an object elsewhere # because ProjectQ mixes the construction of the quantum # code with its execution: # create a main compiler engine eng = MainEngine() # allocate one qubit b1 = eng.allocate_qubit() b2 = eng.allocate_qubit() # put it in superposition H | b1 CNOT | (b1, b2) # measure Measure | q1 Measure | q2 eng.flush() # print the result: print("Measured: {}{}".format(int(q1),int(q2))) What I'd like to see is something more like ;; declare H to be a 1-bit gate and CNOT to be a 2-bit gate ;; note these don't have to DO anything here as long as they can ;; be interpreted in the Python backends (defgate H 1) (defgate CNOT 2) (defq-fn bell-pair [b1 b2] (H b1) (CNOT b1 b2)) (defq-pgm run-bell-pair [] (let [b1 (allocate-bit 1) ;; variable of one qubit b2 (allocate-bit 1)] ;; same (bell-pair b1 b2) (measure b1 b2)) ...where gates behave like functions (so you can use partial, map, etc, like (map (partial CNOT 1) [b1 b2 b3]) And doing say (bell-pair 1 2) would spit out EDN ((:H 1) (:CNOT 1 2)) and (run-bell-pair) might parse everything, include extra data about the necessary machine, and reassign variables to allocated bits {:machine {:bitsize 2} ; calculated because only two bits were allocated in all the subsidiary code :code ((:block {:name bell-pair :code (:H 0) (:CNOT 0 1) (:measure 0 1)}))} That sort of thing (the ":block" idea is mostly to delineate "where you are" in the output program, and to group operations for display). Then I could write a parser in Python for the simulators and such (or rewrite the Clojure code for Hylang, which is its own exercise, but I could use the Python libs directly then). There are other things I'd like (allocate multi-bit variables, and apply gates to individual bits of those, like to have the idea of reusing bits once they're measured and done with, that sort of thing) but this is a start. On the surface, this looks really easy--you're just generating and traversing data structures--but it's funny how hard I'm finding it because it's key that you can execute proper computational code within (to do things like determine angles for parameterized gates, apply gates in complex ways to sequences, etc). I created a defgate macro that generated function stubs for gates that created EDN for gates; that was easy. But properly doing the "defq-fn" macro is eluding me. I want it to return a list of the gates' data structures, but if I just eval the given form, I'll only get the last result and (do...) to get a sequence is tricky because we're mixing gates and clojure code. I tried a solution where the generated "gate" functions would call an "emit" function which appended to a module-level variable, and that srta worked, but it's not elegant (and not threadsafe). Ideally the defq-fn macro would create a function that returns a sequence of gates, one for every "gate function" executed in the execution of the function, but no other output (I may be making a specious distinction between defq-fn and defq-pgm, since I'd like to be able to allocate and "free" bits within qfns). Aaaanyway, long story. But what's the best/correct approach here? I'm new to macros, but game to flail wildly. Ideally any solution would be sorta-portable to Hylang (I'm doing the same exercise there and running into even stranger problems as for example "map" just returns a "map object" rather than simply being lazily evaluated, but I'm trying). And yeah, for "real" QC applications there's a lot missing here, but one has to start somewhere :) Vic -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this gro