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 On 8/2/06, David Grant <[EMAIL PROTECTED]> 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > ------------------------------------------------------------------------- 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
