[GRASS-dev] Unused files

[Markus Neteler]

Glynn Clements wrote on 04/17/2007 12:21 AM:
> Markus Neteler wrote:
>
>   
>> These imagery functions, if really unused, are probably
>> delete candidates.
>>     
>
> Apart from that, it would be nice to start 7.x with "rm -rf imagery/",
> and telling people to clean stuff up before they put it back in.
>
> If I'm making the same change to every file which uses a particular
> function, I know I've reached the imagery directory when I start
> seeing almost exactly the same file over and over again. E.g.:
>
> 	imagery/i.ortho.photo/photo.2image/analyze.c
> 	imagery/i.ortho.photo/photo.2target/analyze.c
> 	imagery/i.points/analyze.c
> 	imagery/i.vpoints/analyze.c
> or:
> 	imagery/i.ortho.photo/photo.2image/ask_mag.c
> 	imagery/i.ortho.photo/photo.2target/ask_mag.c
> 	imagery/i.points/ask_mag.c
> 	imagery/i.vpoints/ask_mag.c
> or:
> 	imagery/i.ortho.photo/photo.2image/call.c
> 	imagery/i.ortho.photo/photo.2target/call.c
> 	imagery/i.points/call.c
> 	imagery/i.vpoints/call.c
> or:
> 	[well, you get the idea.]
>   
Yes, the problem is well known - see the GRASS Quality Assessment site,
in particular the clone detection part therein:

http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/clone-browser.html

Maybe Brad has comments on his plans to polish the imagery part.

>>>  lib/vector/Vlib/dbcolumns.c       | Vect_get_column_names
>>>  lib/vector/Vlib/dbcolumns.c       | Vect_get_column_names_types
>>>  lib/vector/Vlib/dbcolumns.c       | Vect_get_column_types
>>>  lib/vector/Vlib/graph.c           | Vect_graph_add_edge
>>>  lib/vector/Vlib/graph.c           | Vect_graph_build
>>>  lib/vector/Vlib/graph.c           | Vect_graph_init
>>>  lib/vector/Vlib/graph.c           | Vect_graph_set_node_costs
>>>  lib/vector/Vlib/graph.c           | Vect_graph_shortest_path
>>>  lib/vector/Vlib/overlap.c         | V__map_overlap
>>>  lib/vector/Vlib/overlay.c         | Vect_overlay
>>>  lib/vector/Vlib/overlay.c         | Vect_overlay_and
>>>  lib/vector/Vlib/overlay.c         | Vect_overlay_str_to_operator
>>>       
>> I am suprised to see these Vect functions unused. Really sure?
>>     
>
> I'm quite sure.
>
>   
>>>  lib/vector/dglib/avl.c            | avl_allocator_default
>>>       
>> avl: libavl - library for manipulation of binary trees
>> I think we have also lib/btree/ is that's the same purpose?
>>     
>
> Yes; both provide essentially the same functionality.
>
> AVL trees are balanced, so they have better worst-case performance.
>
> Unbalanced trees are O(log(n)) for random data but degenerate to O(n)
> for sorted data (you essentially end up with a linked list). Balanced
> trees are always O(log(n)), although with a higher constant factor for
> insertions due to the cost of rebalancing.
>   
Could this be a reason to drop
lib/btree/
and to replace it by a wrapper to
lib/vector/dglib/

(wild guess)?

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------