On Tuesday, 13 March 2018 at 03:37:36 UTC, 9il wrote:
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 numpy.ndarray.
After some work on commercial projects based on Lubeck[1] 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 functions.
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`
[2].
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,
Ilya
[1] https://github.com/kaleidicassociates/lubeck
[2]
http://docs.algorithm.dlang.io/latest/mir_ndslice_topology.html#bitwise
[3]
http://www.netlib.org/lapack/explore-html/d1/d54/group__double__blas__level3_gaeda3cbd99c8fb834a60a6412878226e1.html#gaeda3cbd99c8fb834a60a6412878226e1
Well if D had:
- a good matrix type, supporting all numeric types (absolutely
crucial: including complex!)
- *very important*: with operations syntax corresponding to the
well-established standard mathematical conventions (including in
labelling the elements!)
- with superfast LU decomposition, det and similar (perhaps via
LAPACK)
- able to recognize/carry a tag for (anti)symmetric, hermitian,
... and exploit these in computations
then I'd be more seriously considering switching to D.
Your suggestion [4] that matrix[i] returns a Vec is perhaps too
inflexible. What one needs sometimes is to return a row, or a
column of a matrix, so a notation like matrix[i, ..] or
matrix[.., j] returning respectively a row or column would be
useful.
I'd be happy to help out/give advice from the viewpoint of a
scientist trying to "graduate" away from C++ without having to
sacrifice performance.
