Re: GSOC 2013

Nasos Iliopoulos <nasos_i <at> hotmail.com> writes:
>       Since mdsd:array is a generic multi-dimensional container it is
>       not bound to algebraic operations. I expect that with proper
>       aligned memory allocation and SSE aglorithms (It is easy to add a
>       custom storage container that supports that) it will be as fast as
>       MKL, GotoBLAS, Eigen or armadillo. I believe that within that

ublas is great - and I certainly prefer its functional syntax to that of Eigen - 
but direct additions to it would have only a modest effect on the state of 
scientific computing.

The lack of a standardized container for storage and inter-operability of 
vectors, matrices, and multi-arrays is the single biggest impediment to c++ 
becoming the premier scientific computing language.  So what would make a major 
contribution is something that could form the kernel of a array, matrix, multi-
array library for the STD - and serve as a point of interoperability between the 
various numerical libraries.

So, can I make an even more radical suggestion for this sort of library and 
ublas?
* Implement a multi-dimensional array library with the intention of proposing 
for C++14 or C++17 standard library.  Static number of dimensions, static or 
dynamic extents for those dimensions, lower dimensional slices, etc.
* There is no way that an expression template library for linear algebra will be 
standardized in the near future, but that doesn't mean that an interoperable 
storage format couldn't become standardized.  Let the expression template 
libraries innovate independently as long as they allow adaptation with a common 
storage better than raw pointers.
* I really like the mdsdarray approach, though I am not entirely sure that 
having both dynamic and fixed extents in the same multi_array is necessary.
* Another, of course, which could serve as the core of this is 
boost::multi_array.  In fact, I think a pared down version where some of the 
fancier features are removed and a few added (e.g., add fixed extent 
multi_arrays, replace the generic storage ordering to be a static row vs. column 
major, cut down on the fancy slicing notation, etc.)
* In general, my feeling is that this should have multi-dimensional array, 
rather than matrix or vector semantics as those should be done in an expression 
template library

What relationship could this have to ublas and the numeric bindings?
* The 1 and 2 dimensional versions or slices could be adapted as vectors and 
matrices (i.e. like fortran, matlab, numpy, etc.)
* Ublas adaptors could be written for this to work with existing ublas 
expression templates, which showcases how this sort of thing could create 
interoperability between libraries
* Bindings for the the numeric_bindings would make these immediately usable with 
lapack, etc.
* Ultimately, this class could serve as the native storage container for ublas, 
but that may not be a great idea.

You will note that a subset of this is being discussed right now on 
https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-
proposals/WODPvhOt0PM although this is missing the necessary features of fortran 
storage options and dynamic vs. static allocation.

_______________________________________________
ublas mailing list
[email protected]
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [email protected]