[BioC] BRUCELLA 2 CHANNEL CUSTOM ARRAYS

[Bandyopadhyay, Somnath (Som)]

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 at stat.math.ethz.ch [mailto:bioconductor-bounces at 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