[GRASS-dev] r.cost

[Markus Metz]

Paolo Cavallini wrote:
> Paolo Cavallini ha scritto:
>   
>> Markus Metz ha scritto:
>>     
>>> Could it be that the binary tree implementation in r.cost is not
>>> balanced? If yes, the search tree may degenerate on smooth surfaces
>>> towards a linked list, search time going from O(log n) to O(n). BTW,
>>> there are now three different generic balanced binary search tree
>>> implementations in the vector libs, plus sorted heaps. Just an idea.
>>>       
>> Tested on two different machines, (ubuntu+debian) 3 diff surfaces,
>> always the same result. It seems something more structural.
>> :(
>>     
My comment was a suggestion to Colin Nielson to use another binary tree 
in r.cost if the current tree is not a balanced tree, and that there are 
generic balanced binary tree implementations in the vector libs that can 
be used by other developers in their modules. AFAIKT r.cost uses the 
same binary tree implementation in all versions, i.e. the results and 
the speed should be similar on different machines and with different 
grass versions.