Project Goals for Open-Blackfire

There’s no denying, I went a little bit over the top with the closed-source, proprietary version of the Blackfire Framework under my now-defunct start-up, Black Brane Systems. For the new, open-source version, Open-Blackfire, I intend to focus the implementation on the features that will make it most useful for the Common Lisp and Quantum Computing communities, along the shortest path of development to these features.

The core modules of the Blackfire Framework boil down to:

• The Wittek Machine: quantum virtualization
• Protocol “Phi”: higher-order quantum type system
• Blackfire Quantum Assembly: Vendor-agnostic quantum computer machine language

The initial priorities for Open-Blackfire are for Protocol “Phi” and the Blackfire Quantum Assembly language for vendor-agnostic quantum computer programming. The Wittek Machine architecture, which uses a hyperlattice data-structure to represent quantum states and operations under the Quantum Logic formalism, will be a serious pain to reimplement, so I’m saving that migraine as an optimization down the road once the core functionality is exposed.

To start with, Open-Blackfire will rely heavily on CLOS and the MOP in its architecture, and use Complex-valued matrix encodings to represent Quantum States and Operations, which as the standard in the literature will be easily checked for correctness. This will be extensible to use alternate and eventually interchangeable internal encodings, which will allow streamlined Quantum Validation built into Open-Blackfire’s test suite.

The above paragraph feels distinctly hand-wavey, ignoring the complications between various interpretations of Quantum Mechanics and the impact that has on the practical aspects of Quantum Computing. I will be keeping these complications at the forefront of my mind and factoring them into the new codebase from the beginning, and my hope is that I can do it in a way this time that is clear in the codebase for those who care, and a non-issue for those who don’t.

And lastly, as a large-scale open-source project, I will need to rely on the Common Lisp and Quantum Computing communities to see this project through, so if this technology will be of use to you and you are able to help make it a reality, please consider sponsoring me on GitHub Sponsors:

• https://github.com/sponsors/thephoeron/

Announcing Open-Blackfire and Open-Quicksilver

With the death of my start-up, I’ll be switching my focus back to open-source software and open-science, starting with developing new, open-source versions of the Blackfire framework and Quicksilver Quantum Lisp programming language. I will also be resuming work on Learn Lisp The Hard Way and Learn Quantum The Hard Way.

You can follow these projects at:

• https://github.com/thephoeron/open-blackfire
• https://github.com/thephoeron/open-quicksilver
• https://github.com/thephoeron/LLTHW
• https://github.com/thephoeron/LQTHW

My goal is to work full-time on open-source software, open-science, and educational material for Common Lisp and Quantum Programming, but I can’t do it without your support. Please consider sponsoring development of Open-Blackfire, Open-Quicksilver, LLTHW, and LQTHW through my GitHub Sponsors profile:

• https://github.com/sponsors/thephoeron/

Quantum Computing and Lisp

Quantum Computing is a fascinating field, but currently a contentious one. The only examples we have of real-world, hardware quantum computers are the line of adiabatic quantum computers from D-Wave Systems—and many voices in the scientific community still protest its identification as such simply because it is not a full-fledged gate-model quantum computer complete with persistent quantum data storage and QRAM. However, by the strictest definition, any machine which exploits quantum mechanical phenomena for the purpose of computation is a quantum computer, and the D-Wave One and Two meet this definition.

For us in the Lisp community, Quantum Computing is even more important; one of the most surprising secrets of the D-Wave line of adiabatic quantum computers is that their low-level operating system is programmed in Common Lisp. Specifically, D-Wave uses SBCL. This choice is not accidental or arbitrary—Common Lisp is uniquely suited to the task of quantum computer programming.

Oculus Rift: first impressions

My Oculus Rift developer kit arrived today, and needless to say, I dived right in to my complimentary 4-month Unity Pro trial, and a handful of assets I’ve been eyeing for a while (namely UFPS). But I may have overdone it a little. Already suffering from a major case of VORTAN.

VR “motion” sickness aside, it was a lot of fun. The Rift came in a slick black carrying case with all the extras, setup was a breeze, the included World demo from the SDK and extra Tuscany demo download both worked flawlessly and helped a lot with configuration. Interestingly, the included World demo also served as a useful case study for my previous post on (fluxus) and the oculus rift; in the world demo, hit your spacebar and you get a sweet floating popup that lists a few important settings. Hit spacebar again and you get more detail. Hit it a third time and you get a helpful list of keyboard shortcuts for adjusting the settings. The floating dialog, appearing more like a wetware HUD for augmented reality than a help screen for virtual reality, followed along with the head tracking; the text was crisp and clear, even without the distortion filter that normalizes the stereoscopic projection for your FOV.

New Toys: (fluxus) and Oculus Rift

I got the email on Friday from Oculus VR that my Rift Developer Kit would be shipping soon. Naturally I’m pretty excited, since I haven’t used a VR headset since some tech expo I was at back in the 90s—and the Rift is substantially more advanced. I’m also quite excited for the 4-month Unity Pro trial license that comes with the Rift (not to mention Unity Pro’s new subscription license!).

So this weekend, with the expectation of the impending arrival of said hardware, I’ve been playing around with a bunch of different things. Exploring my options, as it were, to take full advantage of the Rift hardware once it arrives. I plan to write a Common Lisp wrapper to the Oculus SDK, as that will be generally useful for Lisp game developers; but it would benefit me more directly to have a toolkit in Lisp for procedural generation of 3D graphics.

That’s when I came across (FLUXUS), a really cool livecoding environment built on Racket (a relatively new flavour of LISP/Scheme). It doesn’t have support for the Oculus Rift, and I imagine it would be slightly difficult to type with a VR headset on, but at least it’s a step in the right direction. But that’s no matter, because (fluxus) is exactly the tool I was looking for, for my live music performances.

