[statnet_help] Assistance with Calculating Degree Centrality in Directed and Valued Networks Using the sna Package in R

[Carter T. Butts via statnet_help]

Hi, Chuding -

On 9/3/24 9:28 PM, CHU-DING LING wrote:

>

> Dear Carter,

>

> Thanks again for your suggestions. I have some further questions 

> regarding inconsistencies between the Bonacich’s power centrality 

> (Beta centrality) from *igraph* and *sna* for an undirected and valued 

> network. Enclosed please find the example codes and the associated 

> annotations. Despite setting the ‘exponent’ and ‘rescale’ parameters 

> consistently between the two packages, I am noticing some 

> discrepancies in the results.

>

I'm afraid that I can only answer questions about statnet tools, so I 
can't help you there.  If you have a question about a specific 
calculation done by sna, I can answer that.  But I can't speak to what 
some other package may or may not be doing, and thus why it gives 
different results.


> I have a couple of questions which I was hoping you could help with:

>

> *1. How can we get the highest beta value before calculating 

> Bonacich’s power centrality?*Currently I use another unpublished 

> package to obtain the value. I would like to understand the process or 

> any specific considerations required to obtain the highest beta value 

> with *sna* or *igraph*.

>

I don't know what you mean by "the highest beta value."  If you define 
the power centrality in terms of a feedback process (as one, I think, 
probably should in most cases), /any/ scalar can serve as a beta value 
(so there is no maximum); however, not all lead to convergent results.  
One thus typically confines interest to |beta| < 1/rho, where rho is the 
spectral radius of the input matrix, which ensures convergence.  
(Substantively, non-convergent cases would correspond to runaway power 
growth, so we are implicitly assuming here that we are seeing the steady 
state of a feedback process that has converged to a fixed point.) 
Anyway, you can get that with something like

1/max(Mod(eigen(MyMat)$values))

Which, in your example, is about 0.1026.  Note that you can't find a 
unique largest beta value for which convergence is guaranteed, because 
this is an open interval - but in practice, anything close to the limit 
will give you approximately the same answer.

