On 12 March 2018 at 20:37, 9il via Digitalmars-d
> Hi All,
> The Dlang multidimensional range type, ndslice, is a struct composed a an
> iterator, lengths and possibly strides. It does not own memory and does not
> know anything about its content. ndslice is a faster and extended version of
> After some work on commercial projects based on Lubeck and ndslice I
> figure out what API and memory management is required to make Dlang super
> fast and math friendly in the same time.
> The concept is the following:
> 1. All memory is managed by a global BetterC thread safe ARC allocator.
> Optionally the allocator can be overloaded.
> 2. User can take an internal ndslice to use mir.ndslice API internally in
> 2. auto matrixB = matrixA; // increase ARC
> 3. auto matrixB = matrixA.dup; // allocates new matrix
> 4. matrix[i] returns a Vec and increase ARC, matrix[i, j] returns a content
> of the cell.
> 5. Clever `=` expression based syntax. For example:
> // performs CBLAS call of GEMM and does zero memory allocations
> C = alpha * A * B + beta * C;
> `Mat` and other types will support any numeric types, PODlike structs, plus
> special overload for `bool` based on `bitwise` .
> I have a lot of work for next months, but looking for a good opportunity to
> make Mat happen.
> For contributing or co-financing:
> Ilya Yaroshenko at
> gmail com
> Best Regards,
I'd like to understand why implement a distinct vector type, rather
than just a Nx1/1xN matrix?
That kinds sounds like a hassle to me... although there is already
precedent for it, in that a scalar is distinct from a 1x1 matrix (or a
I want to talk to you about how we interact with colours better...
since in that world, a matrix can't just be a grid of independent
storage cells. That will throw some spanners into the works, and I'd
like to think that designs will support a classy way of expressing
images as matrices of pixel data.