From: Amitha Perera <A<mitha@th...>  20070227 15:43:55

It seems like a division into vgl (selfcontained) and vgl_algo (dependent on stuff) is inevitable. In that case, I support Ian's idea of two similarly named include files. The idea is that they conceptually belong in the same file, but are separated for other reasons. However, being consistent about this would mean reconsidering the location of many files in vxl vs vxl_algo. Some examples that jump to mind: vnl_brent, vil_threshold. These are in the _algo libraries, but are not dependent on anything else. I think it's worth doing this for vxl 2.x, but not for vxl 1.x. Amitha. 
From: Joseph Mundy <mundy@le...>  20070226 12:54:29

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 > > > > > > > ________________________________________________________________________ ____________ > Do you Yahoo!? > Everyone is raving about the allnew Yahoo! Mail beta. > http://new.mail.yahoo.com > >   > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys  and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V > _______________________________________________ > Vxlusers mailing list > Vxlusers@... > https://lists.sourceforge.net/lists/listinfo/vxlusers   Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveysand earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ Vxlmaintainers mailing list Vxlmaintainers@... https://lists.sourceforge.net/lists/listinfo/vxlmaintainers 
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 >> >> >> >> >> 
From: Ian Scott <ian.scott@st...>  20070226 16:45:25

Additionally standardising on vgl_intersect(A,B) would be valuable to distinguish from the deprecated intersection standalone functions intersection(A,B). That would allow us to leave the deprecated functions in place for at least one release without breaking the One Definition Rule. I don't think intersection() is one of those functions like swap() that has consistent meaning across multiple libraries, and so the vgl_ prefix is warranted. Ian. Ian Scott wrote: > I agree that moving the intersection(class A, class B) out of either A.h > or B.h is a good idea. And 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 >>> >>> >>> >>> >>> > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vxlmaintainers mailing list > Vxlmaintainers@... > https://lists.sourceforge.net/lists/listinfo/vxlmaintainers 
From: Amitha Perera <A<mitha@th...>  20070227 15:43:55

It seems like a division into vgl (selfcontained) and vgl_algo (dependent on stuff) is inevitable. In that case, I support Ian's idea of two similarly named include files. The idea is that they conceptually belong in the same file, but are separated for other reasons. However, being consistent about this would mean reconsidering the location of many files in vxl vs vxl_algo. Some examples that jump to mind: vnl_brent, vil_threshold. These are in the _algo libraries, but are not dependent on anything else. I think it's worth doing this for vxl 2.x, but not for vxl 1.x. Amitha. 