Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orientation of simplicial complexes #358

Open
ffl096 opened this issue May 29, 2024 · 3 comments
Open

Orientation of simplicial complexes #358

ffl096 opened this issue May 29, 2024 · 3 comments

Comments

@ffl096
Copy link
Member

ffl096 commented May 29, 2024

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
Copy link
Member Author

ffl096 commented May 29, 2024

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.

@USFCA-MSDS
Copy link
Contributor

@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?

@ffl096
Copy link
Member Author

ffl096 commented Oct 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants