Sphinx 3.0.3 has released, but it doesn't seem to work well with recommonmark just yet. Regardless, we need to find a way to make it work.

Right now we are using degree for each node but we want to consolidate to the Graspy implementation and use the sum of edge weights for undirected graphs and the average sum of in/out degree for directed graphs.

• Support DAD normalized laplacians using weighted degree

Notes: http://www.cs.cmu.edu/~aarti/Class/10701/readings/Luxburg06_TR.pdf

We specify the default in the method signature but we should also specify it in the docs.

https://topologic.readthedocs.io/en/latest/topologic.embedding.html?highlight=node2vec#topologic.embedding.node2vec_embedding

This well-meaning concept tried to provide type information for every attribute added to a graph object via the io & projections package. While neat, I'm not entirely sure I've ever seen or heard of anyone ever using it. It's a needless complexity if it isn't providing immediate and obvious value, and we should remove it.

Leiden University advanced the community identification algorithm first developed by Universite catholique de Louvain in the paper From Louvain to Leiden: guaranteeing well-connected communities, as well as provided a Java reference implementation released under the MIT license.

We now have a working version of this written in Rust and can use pyo3 to provide it as a native Python module. This should be pulled into topologic for others to use.

It should be noted that this initial release is still somewhat fluid, but we're excited to bring this to everyone!

Both modules should be moved to somewhere within the embedding package.

A user has found a bug where a new nx.DiGraph object passed into tc.io.from_dataset is not being used and an undirected graph is returned instead. This is rather surprising since we have unit tests around having graph objects being passed in and being updated.

I was trying to use ts.statistics.cut_edges_by_weight and I got a bit confused by the cut_process argument here - figured it out, but seems worth explaining in the docstring for this function. Could these be string arguments as well?

There are some wrong assumptions in the networkx edge iteration behavior that is resulting in incorrect modularity values being returned. This was noticed when being implemented the first time but incorrectly chalked up to being a floating point arithmetic inconsistency that built upon itself to the point where we were getting accuracy only within 10E-3, but it is instead a definitive logic error.

• Delete iterators module as this isn't useful functionality we wish to expose

We've had a request to add a function that will return a dictionary of communities to the portion of modularity they are responsible for adding in the full modularity calculation

Our Leiden community partitioning is ready for inclusion into topologic. Rather than move all of the existing topologic code around and include the native code all in one PR, I want to ensure we focus on making sure the new structure works first, and then focus on the logic, style, etc of the native code in a separate PR.

The louvain.py file is one method for creating a global partition structure of the graph. We already plan on including leiden's algorithm for global partitioning, and there could be others.

There's also the ability to partition a graph based off the embeddings, which is currently present in the topologic.embedding.clustering package. A more-unified package like topologic.partitioning should probably be created, with louvain.py being moved into it. We should also rename the functions from best_partition to louvain() and induce_graph_by_communities should be specifically made to be not in the louvain.py module.

In the future I envision this partitioning package to also include ways of taking the output of an embedding clustering and inducing a graph from that as well.

In short, we have some short sighted naming going on, and we should use this opportunity to fix it.

We're publishing to pypi - prerelease versions, at least. We should ensure our documentation reflects this.

• Move into a module called similarity at topologic.similarity
• Add support for Jaccard similarity
• Remove calculate_ari_scores function (no more enriched graphs)

• tests/embedding/test_laplacian_spectral_embedding.py -> test_laplacian_embedding_elbowcut_none

This test fails on Mac OS in the github matrix action to run tests on Linux, Windows and Mac OS. The Linux and Windows tests return exactly as expected. I could not reproduce this issue on Mac OS Catalina running Python 3.7.

It is unclear to me whether this is an issue in the code, sklearn, or Github actions. Reproducible steps would be ideal for tracking down the source of this issue.

Marked resolved when we can remove the pytest.skip() from that test.

We want to perform ptr and cvec after we reduce the graphs to contain the common set of nodes

The distance module should be moved and reworked. As it is right now it's just a glorified alias to the scipy functions, which has very little utility (possibly better documentation and type hinting? Not enough to keep around by itself).

However, we do know how we use these:

• Given a vector, we iterate through a list of vectors and return the distances
• Given a vector, we iterate through a list of vectors, sort them, and return the top N

I would argue that these are the utilities we should be providing functionality for - not for calling scipy.spatial.cosine_distance.

At most we should support the 3 functions we currently do (cosine, euclidean, and mahalanobis) via a single function with a hyper parameter for choice - then users can toggle based on a configuration value in their code rather than swapping the function(s) out.

Python versions and operating systems.

topologic/graph_augmentation.py needs to have one line changed:
edge_count = len(graph.edges)

to:

edge_count = len(graph.edges())

We set up a very complicated version file for an internal CICD process that published new versions on merge to master. Switching to open source and requiring a human to be involved in publication obviates this complication, and we should pull it out and do versions like a normal open source python project.