Implementing personalized PageRank for graph node scoring.

[maniospas]

Before filing

• I searched the existing issues and did not find a duplicate.
• This is a concrete proposal, not an open-ended design question.

Kind of addition

• New algorithm
• New data structure
• New property map or utility
• New I/O format reader or writer
• Extension to an existing component
• Performance improvement
• Other (specify below)

Motivation

Following preliminary discussion in #492 , this proposal aims to bring the popular personalized node scoring/ranking algorithm to BGL. Personalized node scoring can be used to score nodes with respect to their structural proximity to a (weighted) set of seed nodes, so it can be used for overlapping community member scoring and ranking. It can also be used as a building block for more complex community detection schemes that satisfy theoretical properties like finding structural communities of low conductance given that the seed nodes lie closely together. Finally, node scores can be used for link prediction by starting from one node and finding structural close alternatives.

The proposal below presents some basic information for bringing these kinds of methods, and can be used as future basis for also implementing more spectral graph filters (not to be confused with full-blown spectral processing in that spectral filters act on eigenvalue-based properties by actually working only on the vertex domain for near-linear instead of quadratic time complexity).

Proposed addition

In linear algebra terms, the algorithm implements the iterative scheme:

$p = (1-dmp)Ap+dmp p_0$

where A is broadly a normalized graph adjacency matrix, dmp is the equivalent of the dampening factor (equal to 1-restart probability of equivalent random walk with restart schemes), and $p_0$ a starting personalization vector. As an API, this would mainly follow the existing page_rank interface:

template <typename Graph, typename RankMap, typename Done>
void personalized_page_rank(const Graph& g, RankMap rank_map, Done done,
               typename property_traits<RankMap>::value_type damping,
               typename graph_traits<Graph>::vertices_size_type n,
               Normalization normalization,
               Optimizer optimizer,
               RankMap1 rank_map1,
               RankMap2 rank_map2);

Simplifications analogous to page_rank's will be added, for example so that done uses some common default (see below for planned options for convergence tracking; it is not as simple a problem as it appears).

Important differences:

A. rank_map will hold both input personalization $p_0$ and the eventually outputted $p$, in alignment with page_rank's interface. This can change but I think it's elegant. Two more storage containers for node values are inserted, as we need to keep track the previous and next node values, as well s the personalization. All vertex value containers would be ReadWritePropertyMaps.

B. I am proposing that the default for done should not be a fixed number of iterations, as this creates a high computational overhead or may not be enough for robustness in scoring or rank order. Since I have worked on research determining robust stopping orders [2], I am proposing implementation of three different schemes, of which the first one would be the default, the second an alternative when correct ranking order does not matter as much as correct scoring, and the third is a practically unknown but a more theoretically rigorous version of the first:

• Run for max(10, ceil(1/dmp)) iterations to account for most random walks of the equivalent random walk with restart scheme per [2]
• Use mean(abs(p-p_previous))<tol as the stopping criterion with tol=10E-9 as the default (the popular Python library networkx does this, but its default tol=10E-6 is not sufficient for most graphs).
• [Optional implementation - may consume a PR by itself] Use the adaptive criteria of [2] as a more advanced version of the previous bullet point, where a confidence score is provided. The exact criterion is a bit complicated to write as markdown (see the paper) but would require an interface akin to the above bullet point.

This means that Done would in general require as inputs const RankMap& rank_map1 and const RankMap& rank_map2 to compare, and contain early stopping parameter as well as a user-provided upper bound to the number of iterations that can be 100 by default. The last one is needed because, depending on what input are provided, the computations may never converge and it would be nice for applications to stop. I see that other components throw boost::throw_exception and we could also do it here.

