Re: [Vxl-maintainers] vgl_intersection - should be undone?

[Ian S. <ian...@st...>]

Additionally standardising on vgl_intersect(A,B) would be valuable
to distinguish from the deprecated intersection stand-alone 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 computationally-tricky intersections,
> and
> vgl/vgl_intersect.* containing all the straight-forward 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 re-organize 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: vxl...@li...
>> [mailto:vxl...@li...] On Behalf Of Ian
>> Scott
>> Sent: Monday, February 26, 2007 5:59 AM
>> To: Gamze Tunali
>> Cc: vxl...@li...
>> Subject: [Vxl-maintainers] vgl_intersection - should be undone?
>>
>> Gamze, and vxl-maintainers.
>>
>> 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 surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers