Re: [Numpy-discussion] Graph class

[David G. <dav...@gm...>]

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 <wb...@gm...> 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
>
>
> On 8/2/06, David Grant <dav...@gm...> 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
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
> >
> >
>



-- 
David Grant
http://www.davidgrant.ca