Thanks Bill, I think you are right, I think what I have is what I want (ie. not extending ndarray). I guess do go along with the "whatever makes your life the easiest" mantra, all I am really missing right now is the ability to access my Graph object like this g[blah] with square brackets and to do vector indexing and all that. What is the name of the double-underscored method that I should implement (and then call the underlying datastructure's corresponding method)? I see __getitem__ and __getslice__... hmm, this could get messy. Maybe the way I have it is ok. Maybe I can live with G.Adj. Dave On 8/1/06, Bill Baxter <wbaxter@gmail.com> wrote:
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.
--bill
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
can just access itself directly rather than having to type self.Adj. Is
On 8/2/06, David Grant <davidgrant@gmail.com> wrote: then I 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > >
-- David Grant http://www.davidgrant.ca