Hi -
When running igraph 2.1.4.9055 I’m finding a new behavior where NAs on the diagonal of an adjacency matrix now return an error (never used to). Is this known/deliberate behavior?
Thank you!
This is deliberate. @schochastics can say more.
How would you prefer the NAs to be handled here, for your use case?
Thanks for responding, appreciate it!
I think ignored as it was in prior sets would be our preference - as we include it upstream in ensuring there are no unexpected self-loops. But we can hard-code that situation to 0s on the diagonal simply enough. Just as this had shifted from prior versions (i.e. threw a new error when we compiled our package vignette), we wanted to make sure that it wasn’t a bug.
Just some background: This was deliberately introduced. One of many reasons is that it is unclear how to interpret NAs correctly. In the cases I could look at (usage in other cran packages), NAs were never explicitly used but rather erroneously appeared and were meant to be zeros. This also seems to be your use case: NAs interpreted as 0? May I ask which package you are referring to?
That being said, we are still deliberating if or how this will hit CRAN.
1 Like
In the C layer, I wouldn’t want to implement ignoring NAs. I would prefer to not have any R specific code in C and R’s NAs are encoded as one type of NaN. Ignoring NaNs (as opposed to NAs) is something I definitely wouldn’t do.
In the longer term, the C core might become capable of passing through NaN values unchanged, meaning that the specific NaN representations are preserved. Thus it would stay a proper NA in R, and show up like that in the edge weight vector. If other languages, such as Julia, also use certain NaN encodings for special purposes, that would be preserved as well. Doing this would likely break the old behaviour (which was never guaranteed!) thus it’s better to go through a transition phase where the use of NAs raises an error.
The package we have is IDEANet - it’s a tool we’re building out to help novice & applied users use network analysis.
For us, it was “NA” as confirmation for no self loops (i..e not a general feature anywhere else but the diagonal). Again, simple enough to switch around and I don’t recall why we went this route initially.
Ah yes I checked that package. Given that you are ahead of timeline, I think you should have enough time to change this. We wanted to discuss tomorrow how we handle this situation in general. Best case is that all maintainers fix it like you did!