I note that, as beta -> 1/rho from below, the bonpow scores converge to 
the principal eigenvector (where one exists), up to a scaling 
coefficient (which can be negative, though this does not change the 
substantive interpretation since the eigenvector is invariant to a sign 
flip).  Pragmatically, this means that bonpow is equivalent to 
eigenvector centrality for positive beta near the inverse spectral 
radius.  This leads to a number of wonderful insights (to which I 
subject the students in my theory class), but a not-so-exciting one is 
that there's not really much /practical/ value in using bonpow with a 
large positive beta - cleaner to just use eigenvector centrality 
(because that's what you are approaching as you increase beta), and then 
not have to worry about whether you're within the spectral radius.  
Bonpow only starts to get interesting when beta is small (leading to a 
much flatter spectral weighting, which allows smaller core-periphery 
structures to start to matter) or negative (which puts relatively more 
weight on bipartitions).  But that's another topic....


> *2. How can we achieve consistent results between ‘igraph’ and 

> ‘sna’?*Despite aligning the ‘exponent’ and ‘rescale’ parameters across 

> both packages, the results still differ. Are there any additional 

> parameters or factors I should consider to ensure the outputs are 

> consistent?

>


Again, I can't speak to the behavior of other, non-statnet software.  I 
note that in your notes to refer to that package as returning constant 
values on your test case, which might suggest that you didn't tell it to 
use your edge values (your network returns unit results if one 
dichotomizes it).  But you'll want to look to their documentation and 
code to see what is being computed.

Hope that helps,

-Carter


> I would greatly appreciate any guidance or insights you could provide 

> on these matters.

>

> Thank you for your time and assistance.

>

> Best regards,

>

> Chuding

>

>

>

> Carter T. Butts via statnet_help <statnet_help at u.washington.edu> 

> 于2024年8月30日周五 16:00写道：

>

>     Hi, Chuding -

>

>     Glad that fixed it.   With respect to edgelists vs. adjacency

>     matrices, they will give you equivalent results.  If you seem to

>     be getting different results, check the two objects: somewhere in

>     your code, you've presumably made them non-equivalent....

>

>     Best,

>

>     -Carter

>

>     On 8/26/24 5:59 AM, CHU-DING LING wrote:

>>

>>     Carter,

>>

>>

>>     Thank you for your suggestions! The problem has been resolved.

>>

>>     Initially, I imported a matrix from a CSV file and stored it as a

>>     matrix class object. I then converted it into a network class

>>     object since many functions in *sna* require objects to be of the

>>     network class. However, I noticed that the edge weights were lost

>>     during the conversion from the matrix object to the network

>>     object, which caused the results from the degree() function not

>>     to account for edge weights.

>>

>>     Actually, the degree() function can directly handle the matrix

>>     object. I also used as.sociomatrix.sna() to convert the original

>>     matrix object into another matrix object with a different name.

>>     Both approaches produced the same degree centrality results for

>>     the directed and valued network.

>>

>>     I also experimented with the as.edgelist.sna() function to

>>     convert the original matrix object into an edgelist object.

>>     However, when I calculated the degree centrality of this object,

>>     it produced incorrect results, with a greater number of elements

>>     than the number of nodes in my network. I appreciate if you can

>>     give some insights on this issue.

>>

>>     Thanks in advance!

>>

>>     Chuding

>>

>>

>>     Carter T. Butts via statnet_help <statnet_help at u.washington.edu>

>>     于2024年8月25日周日 05:15写道：

>>

>>         H, Chuding -

>>

>>         The degree() function already exploits edge values; this is

>>         its default behavior.  If you wish to /ignore/ edge values,

>>         you need to set the "ignore.eval" argument to TRUE.

>>

>>         If you are not getting valued degree calculations from

>>         degree() using the defaults, then you are not passing it

>>         valued data.  This may be due to a preprocessing error (so

>>         check your inputs). Another possible failure mode is that you

>>         are passing it a network object that has value information

>>         stored as an edge attribute, and are expecting degree() to

>>         use those edge values. Since a network object can have any

>>         number of edge attributes (or none at all), and they can be

>>         of any data type (i.e., not necessarily numeric), degree()

>>         can't automagically know what is intended in that case, and

>>         will therefore treat the data as unvalued.  An easy way to

>>         use edge attribute information is to wrap your object in a

>>         call like

>>         as.edgelist.sna(<mynet>,attrname=<whateveredgeattributeIwanttouse>),

>>         which will extract from the object the specific valued

>>         network that you want to analyze.  That's especially handy if

>>         you have several different edge values you want to store in

>>         the same network object.  Of course, you can also use that

>>         same trick to make a "working" edgelist at the top of your

>>         script that you reuse for multiple calculations.  (The same

>>         can be done with adjacency matrices rather than edgelists, if

>>         one prefers.  See e.g. ?as.sociomatrix.sna.)

>>

>>         Hope that helps,

>>

>>         -Carter

>>

>>         On 8/23/24 9:07 PM, CHU-DING LING via statnet_help wrote:

>>>

>>>         Dear all,

>>>

>>>         I hope this message finds you well. I am currently working

>>>         on a project that involves social network analysis using the

>>>         *sna* package in R. I am reaching out to seek your expertise

>>>         on a particular issue I have encountered regarding the

>>>         calculation of degree centrality in directed and valued

>>>         networks.

>>>

>>>         I am working with a directed network where edges have

>>>         associated weights. My goal is to accurately calculate both

>>>         the in-degree and out-degree centrality of nodes while

>>>         considering the edge weights. I attempted to calculate the

>>>         degree centrality using the degree function in the *sna*

>>>         package. While this function works well for unweighted

>>>         networks, I realized that it does not account for edge weights.

>>>

>>>         Could you please advise on the best method or function

>>>         within the *sna* package to accurately calculate the degree

>>>         centrality in this context? Though I can make it with

>>>         *igraph* or other packages, I am particularly interested in

>>>         whether *sna* could directly handle weighted edges in

>>>         directed networks.

>>>

>>>         Your guidance would be invaluable, and I would greatly

>>>         appreciate any suggestions or resources you might be able to

>>>         provide. Thank you for your time and consideration. I look

>>>         forward to your insights.

>>>

>>>         Best,

>>>

>>>         Chuding

>>>

>>>

>>>         _______________________________________________

>>>         statnet_help mailing list

>>>         statnet_help at u.washington.edu

>>>         https://urldefense.com/v3/__http://mailman13.u.washington.edu/mailman/listinfo/statnet_help__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Npw4CFqLg3mWAfPesSBtoa6UjvVqK_t7JYrixPsjqKAxzUTjhOvoeAxG6tO4iWruplppJ7ZQGd8FOLXV8VLxBP8-nfnt$  

>>         _______________________________________________

>>         statnet_help mailing list

>>         statnet_help at u.washington.edu

>>         http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

>>         <https://urldefense.com/v3/__http://mailman13.u.washington.edu/mailman/listinfo/statnet_help__;!!CzAuKJ42GuquVTTmVmPViYEvSg!K6AnX5T7ncI4niN0TJ-TlovKAm3m3t5-Q3ZLpsyePCkGVbHm5aIUd8RF7svulqI3hJGWibMjch4bTC5nxZg$>

>>

>     _______________________________________________

>     statnet_help mailing list

>     statnet_help at u.washington.edu

>     http://mailman13.u.washington.edu/mailman/listinfo/statnet_help

>     <https://urldefense.com/v3/__http://mailman13.u.washington.edu/mailman/listinfo/statnet_help__;!!CzAuKJ42GuquVTTmVmPViYEvSg!J8esjxeWL9ZAUgoyxxZZfvYotyuBCgbBZNSJeVH6tBpbx7Uon79o89j104HewkpHj9e90P3SlHKEwdKZymQ$>

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/statnet_help/attachments/20240904/9f8fcbd6/attachment-0001.html>