From: Andrew F. <aw...@ro...> - 2004-03-17 12:10:25
|
A student wrote the following code: vnl_vector<double> x(1.0,2.0,3.0); It was hard to debug. The following constructor exists on vnl_vector. I do not see its value. //: Creates a vector of length 2 and initializes with the arguments, px,py. // Requires that len==2. // Consider using vnl_vector_fixed<T,2> instead! vnl_vector (unsigned len, T const& px, T const& py); Andrew Fitzgibbon, Royal Society University Research Fellow Robotics Research Group, Tel: +44 7712 579332 Dept of Engineering Science, Oxford Univ FAX: +44 1865 280922 Ewert House, Summertown, Oxford www.robots.ox.ac.uk/~awf |
From: Peter V. <Pet...@es...> - 2004-03-17 13:00:30
|
> //: Creates a vector of length 2 and initializes with the arguments, > px,py. > // Requires that len==2. > // Consider using vnl_vector_fixed<T,2> instead! > vnl_vector (unsigned len, T const& px, T const& py); This constructor should at least be marked as "deprecated" (with appropriate notification message). Its use has been superceeded by vnl_vector_fixed<T,2> (as the comment indicates). -- Peter. |
From: <kar...@ya...> - 2004-03-17 16:33:43
|
I also wasted several hours finding the bugs caused by this inane constructor (comipiling old code from when the constructor with 3 parameters did the logical thing and made a vector of length 3). If this constructor at least actually checked that the first parameter was equal to 2 then most wrong uses would be picked up. Of course quite why you would want a parameter that can only take one possible value is another question.... --- Andrew Fitzgibbon <aw...@ro...> wrote: > > A student wrote the following code: > > vnl_vector<double> x(1.0,2.0,3.0); > > It was hard to debug. The following constructor exists > on vnl_vector. I do not see its value. > > //: Creates a vector of length 2 and initializes with the arguments, > px,py. > // Requires that len==2. > // Consider using vnl_vector_fixed<T,2> instead! > vnl_vector (unsigned len, T const& px, T const& py); > > > > Andrew Fitzgibbon, Royal Society University Research Fellow > Robotics Research Group, Tel: +44 7712 579332 > Dept of Engineering Science, Oxford Univ FAX: +44 1865 280922 > Ewert House, Summertown, Oxford www.robots.ox.ac.uk/~awf > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html |
From: Peter V. <Pet...@es...> - 2004-03-17 16:47:13
|
> If this constructor at least actually checked that the first parameter > was equal to 2 then most wrong uses would be picked up. It does! That is to say, the first statement of the constructor is assert(length==2); So only when asserts are not active, this is passing unnoticed ... -- Peter. |
From: Amitha P. <pe...@cs...> - 2004-03-17 20:19:11
|
On Wed 17 Mar 2004, Andrew Fitzgibbon wrote: > > A student wrote the following code: > > vnl_vector<double> x(1.0,2.0,3.0); > > It was hard to debug. What compiler are you using that didn't warn about a double->unsigned conversion? > The following constructor exists > on vnl_vector. I do not see its value. > > //: Creates a vector of length 2 and initializes with the arguments, > px,py. > // Requires that len==2. > // Consider using vnl_vector_fixed<T,2> instead! > vnl_vector (unsigned len, T const& px, T const& py); I think it should be removed. However, removing this should also imply removing the similar 4, 5 and 6 argument versions. This would then mean that a vnl_vector can only be initialized via an array or by getting individual elements. Note that vnl_vector_fixed doesn't help here. Only the classes vnl_double_* allow easy initialization of vectors. Also note that removing the first length argument is not an option because that would create a conflict with //: Creates vector of len elements, all set to v0 vnl_vector(unsigned len, T const& v0); when T==unsigned. Amitha. |
From: Ian S. <ian...@st...> - 2004-03-17 20:53:16
|
It appears to me that users want a simple way of initialising a vnl_vector, so here is a suggestions that would allow us to get rid of all the existing arbitrary initialisers. I'm sure I've seen some code somewhere that allows something like vnl_vector<double> v( init()|1.0|2.0|3.0, 3); I guess that vbl_init would look like class init { vcl_vector<double> d; public: operator const double *(){ return &d.front();} initialiser & operator | (double v) { d.push_back(v); return *this; } }; Verfication, templatisation, documentation, testing, etc is left as an exercise for the reader, as is the deprecation of some the initialisers currently in vnl_vector. I suspect that the Loki library may have something similar which gets optimised away to something as efficient as vnl_vector(1.0, 2.0, 3.0); Ian. > -----Original Message----- > From: vxl...@li... > [mailto:vxl...@li...]On Behalf > Of Amitha > Perera > Sent: Wednesday, March 17, 2004 8:19 PM > To: Andrew Fitzgibbon > Cc: 'Vxl-maintainers (E-mail)' > Subject: Re: [Vxl-maintainers] new vnl_vector constructor > > > On Wed 17 Mar 2004, Andrew Fitzgibbon wrote: > > > > A student wrote the following code: > > > > vnl_vector<double> x(1.0,2.0,3.0); > > > > It was hard to debug. > > What compiler are you using that didn't warn about a double->unsigned > conversion? > > > The following constructor exists > > on vnl_vector. I do not see its value. > > > > //: Creates a vector of length 2 and initializes with the > arguments, > > px,py. > > // Requires that len==2. > > // Consider using vnl_vector_fixed<T,2> instead! > > vnl_vector (unsigned len, T const& px, T const& py); > > I think it should be removed. However, removing this should also imply > removing the similar 4, 5 and 6 argument versions. This would then > mean that a vnl_vector can only be initialized via an array or by > getting individual elements. Note that vnl_vector_fixed doesn't help > here. Only the classes vnl_double_* allow easy initialization of > vectors. > > Also note that removing the first length argument is not an option > because that would create a conflict with > > //: Creates vector of len elements, all set to v0 > vnl_vector(unsigned len, T const& v0); > > when T==unsigned. > > Amitha. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Peter V. <Pet...@es...> - 2004-03-18 11:51:18
|
> vnl_vector<double> v( init()|1.0|2.0|3.0, 3); Actually, it's even simpler than this: vnl_vector<double> v = vnl_vector_fixed<double,3>(1.0,2.0,3.0).as_vector(); -- Peter. |
From: Andrew F. <aw...@ro...> - 2004-03-18 14:54:02
|
> It appears to me that users want a simple way of initialising > a vnl_vector, > so here is a suggestions that would allow us to get rid of > all the existing > arbitrary initialisers. > > I'm sure I've seen some code somewhere that allows something like > > vnl_vector<double> v( init()|1.0|2.0|3.0, 3); > I'm inclined to say eek. What about vnl_vector<double>().init(1,2,3); ? |
From: Amitha P. <pe...@cs...> - 2004-03-20 15:24:51
|
On Thu 18 Mar 2004, Peter Vanroose wrote: > [...] vnl_vector_fixed<double,3>(1.0,2.0,3.0) [...] I dislike this interface, because vnl_vector_fixed<double,2> x(1.0, 2.0, 3.0); will compile, and will only fail at run-time IF debugging is on (i.e. asserts are enabled). This is bad. The better alternative is to use vnl_double_2 x(1.0,2.0); // will compile vnl_double_2 x(1.0,2.0,3.0); // will not compile I would advocate removing the former in favour of the latter. Amitha. |
From: Peter V. <Pet...@es...> - 2004-03-20 15:45:19
|
> vnl_vector_fixed<double,2> x(1.0, 2.0, 3.0); > will compile, and will only fail at run-time IF debugging is on > (i.e. asserts are enabled). This is bad. The better alternative is > to use > vnl_double_2 x(1.0,2.0); // will compile > vnl_double_2 x(1.0,2.0,3.0); // will not compile > > I would advocate removing the former in favour of the latter. Agreed. -- Peter. |
From: Miguel A Figueroa-V. <mi...@eg...> - 2004-03-20 16:54:19
|
wouldn't you be able to keep the templates for the double part? vnl_vector_fixed2<double> x(1.0, 2.0); --Miguel On Sat, 20 Mar 2004, Peter Vanroose wrote: > > vnl_vector_fixed<double,2> x(1.0, 2.0, 3.0); > > will compile, and will only fail at run-time IF debugging is on > > (i.e. asserts are enabled). This is bad. The better alternative is > > to use > > vnl_double_2 x(1.0,2.0); // will compile > > vnl_double_2 x(1.0,2.0,3.0); // will not compile > > > > I would advocate removing the former in favour of the latter. > > Agreed. > > > -- Peter. |
From: Andrew F. <aw...@ro...> - 2004-03-18 14:52:04
|
> What compiler are you using that didn't warn about a double->unsigned > conversion? Actually, he had used (1,1,0) as the initializer list. It wasn't *that* hard to debug, but it could have been. And for the student it could have been hideous. > I think it should be removed. However, removing this should also imply > removing the similar 4, 5 and 6 argument versions. This would then > mean that a vnl_vector can only be initialized via an array or by > getting individual elements. Note that vnl_vector_fixed doesn't help > here. Only the classes vnl_double_* allow easy initialization of > vectors. I agree -- all of them should go. I'm beginning to dislike constructors in general now anyway, because they don't have nice readable names. i.e I prefer vgg_canny canny; canny.set_sigma(1.0); canny.set_jump_threshold(2); canny.set_non_max_suppression(true); to vgg_canny canny(1.0,2,true); |
From: Amitha P. <pe...@cs...> - 2004-03-20 15:19:08
|
On Thu 18 Mar 2004, Andrew Fitzgibbon wrote: > I agree -- all of them should go. I'm beginning to dislike constructors > in general now anyway, because they don't have nice readable names. i.e > I prefer > > vgg_canny canny; > canny.set_sigma(1.0); > canny.set_jump_threshold(2); > canny.set_non_max_suppression(true); > > to > > vgg_canny canny(1.0,2,true); We are in agreement. I think the way you outlined, or a parameter class (illustrated below) are better ways. class vgl_canny_params; vgl_canny_params p; p.set_sigma( 1.0 ); p.set_jump_threshold( 2 ); vgl_canny canny( p ); OR, to avoid unnecessary variable names, vgl_canny canny( vgl_canny_params().set_sigma( 1.0 ) .set_jump_threshold( 2 ) ); This allows the constructor to do more work, for the situation where default construction followed by (re)initialization is potentially too expensive. Amitha. |