# R: Missing weight for eigen\_centrality() **URL:** \ **Category:** Usage\ **Tags:** R\ **Created:** [20 March 2020 06:03 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144 "2020-03-20T06:03:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![cccfran](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/cccfran/32/159_2.png) [@cccfran](https://igraph.discourse.group/u/cccfran)\ **Post date:** [20 March 2020 06:03 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144/1 "2020-03-20T06:03:22Z")
How does eigen\_centrality() handle missing weights when using the weight option? Does it treat NA as 0? Thanks. ---
**Author:** ![vtraag](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/vtraag/32/38_2.png) [@vtraag](https://igraph.discourse.group/u/vtraag)\ **Post date:** [26 March 2020 13:42 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144/2 "2020-03-26T13:42:07Z")
This question turned out to be more difficult than I imagined. In principle the vector gets passed on to the C core or `igraph`. It is not immediately clear to me what `NA` from R is translated to in C, apparently R uses a [separate representation](https://cran.r-project.org/doc/manuals/R-exts.html#Missing-and-IEEE-values) of `NA` (i.e. different from `NaN`). When reading through the code though it seem as if the check on `NA` is not done correctly: ```auto if (!is.null(weights) && any(!is.na(weights))) { weights <- as.numeric(weights) } else { weights <- NULL } ``` What seems to be required instead is `all(!is.na(weights))` or `!any(is.na(weights))`. I believe this is an error. Could you confirm this @Gabor? Or am I overlooking something here? ---
**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\ **Post date:** [26 March 2020 16:42 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144/4 "2020-03-26T16:42:12Z")
Does the R interface pass on the binary representations of `NA` to the C core as-is? @vtraag you are saying that NAs are detected and the weight vector changed appropriately, right? (Not just passed on.) On the types of CPUs we use, the “NaN” value has more than one possible representation. My understanding is that R uses a specific NaN representation for `NA`. If this is so, and if the binary representation were passed to C as-is, then as far as the C core is concerned, all `NA`s would really just be NaNs. IMO that would make no sense—it should not be allowed. > [@vtraag](#): > > What seems to be required instead is `all(!is.na(weights))` or `!any(is.na(weights))` . I believe this is an error. What you say makes sense to me _but I am not experienced with R at all_. ---
**Author:** ![vtraag](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/vtraag/32/38_2.png) [@vtraag](https://igraph.discourse.group/u/vtraag)\ **Post date:** [26 March 2020 18:52 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144/5 "2020-03-26T18:52:49Z")
AFAIK, the `weight` vector was intended to be set to `NULL` if any of the values are `NA`. This should be corrected in the R interface (it can be easily corrected in the `types-R.def` file I believe). I’m not exactly sure what the representation of `NA` is, but indeed R seems to use a specific `NaN` value for representing the `NA` value of R. In the translation from R vectors to `igraph_vector_t` (done by `R_SEXP_to_vector`) no translation of any values occur at all. In other words, as it is now the specific value of `NA` gets passed to the igraph C core, which indeed does not make any sense. We do not perform any checks on this in the C core either by the way. ---
**Author:** ![cccfran](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/cccfran/32/159_2.png) [@cccfran](https://igraph.discourse.group/u/cccfran)\ **Post date:** [29 March 2020 04:55 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144/6 "2020-03-29T04:55:38Z")
I agree that results with weights containing any NA are totally nonsense if NAs are just NaNs (there is a table on [here](https://teuder.github.io/rcpp4everyone_en/240_na_nan_inf.html) summarizing the corresponding c++ type for NA in Rcpp. Rcpp does interpret NAs as NaNs for doubles but for the raw c interface the conversion does not seem to be documented). > [@vtraag](#): > > AFAIK, the `weight` vector was intended to be set to `NULL` if any of the values are `NA`. This should be corrected in the R interface (it can be easily corrected in the `types-R.def` file I believe). > > I’m not exactly sure what the representation of `NA` is, but indeed R seems to use a specific `NaN` value for representing the `NA` value of R. In the translation from R vectors to `igraph_vector_t` (done by `R_SEXP_to_vector`) no translation of any values occur at all. In other words, as it is now the specific value of `NA` gets passed to the igraph C core, which indeed does not make any sense. We do not perform any checks on this in the C core either by the way. If that’s the case, I will open an issue on rigraph repo. ---
**Author:** ![tamas](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/tamas/32/1261_2.png) [@tamas](https://igraph.discourse.group/u/tamas)\ **Post date:** [8 October 2021 22:12 UTC](https://igraph.discourse.group/t/r-missing-weight-for-eigen-centrality/144/7 "2021-10-08T22:12:49Z")
> [@vtraag](#): > > AFAIK, the `weight` vector was intended to be set to `NULL` if any of the values are `NA` . This should be corrected in the R interface (it can be easily corrected in the `types-R.def` file I believe). Sorry for resurrecting an old thread, but I think this definitely _wasn’t_ the intention. It is way too easy to accidentally introduce a `NA` value in a numeric vector in R; also, it is pretty commonplace to use `NA` as a placeholder for unknown values. Numeric weight vectors (potentially containing thousands of values) should not be silently ignored if there is a `NA` value somewhere in the middle; I think that the correct behaviour in this case is to convert `NA` to `NaN` when transferring them over to the C layer, and make the C layer handle them accordingly (or blow up with an error if the C layer cannot handle them).