Centrality Polarity
PortfolioOptimisers.DistancePolarity — Type
struct DistancePolarity <: AbstractCentralityPolarityDeclares that an algorithm's edge weights must be distances: small means closely related.
Every algorithm that walks a shortest path needs this polarity, because a shortest path minimises the sum of the weights along it. Over similarities the same routine seeks the route through the weakest links and returns a backwards answer without raising.
Supplied by calc_distance_weighted_graph, which carries distances on both branches.
Related
PortfolioOptimisers.SimilarityPolarity — Type
struct SimilarityPolarity <: AbstractCentralityPolarityDeclares that an algorithm's edge weights must be similarities: large means closely related.
An algorithm that reads the weighted adjacency matrix directly, rather than walking a path, needs the entry to grow with relatedness — a stronger link must contribute more.
Supplied by calc_weighted_adjacency_graph, and only on its similarity branch. The tree branch is selected by calc_mst minimising a distance and holds no similarity, so an algorithm declaring this polarity runs unweighted there.
Related
PortfolioOptimisers.centrality_polarity — Function
centrality_polarity(ct::AbstractCentralityAlgorithm)
centrality_polarity(ct::Union{<:BetweennessCentrality{<:Any, <:Any, Nothing},
<:ClosenessCentrality{<:Any, <:Any, Nothing},
<:StressCentrality{<:Any, <:Any, Nothing},
<:RadialityCentrality{Nothing}})
centrality_polarity(ct::Union{<:BetweennessCentrality{<:Any, <:Any, TopologyOnly},
<:ClosenessCentrality{<:Any, <:Any, TopologyOnly},
<:StressCentrality{<:Any, <:Any, TopologyOnly},
<:RadialityCentrality{TopologyOnly}})
centrality_polarity(ct::EigenvectorCentrality{Nothing})
centrality_polarity(ct::EigenvectorCentrality{TopologyOnly})Answer which quantity a centrality algorithm's edge weights must be.
The extension contract of AbstractCentralityPolarity. centrality_graph reads it to decide what to weight the network with.
The answer is the effective polarity, not the declared one
A TopologyOnly in the algorithm's ov field withdraws the declaration, so this function answers nothing and the caller gets the plain graph. The override is resolved here rather than at the call site, because three algorithms carry no ov field at all and an inline read of ct.ov cannot be written for them. So this function keeps predicting the graph that centrality_graph builds, which is the property that makes it worth exporting.
The fallback declares nothing, so opting in is explicit
The method on AbstractCentralityAlgorithm returns nothing, which routes to the plain unweighted graph. A new algorithm therefore runs unweighted until it says otherwise, which is the safe default: a wrong polarity does not raise, it silently reverses the ordering the algorithm is reading.
What the shipped members declare, and why
DistancePolarity—BetweennessCentrality,ClosenessCentrality,RadialityCentrality,StressCentrality. All four are defined over shortest paths.SimilarityPolarity—EigenvectorCentrality. It is the leading eigenvector of the adjacency matrix itself, so a larger entry must mean a stronger link.nothing—DegreeCentrality,Pagerank,KatzCentrality.Graphs.jlcannot use weights in any of the three: the first two ignore them, andGraphs.katz_centralitybinarises throughadjacency_matrix(g, Bool)and throws anInexactErrorwhen handed a weighted graph.nothing— any of the first five carryingov = TopologyOnly(). Those five are the only ones that carry the field, because the other three already answernothingand have nothing to withdraw.
The line between the first two groups and the third is Graphs.jl's own. The declaration is about correctness — which weights — and the absence of one is about capability.
Arguments
ct: Centrality algorithm.
Returns
polarity::Option{<:AbstractCentralityPolarity}: The effective polarity, ornothingfor an algorithm that cannot read weights or has withdrawn its declaration. Each method returns one concrete type, never aUnion.
Related