TopoNetX icon indicating copy to clipboard operation
TopoNetX copied to clipboard

Orientation of simplicial complexes

Open ffl096 opened this issue 1 year ago • 3 comments

The Problem

Simplicial complexes are often used with an arbitrary reference orientation in mind, e.g., when considering edge flows. Consider this simple example:

from toponetx.classes import SimplicialComplex

SC = SimplicialComplex()
SC.add_simplex((2, 1), flow=10)

The user should expect that the edge (2, 1) is added with exactly this orientation, i.e., with an edge flow of 10 from node 2 to node 1. However, TopoNetX does not handle orientation, it transforms the edge into canonical form (1, 2) without any thought about associated data that might be orientation-aware.

Possible Actions

  • Full-fledged orientation support. This is a big undertaking, especially for when already existing simplices are re-added with a different orientation. A priori it is not clear how to deal with already existing data, as we cannot infer whether arbitrary user-data is relative to the orientation or not. For data that is relative to orientation, we might have to change the sign, for other data (with may also be numeric), we must not alter them.
  • Offload the cannocalization and appropriate sign-changes of data to the user. SimplicialComplex.add_simplex calls are only allowed for pre-sorted tuples.

ffl096 avatar May 29 '24 08:05 ffl096

A priori it is not clear how to deal with already existing data, as we cannot infer whether arbitrary user-data is relative to the orientation or not. For data that is relative to orientation, we might have to change the sign, for other data (with may also be numeric), we must not alter them.

We can work around this issue by replacing the attributes of existing simplices instead of updating/extending them. If we go that round, we should make this change consistently across all complexes though.

ffl096 avatar May 29 '24 13:05 ffl096

@ffl096 what do you mean across all complexes ? how do we make sense of orientation of combinatorial complexes? I think the difference is not trivial. Even for simplicial complex, having orientation per simplex is an assumption and abstract simplicial complexes do not come with orientation on each simplex by default. Orientation is only defined when one needs to define a matrix rep for the boundary operator.

I suggest the following : create a class called OrientedSimplex, and OrientedSimplicialComplex, what do you think?

USFCA-MSDS avatar Oct 20 '24 22:10 USFCA-MSDS

what do you mean across all complexes ? how do we make sense of orientation of combinatorial complexes?

I didn't say that combinatorial complexes have an orientation. However, if we go the route of replacing vs. updating attributes, this change should be made across all complexes, even though the need only arises for (oriented) simplicial complexes.

I suggest the following : create a class called OrientedSimplex, and OrientedSimplicialComplex, what do you think?

No. There is no harm in having an orientation-aware simplicial complex even though you don't make use of orientation as an user. Maintaining both would be a nightmare.

ffl096 avatar Oct 21 '24 06:10 ffl096