[Numpy-discussion] Graph class
davidgrant at gmail.com
Tue Aug 1 15:31:35 CDT 2006
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.
On 8/1/06, Bill Baxter <wbaxter at 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.
> 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
> > methods, it might do more later. Up until now it has just had one piece
> > 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
> > 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
> > 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
> > opinions on IT & business topics through brief surveys -- and earn cash
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion