From: Gehua Yang <yangg2@rp...>  20050303 23:08:23

Hi, folks. The outer_product() function in vnl_vector_fixed.h only return vnl_matrix<T>. In our current implementation, we need a function that will computer the outer product of two vnl_vector_fixed<T, n> and return a vnl_matrix_fixed<T, n, n>. Currently, I put the template into a new file called vnl_util_fixed.h. But theoretically it shall replace the outer_product() function in vnl_vector_fixed.h/txx (or it shall not). But I am afraid: 1. the include of vnl_matrix_fixed.h in vnl_vector_fixed.h is not desired. 2. the change may break code that depends on current implementation. Comments? Best Regards, Gehua Yang 
From: Amitha Perera <perera@cs...>  20050304 19:55:58

On Thu 03 Mar 2005, Gehua Yang wrote about changing outer_product API for fixed vectors: > Currently, I put the template into a new file called vnl_util_fixed.h. > But theoretically it shall replace the outer_product() function in > vnl_vector_fixed.h/txx (or it shall not). But I am afraid: > > 1. the include of vnl_matrix_fixed.h in vnl_vector_fixed.h is not > desired. You don't have to do that, though. You could make outer_product noninline, and leave the instantiation to the VNL_VECTOR_FIXED_INSTANTIATE macro. Unless you think (or, better, have tested) that a function call has a huge performance hit. Another option is to move outer_product to vnl_matrix_fixed.h. This won't affect clients, since they must be including both anyway. > 2. the change may break code that depends on current implementation. This is a bigger issue. I think your proposal is the correct thing, and we should correct our code appropriately. Probably adding .as_ref() would solve most cases. Amitha. 
From: Peter Vanroose <Peter.V<anroose@es...>  20050312 16:20:15

> Gehua Yang wrote about changing outer_product API for fixed vectors: > Currently, I put the template into a new file called vnl_util_fixed.h. > But theoretically it shall replace the outer_product() function in > vnl_vector_fixed.h Actually, the signature of this function should be extended to allow for the outer product of two vectors of unequal length: template <class T, unsigned m, unsigned n> vnl_matrix_fixed<T,m,n> outer_product(vnl_vector_fixed<T,m> const&, vnl_vector_fixed<T,n> const&); Amitha Perera wrote, in reply to Gehua Yang's request: > Another option is to move outer_product to vnl_matrix_fixed.h With the mentioned extension, this would indeed be the best thing to do, because then it can be included in the definition of VNL_MATRIX_FIXED_INSTANTIATE(T,m,n). Since I don't see an important advantage in having the implementation of outer_product inlined (as it's a double for loop), I would indeed move the implementation to vnl_matrix_fixed.txx. This also avoids the need for mutual #includes between vnl_matrix_fixed.h and vnl_vector_fixed.h. Actually, with respect to mutual 3includes, the solution used in vnl_matrix.h and vnl_vector.h could be mimiced, namely forward declaring both classes in both header files. Remains the API change of (the return type of) the outer_product function. Apart from one place in vnl/tests/test_vector.cxx, none of the current public vxl code will be affected by this change. If noone objects, I will make the necessary changes by the end of next week.  Peter. 
From: Gehua Yang <yangg2@rp...>  20050312 17:01:46

This is probably the best solution. Thank. Gehua Peter Vanroose wrote: >> Gehua Yang wrote about changing outer_product API for fixed vectors: >> Currently, I put the template into a new file called vnl_util_fixed.h. >> But theoretically it shall replace the outer_product() function in >> vnl_vector_fixed.h > > > Actually, the signature of this function should be extended to allow > for the outer product of two vectors of unequal length: > > template <class T, unsigned m, unsigned n> > vnl_matrix_fixed<T,m,n> > outer_product(vnl_vector_fixed<T,m> const&, vnl_vector_fixed<T,n> > const&); > > > Amitha Perera wrote, in reply to Gehua Yang's request: > >> Another option is to move outer_product to vnl_matrix_fixed.h > > > With the mentioned extension, this would indeed be the best thing to do, > because then it can be included in the definition of > VNL_MATRIX_FIXED_INSTANTIATE(T,m,n). > > Since I don't see an important advantage in having the implementation > of outer_product inlined (as it's a double for loop), I would indeed move > the implementation to vnl_matrix_fixed.txx. This also avoids the need > for mutual #includes between vnl_matrix_fixed.h and vnl_vector_fixed.h. > > Actually, with respect to mutual 3includes, the solution used in > vnl_matrix.h and vnl_vector.h could be mimiced, namely forward declaring > both classes in both header files. > > > Remains the API change of (the return type of) the outer_product > function. > Apart from one place in vnl/tests/test_vector.cxx, none of the current > public vxl code will be affected by this change. > > If noone objects, I will make the necessary changes by the end of > next week. > > >  Peter. > > >  > SF email is sponsored by  The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers > > 