Neighbors function name is counterintuitive for Digraphs.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.create a di_graph such that digr= [0, 1, 2, 3, 4] [(0, 1), (0, 2), (0, 
3), (1, 3), (1, 4), (2, 4), (3, 2), (3, 1), (3, 0), (4, 1), (4, 3), (4, 0)]

2. digr.neighbors(0) returns [1,2,3]

What is the expected output? What do you see instead?

From a layman viewpoint, since there is an edge from node 4 to node 0, i 
would expect 4 to be a neighbour, as that is closer to the real world 
definition of neighbour.

What version of the product are you using? On what operating system?
1.7.0

Please provide any additional information below.
This is not exactly a bug, but a question of the function name neighbors. 
In the case of digraphs the current definition stands as the list of nodes 
which have incident edges from the given node.

So i propose we either rename the function or rewrite it. I think renaming 
is a better idea, since we don't really need the real-world neighbours 
concept in a digraph.(Correct me if i am wrong)

P.S: I looked up digraphs on wikipedia and mathworld.wolfram, but couldn't 
find anywhere the term neighbours used/defined in the context of directed 
graphs.

Original issue reported on code.google.com by anand.jeyahar on 25 May 2010 at 9:40

[GoogleCodeExporter]

That's the behaviour of neighbours() on a regular graph: If node A is an 
neighbour of 
node B then node B must be a neighbour of node A. That's not the case with a 
digraph.

Consider the trivial digraph which can be written A -> B, or 

nodes = [ "A", "B" ]
edges = [ ("A", "B"), ]

B is a neighbour of A
A is incident on B
A is NOT a neighbour of B

Original comment by salimfadhley@gmail.com on 25 May 2010 at 10:21

[GoogleCodeExporter]

I agree that the naming is a bit strange, but we need this to ensure 
compatibility
between graphs and digraphs.

I'm marking this as Invalid, but this might change on a future API refactoring.

Original comment by pmatiello on 25 May 2010 at 10:50

• Changed state: Invalid