Dear Seth, thanks for your detailed reply. On 4/11/07, Seth Falcon <sfalcon at="" fhcrc.org=""> wrote: > [..] > We also found that many methods for manipulating and computing on > graphs made assumptions that failed when the input graph was > non-simple. So it isn't quite true that non-simple graphs were > supported in earlier versions -- they were tolerated ;-) I see your point but one thing is bad(*) in the way it was done: It breaks old code. It took me several days to trace a wrong result in my code back to the changed behaviour of the graph package. Therefore I would deeply recommend to add something like a warning or a specific fragment of deprecation in such a situation. (*) By bad I mean not only my personal situation but in the sense of the "design by contract" principle. The package worked with multigraphs, therefore it either has to do it forever or explicitly "cancel the contract" in the sense of issuing a warning or the like. Otherwise situations like this might happen often over time. > We don't have the resources, or use-cases, right now to implement > classes for multigraphs or other non-simple graphs. But we would > welcome well-written patches to the graph package that added such > support. Extending graphNEL and providing specialized methods for > addEdge, removeEdge might be a start. I see your point but right now I can not help with that as I have to finish writing a thesis... Again, thanks for the great software and all the work done. All the best, Dirk

Hi, I am trying to analyze 2 channel data without dye swap from Brucella arrays. Is there a module/package specific for the qualit control analysis of this kind of data from Brucella? -----Original Message----- From: bioconductor-bounces@stat.math.ethz.ch [mailto:bioconductor- bounces@stat.math.ethz.ch] On Behalf Of Seth Falcon Sent: Tuesday, April 17, 2007 10:35 AM To: Dirk Kosch?tzki Cc: bioconductor at stat.math.ethz.ch Subject: Re: [BioC] Package "graph": bug in function addEdge Hi Dirk, "Dirk Kosch?tzki" <dkoschuetzki at="" googlemail.com=""> writes: > I see your point but one thing is bad(*) in the way it was done: It > breaks old code. It took me several days to trace a wrong result in my > code back to the changed behaviour of the graph package. Therefore I > would deeply recommend to add something like a warning or a specific > fragment of deprecation in such a situation. I'm really sorry about the frustration the change has caused. I dropped the ball with respect to announcing these changes and will do my best to improve such communication in the future. > (*) By bad I mean not only my personal situation but in the sense of > the "design by contract" principle. The package worked with > multigraphs, therefore it either has to do it forever or explicitly > "cancel the contract" in the sense of issuing a warning or the like. > Otherwise situations like this might happen often over time. Perhaps we should have issued a warning when adding an edge that already exists. I will see about adding that. Note that this change is over 1 year old (here is the log from svn): Date: Thu Mar 2 01:32:02 2006 +0000 Disallow duplicates when using addEdge on a graphNEL Up until now, one could add duplicate edges to a graphNEL using addEdge. This can complicated reading serialized graphs, such as GXL, because for an undirected graph it is reasonable to have the reciprocal edges in the serialization (or not). This change does not add anything to the validity check, so a valid graphNEL can still contain dup edges, but it is slightly more difficult to create one now. In the future, we plan to implement a multiGraphNEL or some such for the purpose of representing graphs with multiple edges between a given pair of nodes. We try our best to be careful with changes and issue warnings when contracts change. Sometimes things slip through and this is such an example. Although the change didn't get mentioned, there were general announcements sent to the list about (what was then) recent work on graph and such announcements are invitations to test and give feedback. See, for example, these posts: http://article.gmane.org/gmane.science.biology.informatics.conductor /8465/match=graph http://article.gmane.org/gmane.science.biology.informatics.conductor /8663/match=graph > Again, thanks for the great software and all the work done. You bet. Again, sorry for the snag. I hope you will get a chance to update, test, and give us feedback on graph more often :-) + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org _______________________________________________ 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