Synchronization of implementations for layers applicable to complexes of arbitrary rank

[georg-bn]

Some simplicial(/cellular) complex layers are applicable to complexes of arbitrary high rank. This raises the question of how the input to these layers should be formatted.

In #129 we use a dictionary each for adjacencies, incidences and features, indexing each adjacency/incidence/feature matrix by their rank. In #142 lists are used instead. I must admit that I have not carefully checked all implementations to see if there are more examples. Perhaps neither of these solutions is robust enough and there should be some custom data structure for a complex, something like an analogue to the SimplicialComplex class in TopoNetX but using PyTorch instead of NumPy?

In any case it would be good to synchronize the implementations, so I started this issue for discussing!

[mhajij]

Here my initial thoughts on this.

The signature for any TNN should pass ( features, neighborhoods) somehow. In pyg this has the format ( features, index).

In tnx, we create a Data class and this data class should contain all neighborhood matrices as well as features.

Eventually the user stores :

data = Data()

And pass it to the TNN during inference forward(data)

Inside forward one can access : data.xv, data.xe, data.xf, data.A0, data.B0 and so on.
What do you think ?

@ffl096
@michaelschaub
@georg-bn

[mhajij]

Alternatively, one may allow to cash in the complexes and store the matrices inside the complex itself when chosen. Then pass these objects in the forward pass. This will create an overhead however since the object itself contains so much information that is not needed directly for computation of a TNN, only the neighborhood matrices are needed at the end.

The idea for TopoNetx to be numpy and scioy backend is to make it compatible with the sister libraries networks and hypernetx.

A third solution would be to choose the backend for TopoNetx. The last solution is probably the most time consuming to implement but also has long terms benefits.

[georg-bn]

The signature for any TNN should pass ( features, neighborhoods) somehow. In pyg this has the format ( features, index).

In tnx, we create a Data class and this data class should contain all neighborhood matrices as well as features.

Eventually the user stores :

data = Data()

And pass it to the TNN during inference forward(data)

Inside forward one can access : data.xv, data.xe, data.xf, data.A0, data.B0 and so on. What do you think ?

This seems reasonable to me. But I think a pytorch Data class is needed if the aim is to pass it through forward of TNNs. Would it be a pytorch Data class in TNX then? Or a numpy Data class in TNX and a pytorch Data class in TMX?