C. Normalization means that each edge is weighted by either 1/out_degree(u) or, more common for results compatible with spectral graph theory, by 1/sqrt(out_degree(u)*in_degree(v)) (would collapse to 1/sqrt(out_degree(u)*out_degree(v)) for edge (u,v) of an IncidenceGraph). I have a sense that this may be more computationally intensive than needed and that there should be a mechanism to cache edge weights. So, for this, I have a question if there is some appropriate structure to use.

In order to not overcomplicate things, a first implementation would just run the computations eagerly, making normalization above would be an enum enum class Normalization { Markovian, Symmetric, Laplacian }, corresponding to divisin with outdegree, the geometric means of degree, and the last case while using (I-A) instead of A to obtain a high-pass instead of low-pass filter.

Extensibility considerations: Future versions could accept as argument a storage container for edge weights (like WeightMap for betweeness centrality) as well as means of precomputing and sharing those, but that would be too much potentially interface-risky work for my first PR given that I also need to practically familiarize myself with the codebase's abstractions. Such an extension would be backwards compatible with the above interface.

D. The above design has delegated an optimizer parameter, which will account for future schemas for speeding up convergence speed. There are many means of performing such optimizations, some of which have grown a bit dim in my mind and I would need to re-read material to implement them. However, the most important of those to be included as a first version, and aside from not making any "optimization", is to again normalize vectors after each iteration.

This renormalization has the advantage of performing numerically stable computations by keeping track of the L2 norm of the input/personalization, normalizing the latter, normalizing p after each iteration, and then multiplying the results with the tracked norm. This also speeds up convergence a lot (and even makes it possible if node scores would otherwise be numerically divergent), but has the issue of losing some nuance in the resulting rank magnitude and should therefore be an opt-in (or opt-out) scheme.

Since I am not sure what extensions would be made in the future, I am proposing the optimizer to be of enum class Optimizer { None, Renormalize } (if needed, it could be combined with Normalization as a bitfield-based approach but would prefer to keep type-based explicitness).

Relation to existing Boost.Graph components

This is similar to the page_rank algorithm.

Prior art

• Reference paper or textbook (cite below)
• Implementation in another library (link below)
• None / original idea

References:

Introductory paper is [1], but the proposal aims to follow the implementation of [3], which different from the original paper by adding options for more recent esearch results (see above). The stopping criteria would be determined per [2].

1. https://api.semanticscholar.org/CorpusID:1508503
2. 10.1109/ASONAM49781.2020.9381435
3. https://github.com/MKLab-ITI/pygrank/blob/master/pygrank/algorithms/filters/adhoc/pagerank/pagerank.py

Are you willing to contribute?

• I'd like to submit the implementation as a pull request.
• I can help with review or testing, but not the implementation.
• I'm only proposing the idea.

Edit: typo fixing

[Becheler]

Hi @maniospas !
Thank you for this high-quality feature proposal ! 🤩

Here are some suggestions, @jeremy-murphy will correct me if I say wrong things:

1) It may be more idiomatic to take property maps as independent parameters and let the caller alias them if they want in-place behavior

template <typename Graph, typename PersonalizationMap, typename RankMap, typename Done>
void personalized_page_rank(const Graph& g,
                            PersonalizationMap p0,    // input: seed weights
                            RankMap rank,             // output: final scores
                            Done done,
                            /* ... */);

The erasing decision happens from user's side:

personalized_page_rank(g, scores, scores, done, ...);   // alias: p0 destroyed
personalized_page_rank(g, seeds, scores, done, ...);    // seeds preserved

It is also more expressive and more efficient in case where the input can be generated in a lazy manner (can be read from but not written to):

// Function property map: seed is "1.0 if v == source, else 0"
auto p0 = boost::make_function_property_map<Vertex, double>(
    [source](Vertex v) { return v == source ? 1.0 : 0.0; });

personalized_page_rank(g, p0, rank, done, ...);

2) Don't lock behavior behind closed-sets like enums

enum class Normalization { Markovian, Symmetric, Laplacian }

