From: Ian Scott <ian.scott@st...>  20070226 16:39:07

I agree that moving the intersection(class A, class B) out of either A.h or B.h is a good idea. Moving any intersection member functions out of the class is certainly long overdue. Option 2 would be great apart from there being several simple intersections (e.g. plane & line) that would have to go into vgl_algo. Option 1 has the problem that a simple intersection requires a longish name. Does the following make any sense? Option 1a. have two sets files vgl/algo/vgl_intersect.* containing computationallytricky intersections, and vgl/vgl_intersect.* containing all the straightforward ones. Having two files with identical names does seem a little odd  but by analogy to Koenig lookup in namespaces it should be okay. And if we ever start using namespaces  it should work fine. Ian. Joseph Mundy wrote: > One of our goals in making the move is follow the vxl policy of keeping > the basic class interfaces clean. For example, properties like area are > not in the polygon interface, but handled by vgl_area. > > It was the case that some vgl classes had intersection as members and > others didn't, but their intersection method was included in > vgl_intersection instead. Certainly it is awkward to have the > intersection method for heterogeneous class pairs be defined on one of > the pair classes and not the other, but having it on both will violate > the One Definition Rule. > > Since we were adding some new intersection methods it seemed a good > time to reorganize the location of all the intersect methods, not on > the classes. It is also the case that some intersect methods require > vnl_svd, thus necessitating their location in vgl/algo. > > So how to proceed? > 1) Have two versions of vgl_intersect: e.g. > vgl/vgl_intersect_simple, vgl/algo/vgl_intersect. Those intersect > methods that don't require vnl can be kept in vgl_intersect_simple. > This idea has consequences in that vgl_homg_operators and other support > would have to be partitioned into two groups as well. Ian's idea of > special instantiation for <int> can be used to handle the int case. > 2) Keep the intersection method for a class with itself on the > class interface as a static method. Hetrogeneous pairs would stay in > algo/vgl_intersect. This compromise would keep intersect(vgl_box<int>, > vgl_box<int>) in its old location. > > Other ideas? > > Joe > Original Message > From: vxlmaintainersbounces@... > [mailto:vxlmaintainersbounces@...] On Behalf Of Ian > Scott > Sent: Monday, February 26, 2007 5:59 AM > To: Gamze Tunali > Cc: vxlmaintainers@... > Subject: [Vxlmaintainers] vgl_intersection  should be undone? > > Gamze, and vxlmaintainers. > > We have come across other problems with this mod, and would like to > suggest that it be undone, while the issues are resolved. > > > We use vgl_box_[23]d<int> a lot. It had an intersection function  doing > > the obvious thing. When the box intersections were moved into the > vgl_intersection.*, no <int> template instantiation for vgl_intersection > > was created. > > When we added the <int> template instantiation we realised that now > vgl_intersection needs vgl_distance, and hence vgl_distance <int> > template instantiations. However it doesn't really make sense to > instantiate vgl_distance with <int>. We still haven't tracked down all > the missing <int> instantiations. In particular it would require the > <int> instantiation of things like vgl_homg_line, etc. > > We are also not clear about why vgl_instantiation has to be in vgl_algo. > > All the intersection methods we use are simple, and forcing us to link > into vgl_algo adds unnecessary cost to the link time. > > With the previously identified violation of the One Definition Rule, > perhaps this mod should be backed out until it is more thoroughly > tested? > > One potential fix is to split the instantiation macro into two bits  > one bit for <int> compatible functions, and one macro for <float>only > functions. > > Ian Scott. > > Gamze Tunali wrote: >> Hi, >> >> This is a heads up for the new files >> "vgl_intersection.h" and "vgl_intersection.txx" under >> vgl. Like vgl_distance and vgl_closest_point, we >> thought that gathering intersection methods into a >> file will help to find the available methods while >> doing intersection easily. The intersection methods in >> various vgl classes are still there but there is a >> deprecated warning on them. Please start to use >> intersection methods from vgl_intersection.h. I am >> planning to delete the deprecated version after a >> while, when vxl users are aware of the new addition. >> >> There are also intersection methods in >> vgl/algo/vgl_homg_operators. They may be moved into a >> vgl/algo/vgl_homg_intersection as a future to do. I >> noticed that the intersection of a vector of planes >> does not have an assertion on the number of planes. >> But it seems like it should be at least >=3 since the >> result is a vgl_homg_point_3d. Is it a bug or is there >> an explanation that I could not deduce. >> >> Gamze Tunali >> LEMS, Brown University >> >> >> >> >> 