High-level array combinators seem to ignore memory locality performance details, to me. It's all fine to say you can arbitrarily reorder array indicies in a mathematical sense, but any real program that does that needs to change a lot of things. Similarly, using variant types to index into combined arrays, splits up underlying memory locality and adds "if" branches. Type systems that obscure these details will result is poorly performing code.
That said if you're going to do it, this seems like a reasonable set of primitives to do it with. I'm not a huge performance nut, so I'd love to give it a try.
I'd like to see an implementation in a language with only fixed-stride arrays. I'm not an expert, does Rust do this?
This is great. For a long time I've had a gut feeling that there must exist a synthesis between pure functional, array, and data-oriented programming that gives you the best of all worlds:
Type safety, concise-to-the-point-of-terse code (with the types helping humans read it), and very high performance.
And this feels like a step in the right direction.
This looks pretty compelling to me. I've been itching for a math-friendly language that makes it easy to work with arrays, vectors, vector spaces, manifolds, etc., but takes advantage of static typing. (Haskell is amazing but doesn't quite make linear algebra constructs feel native.)
On first read, it looks like this is designed with a healthy balance between mathematical insight (relationship of product types and tuples, basis in lambda calculus) and real developer needs (e.g., static typic is nice; dependently typed systems can be too much; types are great, but "nameless shapes" are useful, too).
I'd love to see an implementation of this to play around with.
> naming axes gives semantic weight to array shapes, but it also introduces commitment. like in practice, array shapes mutate fast : reshape, squeeze, permute half these ops aren't semantic, they're just cleanup to fit the next layer. adding names to that doesn’t simplify, that adds bookkeeping.
> also naming means locking intent early. once you say 'this axis is time', every downstream op inherits that label, even if that dim gets folded or split.
High-level array combinators seem to ignore memory locality performance details, to me. It's all fine to say you can arbitrarily reorder array indicies in a mathematical sense, but any real program that does that needs to change a lot of things. Similarly, using variant types to index into combined arrays, splits up underlying memory locality and adds "if" branches. Type systems that obscure these details will result is poorly performing code.
That said if you're going to do it, this seems like a reasonable set of primitives to do it with. I'm not a huge performance nut, so I'd love to give it a try.
I'd like to see an implementation in a language with only fixed-stride arrays. I'm not an expert, does Rust do this?
This is great. For a long time I've had a gut feeling that there must exist a synthesis between pure functional, array, and data-oriented programming that gives you the best of all worlds:
Type safety, concise-to-the-point-of-terse code (with the types helping humans read it), and very high performance.
And this feels like a step in the right direction.
This looks pretty compelling to me. I've been itching for a math-friendly language that makes it easy to work with arrays, vectors, vector spaces, manifolds, etc., but takes advantage of static typing. (Haskell is amazing but doesn't quite make linear algebra constructs feel native.)
On first read, it looks like this is designed with a healthy balance between mathematical insight (relationship of product types and tuples, basis in lambda calculus) and real developer needs (e.g., static typic is nice; dependently typed systems can be too much; types are great, but "nameless shapes" are useful, too).
I'd love to see an implementation of this to play around with.
Can't find a repo of this lang...
Is compelling to me because I'm in the hunt for marry array + relational (https://tablam.org)
> naming axes gives semantic weight to array shapes, but it also introduces commitment. like in practice, array shapes mutate fast : reshape, squeeze, permute half these ops aren't semantic, they're just cleanup to fit the next layer. adding names to that doesn’t simplify, that adds bookkeeping.
> also naming means locking intent early. once you say 'this axis is time', every downstream op inherits that label, even if that dim gets folded or split.
it's tradeoffs only