[GRASS-dev] Unused files

[Glynn Clements]

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.]

> >  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.

-- 
Glynn Clements <glynn at gclements.plus.com>