Hi Steve,
I'm in Google research developing a framework for ml and hpc with a focus on performance and a cleaner user experience than TensorFlow. My work will compliment our larger MLIR effort to produce a next gen compiler for parallel computing. You're probably already aware of it. My project is open source called SwiftRT on github.
I have a thought about the naming of your generic Complex type. This is purely a matter of ergonomics and not about correctness. The Real portion of your project is a set of protocols conformed to by the standard Swift real types (Float, Double). Users simply use them in their code and pick up the functionality.
SwiftRT defines several generic tensor types such as Vector, Matrix, etc..
Application models typically select one precision to use throughout, and for the real type that is usually Float. Originally the user was required to explicitly declare types everywhere as Vector<Float>, Matrix<Float>. The element type never changes, is redundant, and makes the code look verbose. I then tried changing my generic tensor type names to VectorT<Element>, MatrixT<Element>, then declaring default type aliases likes typealias Vector = VectorT<Float>. It makes the user code easier to type and a lot less cluttered looking. The users can pick up these default definitions, or in their own module redefine them such as
typealias Vector = VectorT<Double>
So what I would like you to think about is possibly doing the same sort of thing with the Complex generic type. Perhaps calling it ComplexT and then doing a default like typealias Complex = ComplexT<Float>. This would make user code cleaner and less verbose, and of course the user can redefine these any time if it makes sense for their application. Then users can simply type Complex with the implied element type. As it stands, it isn't possible to do this kind of simplified typealias because there will be a naming collision with your generic type. What do you think? So far, internal users here have really liked the SwiftRT simplified tensor type syntax.
On a separate note, I'm curious, what company do you work for?
Thanks, Ed