From: Paul S. <pau...@vi...> - 2002-02-14 18:10:42
|
Here's a go... Arguably there are a few basic properties of vectors 1) a T* (data) pointing to the first element 2) a size(), indicating the number of elements, which may be dynamic or static, depending on whether the size is known at compile time 3) some storage, which may be dynamic or static I reckon that something like this might be appropriate: vector_ref (has T* data, size() member fn - this would need to be virtual or have a size_ member variable. No resize() member fn) | \ | ------------------------------------ vector_fixed_ref | (has T* data, static size - an enum?) vector_dynamic | (has dynamic storage, resize() member) | vector_fixed (has C-array storage plus above) Operators might be: vector_dynamic operator+(const vector_ref&, const vector_ref&); vector_fixed operator+(const vector_fixed_ref&, const vector_fixed_ref&); (Obviously you cannot return an object by value that doesn't own its own memory). Hope this isn't complete rubbish. Paul. -----Original Message----- From: William A. Hoffman [mailto:bil...@ki...] Sent: Thursday, February 14, 2002 4:33 PM To: vxl...@li... Subject: [Vxl-maintainers] VNL speed of C?? I know I brought this up several years ago, but I was wondering if anyone has thought about this problem. The vnl vector hierarchy is upside down. vnl_vector should inherit from vnl_vector_fixed. The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all the operators +, * , etc call new even on the fixed versions of things. This has caused several projects to give up on using the vnl_vector classes and use hand coded arrays. -Bill _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. |
From: William A. H. <bil...@ki...> - 2002-02-14 19:00:45
|
I would argue that it should be done more generically, and more like stl. A vector would only need to have the interface: T& operator[](int) T& get(int); int size(); It would not have a T* as that adds an extra 4 bytes to the fixed version that it does not need. Also a virtual function adds to the size of the object. Also, some of the operators might be better implemented with functions: vnl_mult_vec(v1, v2, vresult); That way people could use these functions in inner loops without constructors being called. Right now "new" is called for most vector and matrix operations which can be very inefficient. -Bill At 06:06 PM 2/14/2002 +0000, Paul Smyth wrote: >Here's a go... > >Arguably there are a few basic properties of vectors >1) a T* (data) pointing to the first element >2) a size(), indicating the number of elements, which may be dynamic or >static, depending on whether the size is known at compile time >3) some storage, which may be dynamic or static > >I reckon that something like this might be appropriate: > > vector_ref >(has T* data, size() member fn - this would need to be virtual or have a >size_ member variable. >No resize() member fn) > > | \ > | ------------------------------------ > vector_fixed_ref | >(has T* data, static size - an enum?) vector_dynamic > | (has dynamic storage, resize() >member) > | > vector_fixed >(has C-array storage plus above) > >Operators might be: >vector_dynamic operator+(const vector_ref&, const vector_ref&); >vector_fixed operator+(const vector_fixed_ref&, const vector_fixed_ref&); >(Obviously you cannot return an object by value that doesn't own its own >memory). > >Hope this isn't complete rubbish. >Paul. > >-----Original Message----- >From: William A. Hoffman [mailto:bil...@ki...] >Sent: Thursday, February 14, 2002 4:33 PM >To: vxl...@li... >Subject: [Vxl-maintainers] VNL speed of C?? > > >I know I brought this up several years ago, but I was wondering if anyone >has thought about >this problem. The vnl vector hierarchy is upside down. vnl_vector should >inherit from vnl_vector_fixed. >The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all >the operators +, * , etc call >new even on the fixed versions of things. This has caused several >projects to give up on using the vnl_vector >classes and use hand coded arrays. > >-Bill > > > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >This e-mail, and any attachment, is confidential. If you have received it in >error, please delete it from your system, do not use or disclose the >information in any way, and notify me immediately. > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Ian S. <ian...@st...> - 2002-02-15 14:39:15
|
Perhaps the list of functions for any generic numeric vector should be the list of functions that vnl_vector currently supports minus some of the constructors. Some of the other things could be removed for conciseness, however lots of algorithms that you might wish to generalise will expect to see many of the current members of vnl_vector. > -----Original Message----- > From: William A. Hoffman [mailto:bil...@ki...] > Sent: Thursday, February 14, 2002 6:56 PM > To: Paul Smyth > Cc: 'vxl...@li...' > Subject: RE: [Vxl-maintainers] VNL speed of C?? > > > I would argue that it should be done more generically, and > more like stl. > A vector would only need to have the interface: > > T& operator[](int) > T& get(int); > int size(); > > It would not have a T* as that adds an extra 4 bytes to the > fixed version > that it does not need. > Also a virtual function adds to the size of the object. > > Also, some of the operators might be better implemented with > functions: > > vnl_mult_vec(v1, v2, vresult); > > That way people could use these functions in inner loops without > constructors being called. > Right now "new" is called for most vector and matrix > operations which can > be very inefficient. > > -Bill > > > At 06:06 PM 2/14/2002 +0000, Paul Smyth wrote: > >Here's a go... > > > >Arguably there are a few basic properties of vectors > >1) a T* (data) pointing to the first element > >2) a size(), indicating the number of elements, which may be > dynamic or > >static, depending on whether the size is known at compile time > >3) some storage, which may be dynamic or static > > > >I reckon that something like this might be appropriate: > > > > vector_ref > >(has T* data, size() member fn - this would need to be > virtual or have a > >size_ member variable. > >No resize() member fn) > > > > | \ > > | ------------------------------------ > > vector_fixed_ref | > >(has T* data, static size - an enum?) vector_dynamic > > | (has dynamic > storage, resize() > >member) > > | > > vector_fixed > >(has C-array storage plus above) > > > >Operators might be: > >vector_dynamic operator+(const vector_ref&, const vector_ref&); > >vector_fixed operator+(const vector_fixed_ref&, const > vector_fixed_ref&); > >(Obviously you cannot return an object by value that doesn't > own its own > >memory). > > > >Hope this isn't complete rubbish. > >Paul. > > > >-----Original Message----- > >From: William A. Hoffman [mailto:bil...@ki...] > >Sent: Thursday, February 14, 2002 4:33 PM > >To: vxl...@li... > >Subject: [Vxl-maintainers] VNL speed of C?? > > > > > >I know I brought this up several years ago, but I was > wondering if anyone > >has thought about > >this problem. The vnl vector hierarchy is upside down. > vnl_vector should > >inherit from vnl_vector_fixed. > >The problem is that vnl_vector_fixed has 8 extra bytes of > memory. Also all > >the operators +, * , etc call > >new even on the fixed versions of things. This has caused several > >projects to give up on using the vnl_vector > >classes and use hand coded arrays. > > > >-Bill > > > > > > > > > >_______________________________________________ > >Vxl-maintainers mailing list > >Vxl...@li... > >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > >This e-mail, and any attachment, is confidential. If you > have received it in > >error, please delete it from your system, do not use or disclose the > >information in any way, and notify me immediately. > > > >_______________________________________________ > >Vxl-maintainers mailing list > >Vxl...@li... > >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Paul S. <pau...@vi...> - 2002-02-15 11:15:46
|
One question is: to what extent people writing client code use is-a relationships, plugging vector_fixeds into algorithms that take vectors, and to what extent generic algorithms would fit into the way people work. If one was going to go for generic algorithms, the matrix template library http://www.osl.iu.edu/research/mtl/, which works with vector and matrix iterators might be worth at least looking at - if only for the approach. e.g. matrix-vector multiply: template < class Matrix, class VecX, class VecY > void matvec_mult(const Matrix& A, VecX x, VecY y) { typename Matrix::const_iterator i; typename Matrix::OneD::const_iterator j; for (i = A.begin(); i != A.end(); i) for (j = (*i).begin(); j != (*i).end(); j) y[j.row()] += *j * x[j.column()]; } Paul. -----Original Message----- From: William A. Hoffman [mailto:bil...@ki...] Sent: 14 February 2002 18:56 To: Paul Smyth Cc: 'vxl...@li...' Subject: RE: [Vxl-maintainers] VNL speed of C?? I would argue that it should be done more generically, and more like stl. A vector would only need to have the interface: T& operator[](int) T& get(int); int size(); It would not have a T* as that adds an extra 4 bytes to the fixed version that it does not need. Also a virtual function adds to the size of the object. Also, some of the operators might be better implemented with functions: vnl_mult_vec(v1, v2, vresult); That way people could use these functions in inner loops without constructors being called. Right now "new" is called for most vector and matrix operations which can be very inefficient. -Bill At 06:06 PM 2/14/2002 +0000, Paul Smyth wrote: >Here's a go... > >Arguably there are a few basic properties of vectors >1) a T* (data) pointing to the first element >2) a size(), indicating the number of elements, which may be dynamic or >static, depending on whether the size is known at compile time >3) some storage, which may be dynamic or static > >I reckon that something like this might be appropriate: > > vector_ref >(has T* data, size() member fn - this would need to be virtual or have a >size_ member variable. >No resize() member fn) > > | \ > | ------------------------------------ > vector_fixed_ref | >(has T* data, static size - an enum?) vector_dynamic > | (has dynamic storage, resize() >member) > | > vector_fixed >(has C-array storage plus above) > >Operators might be: >vector_dynamic operator+(const vector_ref&, const vector_ref&); >vector_fixed operator+(const vector_fixed_ref&, const vector_fixed_ref&); >(Obviously you cannot return an object by value that doesn't own its own >memory). > >Hope this isn't complete rubbish. >Paul. > >-----Original Message----- >From: William A. Hoffman [mailto:bil...@ki...] >Sent: Thursday, February 14, 2002 4:33 PM >To: vxl...@li... >Subject: [Vxl-maintainers] VNL speed of C?? > > >I know I brought this up several years ago, but I was wondering if anyone >has thought about >this problem. The vnl vector hierarchy is upside down. vnl_vector should >inherit from vnl_vector_fixed. >The problem is that vnl_vector_fixed has 8 extra bytes of memory. Also all >the operators +, * , etc call >new even on the fixed versions of things. This has caused several >projects to give up on using the vnl_vector >classes and use hand coded arrays. > >-Bill > > > > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >This e-mail, and any attachment, is confidential. If you have received it in >error, please delete it from your system, do not use or disclose the >information in any way, and notify me immediately. > >_______________________________________________ >Vxl-maintainers mailing list >Vxl...@li... >https://lists.sourceforge.net/lists/listinfo/vxl-maintainers This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. |