quilc VS dtype-next

Yes, they use it for their quantum compiler, at RHL Laboratories (it was maybe initiated even at Rigetti). https://github.com/quil-lang/quilc

QUILC is probably the most interesting project. It is an open-source automatic, retargetable, optimizing compiler for Quil. It can take nearly any quantum computer architecture description and compile+optimize a Quil program for that architecture.

The QVM does all manner of quantum computer simulations. It specifically simulates a Quil program, with both classical and quantum operators. The QVM has lots of different modes of operation:

You can do this with a compiler like quilc. A program like

This is a new physical implementation of a particular mathematical operation, on a specific modality of qubit. The same mathematical operation can be computed on any other quantum computer in production today; very easily so if you use a compiler like QUILC [0].

[0] https://github.com/quil-lang/quilc

For people who maybe already have a job, just want to dip their toes in, or some other life thing that prohibits them from being employed, I’ve done pro bono mentorship sessions to interested individuals, helping them contribute to open source software around this stack, like the quantum compiler. Always happy to discuss that for serious applicants.

compiler code

Yes, simulator, compiler, paper is some of it.

Speaking about Common Lisp, the only commercial-level compiler implementation that I know of is https://github.com/rigetti/quilc by /u/stylewarning et al.

Related (?): https://github.com/cnuernber/dtype-next/blob/master/test/tec...

Tablecloth by generateme is a friendly & expressive table-processing library built on top of tech.ml.dataset & dtype-next, Chris Nuernberger's high-performance data libraries.

There is one other detail here that I found out w/r/t arrays - Clojure's aset implementation returns the previous value; it isn't a faithful wrapper of the JVM's array set value instruction. Due to this if you are using aset on primitive arrays you end up boxing every value you are setting which at least in my tests leads to a performance disadvantage when compared to a tight loop using Java. This is why I have a specialized class implementing an aset that returns void.

If this is something common and the work is numeric, I would highly recommend exploring dtype-next buffer abstraction and tensors. The tensor api supports a nice APL-like substrate for working in index space without having to have the underlying storage "be" a boxed datastructure. You also get the option of off-heap / native tensors that can be zero-copy shuttled between other runtimes.

dtype-next - Major discoverability upgrades for the tech.v3.datatype and tech.v3.datatype.functional namespaces. Similarly to tmd, Cursive and Calva users now get full intellisense help with these main namespaces. Furthermore the FFI bindings now support linting with clj-kondo.

One thing about the readme that is incorrect - [dtype-next](https://github.com/cnuernber/dtype-next)'s ffi does in fact support callbacks :-). It is used as the backend to [libpython-clj](https://github.com/clj-python/libpython-clj) where you certainly can call clojure functions from python.

There are some interesting efforts concurrent with scicloj work by Chris Nuernberger specifically dtype-next, and the earlier tech-jna stuff. It's the same stuff underlying libpython-clj and libjulia-clj. recent talk.

This is great work. One of the things that has been on my mind working through our numerics stack is how to extend the number tower to complex numbers or more generally to arbitrary algebras. This project seems to me to be sort of a type-system-in-a-box that we can use to add arbitrary typing to Clojure where necessary/ideal. Thanks for sharing.