fix: added NA handling for matrix inputs

[schochastics]

Fix #917
Fix #918

This PR introduces an error message if inputs to

• graph_from_adjacency_matrix()
• graph_from_biadjacency_matrix()
• graph_from_edgelist()
• graph_from_data_frame()

contains NAs

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This pull request is currently open (not queued).

How to merge

To merge this PR, comment /aviator merge or add the mergequeue label.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[krlmlr]

Thanks, great! Should we do another round here?

[krlmlr]

Has conflicts too.

[szhorvat]

FYI I've been working on NaN passthrough for the adj. mat. functions in the C core, which would preserve NA values.

[schochastics]

FYI I've been working on NaN passthrough for the adj. mat. functions in the C core, which would preserve NA values.

@szhorvat Whats the use case you have in mind? Working with missing data? Is it still ok to kick it out here?

[szhorvat]

Original motivation was to support the R interface better. On the C side we don't try to distinguish between different types of NaNs, but if we pass through NaNs untouched, then the NaN/NA distinction survives for R. We don't have to do it if you don't think it's important.

If you do think it's useful, should should still go ahead with this PR. The requirements can be relaxed in the future, we can still do it.

[schochastics]

I think for now NAs should through errors. But I have been thinking about how to use NAs for missing values in network data (when data was gathered and there is non-response). It is a very practical, non graph-theoretic problem but important in SNA. I gotta check how people currently deal with it. But that is a task for a day when the interface is clean(ish)