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

[CHU-DING LING via statnet_help]

Dear Carter,

Thank you very much for your detailed explanation and for your continued
support!

I apologize for asking questions that were not directly related to the sna
package. I appreciate your guidance on using the codes to determine the
appropriate beta value. I have tested this with the example matrix and my
own data, and it works perfectly.

I am also grateful for your insights on setting the beta value to explore
different scenarios. Your explanation has been incredibly helpful in
understanding how to approach this parameter when investigating various
research questions.

Thank you again for your time and expertise!

Best regards,
Chuding


Carter T. Butts via statnet_help <statnet_help at u.washington.edu>
于2024年9月4日周三 16:34写道：


> 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 liststatnet_help at u.washington.eduhttps://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$>

>>

> _______________________________________________

> statnet_help mailing list

> statnet_help at u.washington.edu

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

>

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