Subject: [Boost-bugs] [Boost C++ Libraries] #4034: better vector/matrix assignment (or initialization)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-03-22 21:57:50
#4034: better vector/matrix assignment (or initialization)
------------------------------+---------------------------------------------
Reporter: guwi17 | Owner: guwi17
Type: Patches | Status: new
Milestone: To Be Determined | Component: uBLAS
Version: Boost 1.42.0 | Severity: Optimization
Keywords: assigment |
------------------------------+---------------------------------------------
proposal from Nasos Iliopoulos:
I suppose many of you miss the functionality of creating certain matrices
or vectors as in plain c:
double vec[] = {0.1, 2.0, 5.0. 0.3}
With the proposed classes (in the attached file) it is possible to fill
vectors and matrices like that:
{{{
vector<double> vec(3);
vec << 1.0, 2.0, 3.0;
}}}
{{{
vector_range<vector<double> > vr (a, range (1, 3));
vr << 11.0, 12.0;
}}}
{{{
matrix<double> mat(3,3);
mat << 1.0, 2.0, 3.0,
4.0, 5.0, 6.0,
7.0, 8.0, 9.0;
}}}
or even:
{{{
mat << 1.0, 2.0, 3.0,
vec,
7.0, 8.0, 9.0;
}}}
you can also use this form:
{{{
vector<double> vec(10);
vec << 1.0 , project(a, range(0,2)), 10.0, 11.0, a, 15.0, 16.0;
}}}
Another nice trick that is especially useful for sparse matrices and
vectors is:
{{{
compressed_matrix<double> cm(3,4, 3*4);
cm << non_vector(4),
1.0, 2.0, project(a,range(0,2)),
non_vector(3),2;
}}}
where the non_vector free functions returns a "non vector" object that is
used to traverse the expression without modifying it.
I would appreciate your general feedback, thoughts, critisism as well as
your opinion in the following issues:
- Are there any features beside those presented above and in the attached
example that you probably would like to see?
[[BR]]
- Where do you think this should be added? As a separate header file, or
included in vector_ and matrix_ expression headers?
[[BR]]
- I found it incovenient to implement this functionallity using iterators
(especially when the functions work on sparse types). Does anybody think
there are considerable gains if attempting that?
[[BR]]
- I also consider implementing functionality so that project(a, range(..))
<< ...; is possible, but I initially faced some problems. I think that
_range and _slice classes need to include an operator<< in order for this
to work. If somebody wants to work on that it would be great.
[[BR]]
I will write the unit tests if the maintainers consider the proposed code
for addition into uBlas.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/4034> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:02 UTC