qvm VS dtype-next

Quil's semantics are based off of an idea called the "quantum abstract machine". A piece of software which emulates the quantum abstract machine is called the Quantum Virtual Machine or QVM. It's open source and available here.

More interestingly, the QVM repository includes a program called the dqvm which is the QVM but able to be run on an MPI cluster. This doesn't use any advanced state representation (such as matrix product states) and instead just very cleverly arranges for huge wavefunctions to be distributed across a cluster of arbitrary size and worked on in parallel.

and/or in-line assembly code, and still can't optimize specific matrix shapes and structures, or do algebraic simplifications to eliminate work altogether.

The regex library FTA is a great, and clean, example of a long standing practice of compiling regexen, except it doesn't use any fancy VMs or any fancy JITs, just "when you see this regex, automatically turn it into this Common Lisp code, and let the Lisp compiler handle the rest."

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

[0b] COMPILE-OPERATOR: https://github.com/quil-lang/qvm/blob/master/src/compile-gat...

[1] https://www.gnu.org/software/libjit/

quantum computer simulator

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

You can also do this with purely free and open source software like [0].

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

I wish I could try running the DQVM, the distributed quantum simulator written in Common Lisp [0], on this thing.

[0] https://github.com/quil-lang/qvm/tree/master/dqvm

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.