[Bioc-devel] Base class for interaction data - expressions of interest

Thanks for the comment Nadhir.

I had considered the use of a sparse matrix class. The reason I didn't
implement it originally is because truly sparse interaction data would
be better represented by just working with the pairwise format in the
InteractionSet. You need the row/column indices to pass to the
sparseMatrix constructor anyway; a memory-efficient algorithm to do, for
example, compartment identification could just use that directly.

Most existing algorithms for doing this (e.g., k-means/hierarchical
clustering) won't operate natively from a sparseMatrix, and I suspect
they'll just run as.matrix() and convert it to a full matrix. Obviously,
this would defeat the purpose of using a sparse matrix. So, if you have
to rewrite the algorithms anyway, you might as well rewrite them in a
manner that avoids needing the sparseMatrix() as a middleman.

Nonetheless, it's a good point about memory usage. I'll have a think
about it; sparseMatrix() would help a bit, but as coverage increases for
these experiments, the matrix will probably become fairly dense (even if
it's just counts of 1 for some bin pairs). Even now, for compartment
detection, fairly large bins are involved that sparseness usually isn't
observed. Perhaps big.matrix() might be a better choice.

Cheers,

Aaron


On 16/11/15 09:58, DJEKIDEL MOHAMED NADHIR wrote:

Hi Aaron,

Sounds as a great initiative.
I just have some comments about the ContactMatrix-Class.

I think with increasing Hi-C resolution the usage of the matrix class
will consume a lot of memory.
Maybe using sparseMatrix from the Matrix package has a smaller finger
print.

it can also be manipulated in cpp using  RcppEigen, if for example you
plan some functionalities such as AB domains or insulation scores, ...
etc.

Regards,

- Nadhir

On Mon, Nov 16, 2015 at 5:33 PM, Aaron Lun <alun at wehi.edu.au
<mailto:alun at wehi.edu.au>> wrote:

    Hello all,

    I thought I might give an update on the state of affairs for the
    InteractionSet package. Currently, there's three classes:

    - the GInteractions class, inheriting from Vector and intended to
    represent pairwise interactions between genomic regions (based on
    suggestions from Malcolm Perry and Liz Ing-Simmons).

    - the InteractionSet class, inheriting from SummarizedExperiment0
    and containing a GInteractions object; intended to store
    experimental data about pairwise interactions (one interaction per
row).

    - the ContactMatrix class, inheriting from Annotated and storing
    data in matrix form (where rows/columns represent genomic regions).

    Getters, setters, conversion methods between classes, distance
    calculation methods and overlap methods have been implemented. Man
    pages and "testthat" scripts have also been written. Still missing a
    vignette, though it should be easy enough to write one.

    All in all, I think it's a solid first draft. Any comments would be
    appreciated.

    Cheers,

    Aaron

    On 08/11/15 19:31, Aaron Lun wrote:

        Okay, some meat and bones are on GitHub now:

        https://github.com/LTLA/InteractionSet

        The idea is to represent genomic interactions as pairs of genomic
        regions, using indices to point to a common GRanges object (a la
        Hits,
        though I haven't used that explicitly due to the presence of
        additional
        constraints on the indices). Data for each interaction is stored
        using a
        SummarizedExperiment framework (one row per interaction).

        With regards to the methods, most of the low-hanging fruit has
been
        implemented, courtesy of inheriting from SummarizedExperiment0.
        I'll add
        proper unit tests over the coming week. It currently passes
        through R
        CMD check okay, except for a warning about ":::" in the
cbind/rbind
        definitions (callNextMethod() didn't seem to work inside those
        methods,
        and I didn't want to rewrite the SE0 'binding methods).

        Any thoughts appreciated.

        - Aaron

        On 07/11/15 19:33, Morgan, Martin wrote:

            Just to say that this is a great idea. If this starts as a
            github
            package (or in svn, we can create a location for you if
            you'd like) I
            and others would I am sure be happy to try to provide any
            guidance /
            insight. The main design principles are probably to reuse as
            much as
            possible from existing classes, especially the S4Vectors /
            GRanges
            world, and to integrate metadata as appropriate (like
            SummarizedExepriment, for instance).

            Martin