Johann,

here is the fixed_vector/array so far. Be aware that you will need to overwrite ublas' vector.hpp to get it working (there are a few changes in there). I may get to work on fixed_matrix also if you don't. If although you decide to do so start with bounded_matrix and strip it down, compare the fixed_vector class with the bounded_vector class (and fixed_array with bounded_array) to see what I striped.

All the above code was written over the latest trunk version.

Very Best
Nasos Iliopoulos


> Subject: RE: [ublas] fixed vector
> From: jgoetz@ucla.edu
> To: nasos_i@hotmail.com
> Date: Wed, 9 Sep 2009 11:49:56 -0400
>
> Hi Nasos,
> That sounds like exactly what I was looking for! I suppose the only
> thing that really needs to be fast is assignment of individual elements
> and the copy constructor as you have it. Beyond that, providing bound
> checking when dealing with other objects of variable size is reasonable.
> Thanks,
> Johann.
>
> On Wed, 2009-09-09 at 11:17 -0400, Nasos Iliopoulos wrote:
> > 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
> > >
> > >
> >
> >
> > ______________________________________________________________________
> > HotmailŪ is up to 70% faster. Now good news travels really fast. Try
> > it now.
>

---

HotmailŪ is up to 70% faster. Now good news travels really fast. Try it now.