Hi Johann,
I will send the fixed_vector/fixed_array implementation later today or tomorrow, just want to clean up the code a bit.

Some notes on your comments:

> Also, in you discussion on the mailing list you refer to a resize()
> function. Why have that at all? If you want to resize() I would think
> you have to destroy the object and create a new one for a fixed sized
> object like a vector

fixed_vector inherits from ublas::vector, that has a resize function. This is used only when there is the need for a resize (which there is probably not with the change in traits I posted before). So resize in my implementation is mostly a non-function and as assertion mechanism in debug builds. I believe it will not affect performance in release builds.
On the other hand there is a problem without "general" bound checking. Consider the following code:

fixed_vector<double, 3> fv;
vector<double> v(10);
fv=v; // What happens here?

without a check the above will just write in locations beyond fv's container probably causing a segmentation fault. I am not yet sure if this should be allowed. I think Gunter has placed it well here:
http://lists.boost.org/MailArchives/ublas/2009/09/3674.php

> Also, I would like it to be as
> fast as possible in this way: There should be a way to assign and
> retrieve the elements without boundary checking

when assigning to the same type, i.e.:
fixed_vector<double, 3> fv1, fv2;
fv1=fv2;
there is no bound checking.
Also for speed I believe some metaprogramming (like in tvmet or blitz++) will be nice. Metaprogramming is easy with the fixed_vector (already have done a naive implementation).

> in the end I would like to see an interface much
> like bounded_vector<T,dim> but without it actually saving the size in
> the vector (which is known at compile time - by template parameter - so
> it doesn't need to be a member variable)

The implementation of fixed_vector class does not have a size_ member variable. The only member variable is the data[N].

Very Best
Nasos Iliopoulos

> Subject: [ublas] fixed vector
> From: jgoetz@ucla.edu
> To: nasos_i@hotmail.com
> Date: Wed, 9 Sep 2009 09:10:01 -0400
>
> Hi,
> I am interested in testing out your fixed storage/vector. I have been
> using the bounded_vector and matrix types for a physics vector type
> analysis (euclid and lorentz vectors, rotations and relativistic boosts,
> etc). I briefly looked into writing a fixed_vector (and fixed_matrix)
> that would be both fast and have the standard ublas interface, but I was
> too strapped for time to implement it.
>
> Anyways, if you have a working version of the fixed_vector, it should be
> trivial for me to test it and help in the debugging if you would like. I
> would also do some benchmark testing and profiling.
>
> Also, in you discussion on the mailing list you refer to a resize()
> function. Why have that at all? If you want to resize() I would think
> you have to destroy the object and create a new one for a fixed sized
> object like a vector. In the end I would like to see an interface much
> like bounded_vector<T,dim> but without it actually saving the size in
> the vector (which is known at compile time - by template parameter - so
> it doesn't need to be a member variable). Also, I would like it to be as
> fast as possible in this way: There should be a way to assign and
> retrieve the elements without boundary checking. Though like
> std::vector::operator[](int) and std::vector::at(int) you can have
> boundary checking with one method and provide a different method that
> has it...
>
> OK, a bit of a ramble, but I am really interested in seeing if I can
> make use of your fixed_vector. I would be willing to extend it to
> fixed_matrix if I understand your code well enough.
> Thank you,
> Johann Goetz
> UCLA Dept. Physics and Astro., CA
> Jefferson Nat'l Accl Facility, VA
> jgoetz@ucla.edu
>
>

---

With Windows Live, you can organize, edit, and share your photos. Click here.