[BioC] problem with latest version of graph

[Kimpel, Mark William]

Seth,

Thank you for the "mini-vignette"! It will be most helpful :)

I will let more experiences users of the package comment on your
specific ideas.

Mark

Mark W. Kimpel MD 

 

(317) 490-5129 Home, Work, & Mobile

1-(317)-536-2730 FAX

-----Original Message-----
From: bioconductor-bounces at stat.math.ethz.ch
[mailto:bioconductor-bounces at stat.math.ethz.ch] On Behalf Of Seth Falcon
Sent: Wednesday, June 07, 2006 10:10 AM
To: bioconductor at stat.math.ethz.ch
Subject: Re: [BioC] problem with latest version of graph

Hi Mark,

"Kimpel, Mark William" <mkimpel at iupui.edu> writes:
> I am a new user to graph and Rgraphviz but until I updated to R 2.3.1
> today and the latest version of graph, I had no problem displaying
> edge weight labels over my output using code lifted from the Rgraphviz
> vignette. Now, after updating, the edge weights all come out
> "1". Below is some test code that mimics what I have been doing,
> i.e. coercing an adjacency matrix to a graphNEL object. The individual
> points in the matrix are the edge weights I want to have labeled.
>
> As this suddenly appeared after updating, I suspect a problem with the
> package graph.

Yes and no.  But first let me give you a different way to achieve your
goal and then some discusson...

> test.matrix<-matrix(rep(c(1,2,3,4), 9), ncol=6, nrow=6)
>
> rownames(test.matrix)<-colnames(test.matrix)<-c("a", "b", "c", "d",
> "e", "f")
>
> result.gN<-as(test.matrix, Class="graphNEL")

Instead of using the coerce method "as", you will have much more
control over the end result if you call new explicitly to create a
graph instance.  Here's what I mean:

## Use the graphAM class, it is an adjacency matrix representation and
## is easy to initialize given an adjacency matrix
g1 <- new("graphAM", test.matrix)
Error in graph:::isValidAdjMat(adjMat, edgemode) : 
        adjacency matrix must be symmetric for undirected graphs   

## As you can see, the default is to create undirected graphs, but
## that isn't what you want if you have a nonsymmetric adj matrix.
## Let's try again:
g1 <- new("graphAM", test.matrix, edgemode="directed")
g1
A graphAM graph with directed edges
Number of Nodes = 6 
Number of Edges = 36  

## That looks good, but did we pick up the weights?
edgeWeights(g1)[1]
$a
a b c d e f 
1 1 1 1 1 1   

## Not yet.  The graphAM class stores the adj mat as 0/1.  Upon
## initialization, you can tell the system how to interpret the matrix
## values and store them in an edge attribute of your choosing.
## The 'values' arg should be a length 1 list providing the name of
## the edge attribute and the default value for the matrix element
## values.
g1 <- new("graphAM", test.matrix, values=list(weight=1),
edgemode="directed")
edgeWeights(g1)[1]
$a
a b c d e f 
1 3 1 3 1 3   

## But you wanted a graphNEL.  That conversion is easy and does
## preserve node and edge attributes:
g2 <- as(g1, "graphNEL")
edgeWeights(g2)[1]


Some discussion
===============

1. We need to take a look at the Rgraphviz vignette and update it
   where it makes sense to do so.

2. The past behavior of the matrix => graph as() methods is to create
   undirected graphs.  For backwards compatibility, we should continue
   with this.  But I think it makes more sense to create directed
   graphs since they are more general.  I also think we should
   encourage use of new() because it gives the user more control.

3. As for picking up the weights from a call to as(), again for
   backwards compatibility we should probably just make this work.
   Edge weights are special in that they are the most commonly used
   edge attribute.  

   The new fangled node/edge attribute system treats all attributes
   (almost) equally.  They are all stored in the same way and can all
   be accessed using the same API (see the attributes vignette).
   An edge attribute named "weight" is, in the current release,
   slightly more equal :-)  The edgeWeights method looks for this
   special name.  In the devel version, we've added additional
   flexibility to edgeWeights to avoid lock-in to "weight" as a
   special name and to make it easier to verify that the actual edge
   weight values are of the expected type (some algorithms want
   integers, for example).  

ok, maybe I should stop there before this becomes a book.  Comments
and further questions welcome.

Best,

+ seth

_______________________________________________
Bioconductor mailing list
Bioconductor at stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/bioconductor
Search the archives:
http://news.gmane.org/gmane.science.biology.informatics.conductor