[Numpy-discussion] Graph class

Bill Baxter wbaxter at gmail.com
Tue Aug 1 13:41:07 CDT 2006

Hi David,

For a graph, the fact that it's stored as a matrix, or stored as
linked nodes, or dicts, etc,  is an implementation detail.  So from a
classical OO point of view, inheritance is not what you want.
Inheritance says "this is a kind of that".  But a graph is not a kind
of matrix.  A matrix is merely one possible way to represent a graph.
Many matrix operations don't even make sense on a graph (although a
lot of them do...).  Also you say "memory is not a concern (yet)", but
maybe it will be later, and then you'll want to change the underlying
representation.  Ideally you will be able to do this in such a way
that all your graph-using code works completely without modification.
This will be harder to do if you derive from ndarray.  Because to
prevent existing code from breaking you have to duplicate ndarray's
interface exactly, because you don't know which ndarray methods are
being used by all existing Graph-using code.

On the other hand, in the short term it's probably easier to derive
from ndarray directly if all you need is something quick and dirty.
But maybe then you don't even need to make a graph class.  All you
need is

   Graph = ndarray

I've seen plenty of Matlab code that just uses raw matrices to
represent graphs without introducing any new type or class.  It may be
that's good enough for what you want to do.

Python is not really a "Classical OO" language, in the sense that
there's.no real data hiding, etc.  Python's philosophy seems to be
more like "whatever makes your life the easiest".  So do what you
think will make your life easiest based on the totality of your
circumstances (including need for future maintenance).

If memory is your only concern, then if/when it becomes and issue, a
switch to scipy.sparse matrix shouldn't be too bad if you want to just
use the ndarray interface.


On 8/2/06, David Grant <davidgrant at gmail.com> wrote:
> I have written my own graph class, it doesn't really do much, just has a few
> methods, it might do more later. Up until now it has just had one piece of
> data, an adjacency matrix, so it looks something like this:
> class Graph:
>     def __init__(self, Adj):
>         self.Adj = Adj
> I had the idea of changing Graph to inherit numpy.ndarray instead, so then I
> can just access itself directly rather than having to type self.Adj. Is this
> the right way to go about it? To inherit from numpy.ndarray?
> The reason I'm using a numpy array to store the graph by the way is the
> following:
> -Memory is not a concern (yet) so I don't need to use a sparse structure
> like a sparse array or a dictionary
> -I run a lot of sums on it, argmin, blanking out of certain rows and columns
> using fancy indexing, grabbing subgraphs using vector indexing
> --
> David Grant
> http://www.davidgrant.ca
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

More information about the Numpy-discussion mailing list