I completely understand the intent, it's quite pythonic, and many former colleagues reached for enums even in C++. 😄 The main issue is that you will completely locking the library behind the three choices that have actually been merged, without letting to users the freedom to inject their own normalization functions.

What you could do is instead taking ... another property map 😉 With just the same benefits as in point 1).

If I understand correctly, a NormalizationFunction associates a value to an edge. A property map is precisely the abstraction BGL relies on for "thing keyed by edges (or vertices) that yields a value" and it doesn't commit to how the value is produced. The caller decides:

template <typename Graph, typename PersonalizationMap, typename RankMap, typename EdgeWeightMap, typename Done>
void personalized_page_rank(const Graph& g,
                            PersonalizationMap p0,
                            RankMap rank,
                            EdgeWeightMap weight,   // ReadablePropertyMap<Edge, T>
                            Done done, ...);

And the user decides if its precomputed:

std::vector<double> w(num_edges(g));
auto weight = make_iterator_property_map(w.begin(), get(edge_index, g));
// fill w with 1/sqrt(d_u * d_v) once

or computed on the fly (no storage, which is great, but recomputed every time) :

auto weight = make_function_property_map<Edge, double>(
    [&g](Edge e) {
        auto u = source(e, g), v = target(e, g);
        return 1.0 / std::sqrt(out_degree(u, g) * in_degree(v, g));
    });

and you can of course alleviate the user by providing helpers:

auto weight = make_markovian_weight_map(g);
auto weight = make_symmetric_weight_map(g);

Note: the abstraction looks healthier but I am not sure how the Laplacian will hold here. Maybe better passing a low_pass_t / high_pass_t little struct as a parameter for a dispatch at compile time ?

3) Don't lock the optimizer

The optimizer seems to have a different shape.

• cross-iteration state (the tracked L2 norm)
• hooks into iteration lifecycle events.

That is what BGL visitors are for. You could think of a general visitor as a little user-provided object that hooks into the algorithm flow to update (or not) its own internal state:

struct personalized_page_rank_visitor_concept {
    void initialize_personalization(p0, g);
    void start_iteration(p, iter, g);
    void finish_iteration(p, iter, residual, g);
    void finalize(p, g);
    void diverged(p, iter, g);  // before throwing
};

So a user (or the library itself if you want to provide default implementations) can define each of these functions to have access to the algorithm's internals:

• A default_personalized_page_rank_visitor would be an empty stub that does nothing
• A renormalizing_visitor track L2 with a e.g. a m_L2 state.
• A user who wants to log convergence, plot residuals, or implement the adaptive stopping criterion just writes their own visitor

