Markus,
Please find attached some basic tests I did on the fixed types. It seems that everything works as expected :).
I did not run the ublas unittests though to see whether the changes affect other components. (I don't find any reason why it should).
I am divided between the desire to see the fixed_vector and matrix in uBlas and scalability and maintenance concerns.
1. Putting the fixed types as they are into uBlas:
Pros:
a Does not seem to change the matrix functionality
b Will give time to people to play before the next release.
c Does not constitute a major change in the container types.
Cons:
d There are maybe some things we are missing and will badly affect other uBlas components.
e We introduce an ill-conditioned design by having a resize function in a fixed container classes (I think Karl is right here, although I am not as absolute about the matter).
2. Investigating other options like sub-classing the vector_container and matrix_container classes:
Pros:
a Certainly does not affect the current state of uBlas at all.
b There is no vector_container concept in uBlas concepts, we are probably free to define it (i.e. without the resize function)
c Because the fixed type do not need an uBlas storagearray, we don't need to satisfy its requirements either (we get away with the sizing constructor).
d Its development may be a simple refinement of Markus' fixed containers implementation
Cons:
e Will probably need a redefinition of many things (like iterators for fixed types).
f We don't know whether containers are totally compatible with the rest of uBlas (they should be though, otherwise some things should change in uBlas).
g Its development may take much more time than what it looks at a first glance.
Concerning 1.e.:
We will indeed be ok with having the resize function just check for size compatibility. I would argue though to at least put a warning directive, so that we give the developers the time to update their design in case we decide to get rid of the resize. In such a case I think I would personally feel fairly comfortable going with the current Markus' design.
Concering 2d and 2g:
We will need to investigate option 2 because it may solve all the problems, especially if it doesn't require extended implementations.
Concerning 2e
Furthermore we should keep in mind that we might introduce most of the functionality of vector into vector_container (similarly for matrix), as fixed and dynamic vectors can share a lot.
If I have time I will start from Markus' design and investigate option 2. @Markus, if you are willing to start investigating it would be great as I am really busy lately.
I hope it is not only me that appears overly careful into changing those stuff, but I also feel confident that the fixed types will be (or are already) in a good shape.
Very Best,
Nasos
To: ublas@lists.boost.org
From: grabner@icg.tugraz.at
Date: Wed, 4 Aug 2010 01:37:26 +0200
Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
Nasos Iliopoulos wrote:
>
> Markus,
>> As I said in my previous message, fixed_vector was an easy exercise. >
>> However, a fixed_matrix is much more complicated since ublas::matrix
>> already > includes members "size1_" and "size2_" to define the matrix
>> size. I don't > know of any method to "get rid of" these members in a
>> derived class (such > that - again - a contiguous array of matrix
>> coefficients can be cast to an > array of fixed_matrix). Instead I
>> experimented with the following approac...
> I think I had some reasoning in the past against the appropriateness of
> using matrix_container to derive the fixed_matrix. As I am thinking it
> again I cannot find a reason anymore. Do you think the fixed_matrix (and
> maybe the fixed_vector) can be derived from those? Everything should be
> working, as uBlas is designed to work on expressions (containers are
> expressions) rather than matrices and vectors.
I don't see troubles with deriving the fixed_[vector|matrix] from [vector|
matrix]_container, but I didn't look too deep into the matrix case yet.
>> ... Instead I experimented with the following approach: ....
>> Your
>> suggestions will also work, but doing such a radical change looks
>> terrifying to me from backwards compatibility assurance perspective.
>> Doing that will probably require some serious dedication to make sure
>> things are working.
I agree with this. Fortunately I found a less radical approach :-) which
doesn't require an additional base class (matrix_base in my previous
proposal) in the class hierarchy. If the matrix template has a fourth
template parameter specifying a class which provided the matrix size, and
its default argument is a class which allows for dynamic resizing, the
matrix behaves exactly as before. The fixed_matrix (which is derived from
matrix) just has to override this default template argument to a class which
provides a static size.
A patch implementing this proposal is attached (also includes the
fixed_vector class discussed before). What do you think about it?
Kind regards,
Markus
--
Markus Grabner
Institute for Computer Graphics and Vision
Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria
WWW: http://www.icg.tugraz.at/Members/grabner
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: nasos_i@hotmail.com