@metasoarous not yet. but the overhead compared to neanderthal is one protocol dispatch, so neanderthal benchmarks should apply: https://neanderthal.uncomplicate.org/articles/benchmarks.html

i do a hack in a special case of the QR decomposition, that i am not sure about yet. other than that the porting was straightforward. the core.matrix APIs do not respect the low-level BLAS representations though. they e.g. always unpack the matrices for QR or LU decompositions. so neanderthal is very recommendable if you care about performance.

ideally you can do so in parts of your algorithm by specializing on neanderthal and using the core.matrix API for the rest

that is my take on it atm.

neanderthal is also closer to standard literature on numerical algorithms, but i am not too familiar with that literature yet

i mostly care about autograd atm.

@bpiel have you thought about a core.matrix backend for tensorflow?

i need pytorch like autograd for dynamic compute graphs, tensorflow is moving there, i think

i want to implement this https://openreview.net/forum?id=BJ8c3f-0b

(in anglican)

the problem is that the traces can have different length and are steered from clojure's control flow

@whilo I only have a minute, but yes, I have and it seems like a good idea.

i also think so 🙂

great, we can chat later

ping me when you have time