Note: In the general mindset of the BGL, visitors are mere observers that can only read the algorithm state, not influence its flow (that's why every method actually return void). For example, the only way to terminate Dijkstra early is to throw an exception from inside a visitor hook and catch it (yes it's ugly, see here: #466 (reply in thread) ). But in recent discussions with @jeremy-murphy and others we began to agree that returning something else than void from visitor hooks may be more flexible. Maybe we can try it on your PR as a proof of concept ? I can also try it on my Louvain clustering algorith 😉

All of this is just design ideas thrown at you - I am not a PageRank expert, but those are the same kind of points my PR got stuck before merge, so you may save a bit of coding efforts knowing them earlier ? 😄

Anyway, just tell me what you think and let's keep the conversation going, thanks again for contributing ! 🚀

[maniospas]

Thanks a lot for the input. 😄

Yes, it's better to do it as you suggest on all points.

1 Separate input type

The output map can indeed be what was rank_map1 then (moved to early argument order - exactly what you wrote), and have the personalization be a type of its own. Bonus points that personalization is often very sparse, so it makes sense to represent it as a sparse data structure too. I am starting to really appreciate the dynamism here.

2 EdgeWeightMap

For EdgeWeightMap I weirdly missed that it exists, which is why I was uncertain what to do. The abstraction with the user options also helps model some ad-hoc degree mixing schemes that make sense (e.g., getting the product instead of geometric men) but which I was hesitant of having in a first proposal due to being more obscure. Introducing a Laplacian just needs the vertexes to be tested for equality and 1+... can be manually added to the off-diagonal computed degrees, while appropriately modifying the diagonal too.

Perhaps the three normalization (markovian, symmetric, laplacian) can be implemented as eager computations and then have a cached_weight_map<container,normalization_strategy> templated to be called like below - perhaps there is some similar structure for caching maps already?

auto weight = detail::cached_weight_map<std::vector, detail::markovian_weight_map>(g);

In general, I will PR stuff with some naming that makes sense to me, but it is always better if you adjust the final names yourselves to align with the rest of the library.

3 Optimizer

I see. Visitors seem like as a nice pattern indeed.

Actually my intent with enums was not to lock everything in the usage pattern once something definite comes up design wise... like the visitor pattern you mention 👍 ... and then replace the enum with a namespace for backwards compatibility. But, at any rate, if there is a pattern established it can be followed.

To be clear: the visitor that is needed here must be able to make intrusive modifications on the state, namely be able to take non-const RankMap& and RankMap2& as arguments. If this is acceptable, I can implement it as a test (it's easier to desugar into something else from this state), and you can decide how to move forward. I am also worried about accidental mutation, especially library users somehow evoking the [] operator and resizing something, but am not sure if something else could be done and it seems too convenient to not try it here.

P.S. Based on the discussion for Louvain, a returning visitor could also be the way to go for convergence, if that is allowed in the end.

[Becheler]

Oh I see yes your intentation was opening doors indeed showing the points of variations ! Thanks for making them clear to non-PageRank experts ! 🫶

2 EdgeWeightMap

I am not aware of a cached_map and I feel this is orthogonal to this PR. Would you slowly guide me through the operations you would want to see and how they would vary across the markovian/symmetric/laplacian variants ? I suspect we have different way to inject that, with different trade-offs, including asking the user to deal with it 😉

3 Optimizer

Intrusive modification on the state does not sound like something we want a visitor to be able to perform. I feel ok with a visitor being able to "rewires" the algorithm to a different flow, returning a bool or an enum {continue, stop, diverge}`: in this case the set of behavior is closed. But I feel it would be too much responsibility on the user to give them a non const reference on the algorithm internal state. Can you walk me slowly through why this is required ? I am sure we can find an alternative design 😄

Note: Please do not worry about the named parameter overload, we are aiming at deprecating them. A fully positional overload as you suggested will perfectly fit the bill 😄

[maniospas]

3 Optimizer

Sure, so the renormalization first (opposite order of answering). The schema that needs sugaring is basically something like this (pseudo-code for brevity, assume L2 to be a computation of the L2 norm, other cases depending on the optimization strategy):

personalization_type personalization_scale = 0;

// strip away the scaling factor to have L2 norm=1 on the personalization
if (ENABLED_RENORMALIZATION) 
{
     personalization_scale = L2(personalization_map);
     // error here if scale is zero because it indicates uninitialized personalization (all zeroes don't need to run)
     BGL_FORALL_VERTICES_T(v, g, Graph)
     put(personalization_map, v, get(personalization_map,v)/personalization_scale);
}

// run power method
while(true) {
    if(to_map_2) {
        // run iteration normally

        // maintain L2 norm=1 (at least to numerical tolerance)
        if(ENABLED_RENORMALIZATION) // post-processing needed per iteration
        {
             auto scale = L2(rank_map);
             BGL_FORALL_VERTICES_T(v, g, Graph) 
             put(rank_map, get(rank_map2,v)/scale);
         }
    }
   else {
       // dual of above mode
    }
}

// finalization per normal before scaling back to the original

// multiply result with the stripped-away scaling factor so that the L2 norm of the output=L2 norm of the input
if (ENABLED_RENORMALIZATION) 
{   
     BGL_FORALL_VERTICES_T(v, g, Graph) 
     put(rank_map, v, get(rank_map,v)*personalization_scale); // can be optimized a bit for the last iteration but it's a valid first take before making the code more obscure
}

Since this is somewhat unique to this kind of algorithm, it could be an interface onto itself; something like

struct page_rank_optimizer_concept {
    void prepare(&p0, g);
    void step(&next_ranks, previous_ranks, p0, g);
    void finalize(&p, g);
};

I agree that this is too much responsibility to the user. Though, at the point they feel compelled to write something like this instead of using some out-of-the-box options, I believe they understand enough to not be harmful. One option would be to pass L2 as a templated type and have a special version that performs no normalization, but that loses a lot of expressive power. Perhaps following the above and not advertising it as a visitor could be enough, right?

Regardless, returning visitors could be tested by via the stopping criteria instead, which can only be true/false on each iteration and more closely resemble the intent.

2. EdgeWeightMap

With respect to caching, I mean being able to quickly place the computation outcome in a container like a vector or hashmap. That is, currently I would optimize compute for a weighted graph -if storage was not an issue- by creating the container, iterating through edges, running the graph normalization scheme of choice, saving edge weights to the container and then finally calling something like make_iterator_property_map or associative_property_map or create an associative map. Or something like that.

That said, indeed this option is orthogonal to this feature (though this feature would likely be its main consumer), so let's leave it aside as it is not needed for now. 😄 Some benchmarking after personalized_page_rank is there could help determine if there are actual benefits to suggest this later as an optimization.

[Becheler]

Ok, so let's put aside the caching optimization since it's orthogonal 👍🏽

Important Note: Property maps in BGL are passed by value, not by (const) reference. They are designed to be lightweight handles and copying them is meant to be cheap. The "real" data lives elsewhere (in a std::vector, in the graph, in a std::map, etc.). So when you see (const) refs to Property map in the following pseudo code, just think of them as being readable property maps or writable property maps, see https://becheler.github.io/graph/graph/property_maps/overview.html#_property_map_categories

Current Page Rank

The current PageRank overloads are:

// 1. Most explicit: takes a second rank map for double-buffering
template <typename Graph, typename RankMap, typename Done, typename RankMap2>
void page_rank(const Graph& g, RankMap rank_map, Done done,
               typename property_traits<RankMap>::value_type damping,
               typename graph_traits<Graph>::vertices_size_type n,
               RankMap2 rank_map2);

// 2. Drops rank_map2 : algorithm allocates a std::vector internally
template <typename Graph, typename RankMap, typename Done>
void page_rank(const Graph& g, RankMap rank_map, Done done,
               typename property_traits<RankMap>::value_type damping,
               typename graph_traits<Graph>::vertices_size_type n);

// 3. Drops n : defaults to num_vertices(g); damping defaults to 0.85
template <typename Graph, typename RankMap, typename Done>
void page_rank(const Graph& g, RankMap rank_map, Done done,
               typename property_traits<RankMap>::value_type damping = 0.85);

// 4. Drops everything : defaults to n_iterations(20)
template <typename Graph, typename RankMap>
void page_rank(const Graph& g, RankMap rank_map);

Importantly, there is not visitor.

Viable Minimum Proposal

Unless I'm mistaken, the minimum viable signature for personalized page rank would be:

void personalized_page_rank(g, p0, rank_map, weight, done, damping, n, rank_map2);

Importantly, there no optimizer (that would be the None in your enum class Optimizer { None, Renormalize } framing.

This is already significant extension over the existing API and I think it would be a tremendous addition ❤️ 🚀
I also think we should focus on landing that level of PR to avoid scope creep (see next section). Do you think it could be a good first step ? 😄

Ideas for Future extensions

The next levels would be harder, in visitor territory and rely on changing the visitor semantics for the entire BGL (from observer to algorithm flow participant, and this raises lots of new questions).

Let's assume @jeremy-murphy validates that visitors could participate in the flow of executation of algorithms by returning non-void types... I am waving hands right now because it's a larger discussion: we should first decide if we authorize bool (binary flow) or enums (open ended, extensible).

If this is agreed upon as a new BGL direction, then we could do something like this:

// your PR1 overload
void personalized_page_rank(g, p0, rank_map, weight, done, damping, n, rank_map2);

// new overload that does not break users of the former
void personalized_page_rank(g, p0, rank_map, weight, damping, n, rank_map2, visitor);

The visitor would define the state it needs to track through iterations. The visitor returns the measured norm, algorithm decides operation per hook. A default visitor would return 1 to every hook.

struct personalized_page_rank_visitor_concept {
    T initialize(const P& p0, const G& g); // strip from p0
    void start_iteration(const P& p, const G& g);
    T rescale_factor(const P& p, const G& g); // per-iteration scale
    bool should_continue(const P& p, const G& g); // flow control
    T finalize(const P& p, const G& g); // restore to output
};

The algorithm code against this concept could be:

// new overload that does not break users of the former
void personalized_page_rank(g, p0, rank_map, weight, damping, n, rank_map2, vis)
{
    strip = vis.initialize(p0, g)
    p0_view = view of p0 divided by strip

    rank_map <- p0_view

    loop:
        vis.start_iteration(current, g)

        next <- (1 - damping) * A_weighted * current + damping * p0_view

        s = vis.rescale_factor(next, g)
        next <- next / s

        if not vis.should_continue(next, g): break

        swap(current, next)

    final_scale = vis.finalize(rank_map, g)
    rank_map <- rank_map * final_scale
}

And concrete visitors implementations could be something like this

struct default_visitor {
    template <class P, class G> T initialize(const P&, const G&) { return T(1); }
    template <class P, class G> void start_iteration(const P&, const G&) {}
    template <class P, class G> T rescale_factor(const P&, const G&) { return T(1); }
    template <class P, class G> bool should_continue(const P&, const G&) { return true; }
    template <class P, class G> T finalize(const P&, const G&) { return T(1); }
};

struct renormalizing_visitor {
    T initial_scale = T(1);

    template <class P, class G>
    T initialize(const P& p0, const G& g) {
        initial_scale = compute_L2(p0, g);
        if (initial_scale == T(0))
            boost::throw_exception(null_personalization{});
        return initial_scale;
    }

    template <class P, class G>
    void start_iteration(const P&, const G&) {}

    template <class P, class G>
    T rescale_factor(const P& p, const G& g) {
        return compute_L2(p, g);
    }

    template <class P, class G>
    bool should_continue(const P&, const G&) { return true; }   // doesn't decide stopping

    template <class P, class G>
    T finalize(const P&, const G&) { return initial_scale; }
};

struct residual_threshold_visitor {
    T eps;
    std::vector<T> previous;  // its own buffer, not the algorithm's

    template <class P, class G> T initialize(const P&, const G& g)    {
        previous.assign(num_vertices(g), T(0));
        return T(1);
    }
    template <class P, class G> void start_iteration(const P&, const G&) {}
    template <class P, class G> T rescale_factor(const P&, const G&)  { return T(1); }

    template <class P, class G>
    bool should_continue(const P& p, const G& g) {
        // iterate over vertices,
        // accunulate absolute differences between current and previous p 
        // summarize average change
        return average_change > eps; // true: continue, false: stop
    }

    template <class P, class G> T finalize(const P&, const G&) { return T(1); }
};

Sorry to use this discussion as design notes, but I feel it's also helping both of us understanding what we are trying to do 😄

I also think I will test these ideas on visitors extensions on my Louvain work because we both share the same problem space (iteration stopping criterion, arbitrary transformation functions etc). Hopefully I can battletest the design, inform the visitor design discussion and validating/invalidating my next Louvain PR would give you the go/no-go signal on non-trivial extension points 😄

[Becheler]

Also, notes on namespace:

• the initial page rank lives in boost::graph namespace, you should probably use this too (i don't know if you're aware, but many algorithms in BGL actually pollute the boost namespace and we're trying to move things to boost::graph 😆 )
• if you need helpers, utils, details that are not part of the user API, you should use a namespace like boost::graph::personalized_page_rank_details::my_little_helper 😉

Notes on your proposed idea: I am not sure we want per-algorithm concepts (e.g. page_rank_optimizer_concept) if this can be captured by existing abstractions like visitors. Your instinct was super sharp though, because page_rank_optimizer_concept is basically a visitor 😉 But to make the design elegant, we must first decide of the discussion of visitors return-type, that is one of the BGL corner-stone. I will open a Discussion in the forum tomorrow.

Though, at the point they feel compelled to write something like this instead of using some out-of-the-box options, I believe they understand enough to not be harmful.

As I am slowly cleaning the 75 issues in the backlog, I must respectfully disagree with this statement 😆 More seriously, every user end up shooting their own foot if the library give them the opportunity. At some point someone will want to resize or insert in your vector thinking it's harmless. So we must have airtight interfaces they can not break 💪🏽

[maniospas]

It's likely a good place to uncover new design needs because these come a rather different set of needs compared to traditional graph algorithms by mixing -but not committing to- linear algebra patterns. 😄

What I am proposing, mind you, can be used as a starting point to cover an enormous space of spectral graph filters and near-linear time conductance-based structural communities, so it would be nice if it could fit in. Though you are probably right about the footgun. After thinking about it more, even a scaling factor can grant a surprising amount of control, and perhaps could also be a more generalized spectral graph filter scheme. I guess the patterns will appear somewhat by themselves once there is a first version in place.

But I digress, as this would be future work. For now, I will follow the plan of implementing the base schema:

void personalized_page_rank(g, p0, rank_map, weight, done, damping, n, rank_map2);

alongside weight maps for graph normalization and a default optimizer. Then done and an optimizer can be respectively switched or added as visitor patterns, depending on what ends up happening with the Louvain work (can you tag the respective issue so that I can follow discussion progress there?).

Since there is a need to choose a default without alternatives for optimization, I will go with L1 normalization instead as a starting point; it still solves serious convergence and numerical stability issues, and yields the same results under markovian edge weighting as if no normalization was applied (in this case, having the priors be equal and summing to one is the direct equivalent to non-personaized pagerank).

P.S. I did notice that new stuff was being moved under boost::graph indeed. If I encounter issues with development, I hope to be able to ask them here. Something I am not finding (which I guess is locked under a PR judging by how you linked the new PR guideline) is a contributor guide document. Also, it would have been nice if I was able to discover the new docs from the github readme, which again I am sure you are aware of (btw, since you asked, pagerank docs were very comprehensive).

[Becheler]

Amazing! 🚀

Spectral stuff seems its own beast, indeed, and anything related to linear algebra is an open discussion (feel free to open one on the subject by the way).

• You are absolutely welcome to use this issue to ask any question 👍🏽
• The contribution guide CONTRIBUTING.md lives on Adding and editing github plumbing files #489 , it's under review, feel free to comment, give your feedback and suggestion here 🤗
• The new documentation lives on Doc migration #491 waiting to be merged. What you saw was my personal fork, you can for now use the PR cppalliance bot preview that links to the previewed website.
• When these two PRs will be merged you will be able to access the documentation from the github readme and vice-versa
• I also would want to come up with a detailed guide on contributing algorithms (a CONTRIBUTING.md can not do-it-all) so we would really welcome your comments on this discussion Lowering contribution barrier #479 . Feel free to ask for anything you would like to have known/seen that would have lowered your friction 😄