Hacking D-Wave One in Common Lisp: Introducing SILVER-SWORD

I’m pleased to announce that BURGLED-BATTERIES has not failed me (despite being far from finished), and I have been making steady progress with my Common Lisp interface to D-Wave’s Python Pack and Adiabatic Quantum Computer Simulator: SILVER-SWORD. It is now available in alpha as a Quicklisp-installable ASDF package on GitHub: https://github.com/thephoeron/silver-sword

Features left to implement: reading and writing of qubo files, ising to qubo to ising converter functions, chimera graph indexing, and the BlackBox Solver.

Of course, you still need D-Wave’s Python Pack first, so unless you’re already a registered D-Wave developer, SILVER-SWORD won’t be much use to you. You will also need a few other dependencies, which are all conveniently listed in the repo’s README file.

That being said, I have already included a few tutorials, so you can at least see Common Lisp quantum energy programming in action.

The Quipper Quantum Programming Language

I finally got a chance today to play with Peter Selinger’s new quantum programming language, Quipper. Since it was built as an embedded, scalable functional programming language on Haskell, it was quite easy to get up and running; and naturally, with exponential overhead, you are able to simulate an actual quantum computer.

Note: Selinger’s quantum computer simulator within Quipper is designed after an ideal, gate-model quantum computer, which is a substantially different beast from D-Wave’s adiabatic quantum computer. For example, some members of the quantum computing community argue that D-Wave’s line of cryogenically-cooled superconducting chimera-graph flux-qubit processors aren’t ‘true’ quantum computers, primarily because they don’t follow the gate-model, and instead implement their own concept of energy programming to gain most-efficient-solution. The fact is, both are ‘true’ quantum computers, in the sense that they exploit quantum mechanics for computation—and when it comes down to it, flux-qubits are damn cool. In the early days of classical computing, there were a number of competing models of computation as well—but it was eventually discovered that all models that were Turing-complete were effectively equal, so as the most expedient option, the von Neumann model won-out. The question of what counts as a true quantum computer is less simple, of course—but suffice it to say that adiabatic and gate-model quantum computers serve different purposes.

With those differences in mind, we can continue.

You can get Quipper yourself from here: http://www.mathstat.dal.ca/~selinger/quipper/

Familiarity with Haskell, functional programming, and a working installation of The Haskell Platform will get you most of the way. There are a few additional dependencies to install, but everything you need to know is covered in the INSTALLING and README files listed on the language page. Once you’ve got everything set up, the Quipper scripts folder added to your PATH, and all the examples built, continue here.

Hacking D-Wave One in Common Lisp

Mostly for my own amusement, I’ve tried a variety of approaches to hacking D-Wave’s python pack in Common Lisp, from existing Python/Lisp bridges to Python-in-Lisp implementations to decompiling the binary in order to recreate C++ header files that could then be used as a basis for a direct CFFI bridge, without much success. Being that the D-Wave Developer Portal only ever offered a simulator of the company’s D-Wave One hardware for the Python language, and no C/C++ library with associated header files, this was a fairly significant problem as support for Python–Lisp bridges has always been extremely limited, and until very recently, such bridges did not support CPython libraries such as D-Wave’s Python Pack, or its dependencies such as Numpy. Enter burgled-batteries.

With the burgled-batteries library, I was hacking away at D-Wave’s Python Pack within the SBCL REPL in a matter of minutes. And according to the library’s author, it’s only the beginning. Support for Python introspection and calling Lisp from Python are in the works—but in the mean time, handy macros such as RUN and DEFPYFUN allow you to get at all aspects of a Python library in a manner familiar to those used to working with the CLPython or CFFI Common Lisp libraries.

Using burgled-batteries in its present state, it will now be a fairly straightforward task to recreate the Python Pack’s API in Common Lisp. Sadly, registration to D-Wave’s developer portal has been closed for some time (and very few developers registered for it in the first place), so the only person that will get to enjoy hacking away at a quantum computer in Common Lisp (as far as I know) is me.

That being said, I look forward to the continued development of burgled-batteries, and think it will become an invaluable tool for Lisp and Python hackers everywhere. Just think of all the libraries and frameworks we’ll get to add to Lisp!

D-Wave Python Pack 1.4.0-alpha1 Trial 2

I decided to take a break from this long weekend’s coding bender to get back to the D-Wave developer tutorials. Taking a break from one coding project by working on another may seem counter-intuitive to non-programmers, but it’s actually a great way of getting a fresh perspective when one function starts blurring into another.

I decided to take a look at some of the new tutorials, namely Travelling Salesman and the Hadamard Matrix search. I’m pleased to report that they function exactly as advertised (despite some criticism from a certain user on the D-Wave forums).

Emotiv’s Latest EPOC Developer Announcement

Yesterday, less than 24 hours after installing Windows on my MacBook Pro, the folks at Emotiv announced on their Facebook page that they had released the Mac developer kit for their EPOC neuro-headset. While Emotiv’s lack of a Mac version to their SDK was not my main reason, and immediate need, for wasting nearly $300 on Windows 7, it was a major contributing factor—combined with D-Wave’s promise to release the Mac version of their Python pack as soon as this May, it almost seems like an insult.

On the plus side, now that the EPOC supports both Windows and OS X, and soon so will the D-Wave developer beta, I suppose I should be happy that I can support both platforms in my own projects. And, let’s not forget, I also have access to Epic Game’s Unreal Development Kit now too, as well as Unity. As time passes, I’m sure I’ll find other ways to make good use of having Windows again.