Let's say that you have a generic representation of a dynamic matrix. Besides the data of the matrix itself, your matrix class will need to also define two integral types to store its size (number of columns and number of vectors). Now if you want to have a vector represented by the same class you would like this to be reduced into one integral that stores only the number of rows (for example). In the case of a matrix that the dimensions are known at compile time (like a fixed 3x3 matrix) you can get rid of both of those and just keep the size as  template arguments.

This will result in reducing fixed container size into storing only their data and still  need only the generic implementation of matrix operations that can then work on dynamic. fixed, or mixed containers.

The larray class I pointed in the previous post does exactly that. It supports fully dynamic n-dimensional matrices, or fixed at any combination of dimensions and still keeps it optimal.

The benefits you get from having a generic (or unified implementation) for that mater are:

1. Same code for dynamic, fixed containers, matrices and vectors. (big time reduction in code size and complexity)
2. Significant storage gains for small containers
3. Provide the compiler the opportunity to optimize along the fixed dimensions.

Do all those make sense?

Best,
Nasos


On Aug 19, 2011, at 3:23 AM, David Bellot wrote:

what do you mean by unifying matrices and vectors ? Is it using a unique representation for both of them, so a vector is a 1-row/1-column matrix ? I like the idea. Well, in fact, this is what they do in Eigen. It could simplify the architecture a lot. Then vector<> would only be a syntactic sugar over matrix<>

I don't see clearly all the advantages however, in unifying dynamic and fixed matrices/vectors ? (sorry it's due to my ignorance on this topic). Can you explain in more details please ?

Let me have a look at your code this week-end.
Thanks a lot,
David

On Thu, Aug 18, 2011 at 16:51, Nasos Iliopoulos <nasos_i@hotmail.com> wrote:
I was thinking along those lines for some time and I found that with the new standard we could unify matrices and vectors, dynamic and fixed. Here is a working implementation I had started some time ago but as usual don't have the time to complete :)   (http://sourceforge.net/p/larray/wiki/Home/) .  I also have a local version of linear algebra expressions template library using proto and this generic array but haven't pushed it to source forge yet.

Best,
Nasos




On Aug 13, 2011, at 4:31 PM, David Bellot wrote:

I think it's a good idea getting rid of old things from boost and focusing on C++11.
That's gonna be a goal in Boost.ublas too.

On Sat, Aug 13, 2011 at 17:18, Joel falcou <joel.falcou@gmail.com> wrote:
This is meant to be a serious thread and not some trollfest about w/e compilers.

I am currently fixing bugs and applying feature request in MPL and it just happens I spend more time deciphering the web of compatibility #ifdefs than doing actual code. A rough guestimate tells me that on a 100 lines MPL files, 80 of them are #ifdef for compatibility.

It could fine and dandy if those #ifdefs where not, for a majority, targeted at compiler i didnt even knew hwere standard conformant (ICC 5, really) or still in serious use (Borland whatever). Some other are more debatable (like MSVC 6 or such).

Considering such compilers are so broken that upgrading boost is out of question for these users and that C++11 and its new set of supporting compilers are around the corner, also taking into account my limited amount of sanity (IRC people can testify on this), can't we start some support clean up in this library ?

<radical>
Going further, shouldn't we start thinking at boost 2.0 which will definitevely let c++03 die its peaceful death and start, on a voluntary effort, move boost component toward C++11. I know we have a fully working Fusion for 0x only. mpl, proto and other strategic infrastructure libraries should benefit from that. Some are a trivial port like Boost.PP and all the TR1 boost library that will just either disappear or forward the C++11 version.
</radical>

Here is the status of the thingy. Letting Boost 2.0 aside, what should be the status of MPL and its sharazadian list of supported compiler ?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil


_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil