Docs: Briefer Tutorial

[stellarpower]

Hi,

Nice work! Having done some stuff before with larger-than-memory matrix multiplications, this looks great. This blog was very interesting and I wonder how it would look with spans instead.

Just a suggestion, as the tutorial mentions that more will be added at some point in the future. I think the present example could be distilled a bit and have more of a sort of "just show me the code" style to start with. All good stuff, but right now I'm a bit tired and it contains more info than I probably need just to know the basic operations and become familiar with how to use it. So whenever that point comes around, personally I think some of what's there, such as layout customisation, could be moved into a "part 2", with "part 1" just being explanation of the extents type, indexing, maybe generating a subrange for a slice, static/dynamic extents, etc.

Just my view though (genuinely, no pun originally intended).

Thanks!

[mhoemmen]

@stellarpower wrote:

This blog was very interesting and I wonder how it would look with spans instead.

std::linalg has some examples of lazy computation using mdspan layouts (transposed) and accessors (scaled_accessor and conjugated_accessor). Note that computation of each element is eager. For example, scaled_accessor::access(x, k) returns alpha * x[k] and conjugated_accessor::access(x, k) returns the complex conjugate of x[k]. Both accessors' reference types are just value_type, not an expression template. What's lazy is the whole mdspan expression. For instance, transposed(A) doesn't actually move elements; it just returns an mdspan A_T such that A_T[r, c] is the same element as A[c, r]. conjugated(x) doesn't actually replace elements with their complex conjugates; it just returns an mdspan x_conj such that x_conj[r, c] is the complex conjugate of x[r, c].

Please feel welcome to contribute examples or tutorial material via pull request!

[stellarpower]

Linear algebra in the standard library. Never ceases to impress me a bit how much the language is still trying to keep up, modernise, and strive for better. But very interesting, thanks for pointing me towards it. Were it up to me for numeric computation I think it's time for a DSL that's easily loaded in with other languages that handle any application logic. Type-safe, static/dynamic size, arrays are first-class, JAOT-compiles down for GPU etc., and then just none of the extra stuff that gets in the way for a general programming language. The benefits of SciPy etc. in a standard library but no nasty python, and it won't build if it's not correct. People keep writing libraries to do numerical work within a broad language rather than writing a language just for it, as it's the other stuff that holds it back. It's easy in julia/python but the dynamic typing makes it unsafe and very slow to develop in. In C++ templates are complicated at the best of times so you have to work pretty hard and then find you can't easily unfix one dimension say. Or the library just chooses to let you segfault or perform a runtime check, neither is great. Oh well, a man can dream!

If I end up using this much more then would happily open an MR, time permitting (which realistically it never is :S).