|
|
Ublas : |
Subject: Re: [ublas] GSOC 2013
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2013-03-26 12:50:41
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.