Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Comments

New Algorithm: dynamic approx electrical closeness#1333

Open
bernlu wants to merge 14 commits intonetworkit:masterfrom
bernlu:feature/dyn-approx-electrical-closeness-v2
Open

New Algorithm: dynamic approx electrical closeness#1333
bernlu wants to merge 14 commits intonetworkit:masterfrom
bernlu:feature/dyn-approx-electrical-closeness-v2

Conversation

@bernlu
Copy link

This PR is an updated version of#1097.
Old description:

This algorithm is based on the ApproxElectricalCloseness algorithm in networkit.
The dynamic algorithm supports:

  • edge addition. Algorithm details can be found in our recent paper (which I think is not published yet (?))
  • edge deletion. Based on the same idea as edge addition, with small changes to the math / reordering some terms.

This implementation currently does not support arbitrary edge deletions: edges on the BFS tree from the pivot element u (which is used to approximate r(u,v) for all v) may not be deleted, because this would require a larger update computation. In principle, this is possible, but for our current use case this is not a problem. The code can easily be extended when the need arises.

Additional changes in this PR:

  • updated the description of ApproxElectricalCloseness to a more accurate description of the results properties
  • created a new GTest file which now contains the tests for the static and dynamic algorithm

@bernlubernlu requested a review fromCopilotJuly 15, 2025 11:09
Copy link

CopilotAI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Pull Request Overview

This PR introduces a dynamic version of the ApproxElectricalCloseness algorithm, refactors the static implementation for reuse, and adds corresponding tests and Python bindings.

  • ImplementedDynApproxElectricalCloseness in C++ with update support for edge additions and deletions.
  • RefactoredApproxElectricalCloseness internals (tree structures, memory clearing, parameterized delta).
  • Added parameterized GTests, Python tests, and Cython bindings for the dynamic algorithm.

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file
FileDescription
networkit/test/test_centrality.pyAdded Python unit tests forDynApproxElectricalCloseness, including edge addition/deletion
networkit/cpp/centrality/test/CentralityGTest.cppRemoved old static electrical closeness test
networkit/cpp/centrality/test/CMakeLists.txtRegistered newApproxElectricalClosenessGTest
networkit/cpp/centrality/test/ApproxElectricalClosenessGTest.cppAdded parameterized GTests for static and dynamic algorithms
networkit/cpp/centrality/DynApproxElectricalCloseness.cppNew implementation of the dynamic approximation algorithm
networkit/cpp/centrality/CMakeLists.txtAddedDynApproxElectricalCloseness.cpp to centrality module
networkit/cpp/centrality/ApproxElectricalCloseness.cppRefactored static implementation for reuse and added memory cleanup
networkit/centrality.pyxExposedDynApproxElectricalCloseness Cython bindings and doc updates
include/networkit/centrality/DynApproxElectricalCloseness.hppDeclared the dynamic algorithm interface
include/networkit/centrality/ApproxElectricalCloseness.hppExtended header for delta parameter and refactored internal data structures
Comments suppressed due to low confidence (1)

networkit/centrality.pyx:2554

  • [nitpick] The class docstring does not describe thepivot anddelta parameters in the constructor signature. Add parameter descriptions forpivot (the pivot node for updates) anddelta (approximation probability fallback) to clarify usage.
cdef class DynApproxElectricalCloseness(Centrality, DynAlgorithm):


// To debug
G.forNodes([&](node u) {
if (childPtr[u] != none) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Not sure whether the conditionals are mitigated by the compiler if the asserts are disabled. How about something like aNDEBUG macro surrounding the if-statements?

degDist[b] = std::uniform_int_distribution<index>(0, G.degree(b) - 1);

#pragma omp parallel for
for (omp_index i = 0; i < ustsCurrentRound; ++i) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

static_cast<omp_index>(ustsCurrentRound)

return G;
};

GraphEvent add_random_edge(Graph &G) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

What is the reason for using snake_case here? Normally we use camelBack.

return GraphEvent(GraphEvent::EDGE_ADDITION, a, b);
};

GraphEvent remove_random_edge(Graph &G, const node pivot = none) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Same here.

const count n_gen = 75;
const double er_prob = 0.15;

Graph generate(std::string generator) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Better use a more explicit name likegenerateGraph.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Since this is newly added code, better use longer, more explicit names forG.

Alsoauto is used quite a lot in the code. I suggest to use the explicit types if readability (e.g. long names) isn't affected too much. In some cases, it is not clear, what the type exactly might be (given the function name used to initialize the variable).

auto G = generate(generator);

ApproxElectricalCloseness apx(G, eps);
DynApproxElectricalCloseness dapx(G, eps);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

dApx?

Same for other occasions (likeddiag) below.

auto G = generate(generator);

// make sure that removing an edge does not disconnect the graph
auto star_node = G.addNode();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Why issnake_case used here?

g.addEdge(n, n+1)
g.addEdge(n - 1, n)

dapx = nk.centrality.DynApproxElectricalCloseness(g, eps)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

d_apx?

Same for other occasions.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

Copilot code reviewCopilotCopilot left review comments

@fabratufabratufabratu requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@bernlu@fabratu

[8]ページ先頭

©2009-2026 Movatter.jp