feat!: as_adjacency_matrix() no longer supports attributes of type character

[krlmlr]

For #907.

I see how it is useful to advance on that front. Running revdepchecks, if they succeed, I'll merge. Anything beyond that will have to wait until after 2.0.0.

[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 PR was merged using Aviator.

---

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]

Two packages have new breakages, I believe SCORPIUS is a false positive, but checking again.

There are two paths from here:

• We stop support for this functionality, and ask downstream to change their implementation
• We add a test for this functionality and keep supporting it

No urgency from my end.

[szhorvat]

It makes sense to stop support, as this can't be implemented in the C core, and its usefulness is dubious. Eventually all adjacency matrix stuff should rely on the C implementation.

That said, it would be fair to contact these packages and see why they are using this functionality, and whether it is easy for them to stop relying on it. I don't see any good reason for working with string-based adjacency matrices, but maybe I am missing something.

[krlmlr]

@sarahleavitt @schochastics @robertjankowski: The nbTransmission and signnet packages are using as_adjacency_matrix() with an edge attribute of type character. Is this on purpose, or perhaps a mistake? Can you work around so that your packages continue working with this PR?

Install with pak::pak("igraph/rigraph@f-907-adj-chr") .

[schochastics]

Just checked my usecase and I can work around this without issues. I will fix it in the next few days

[schochastics]

@krlmlr already fixed it. I will submit signnet 1.0.4 when CRAN submissions are online again

[szhorvat]

@schochastics I am interested in what your use case was an how you worked around it. Can you share it? Are you working with complex-values adjacency matrices, or complex-values attributes? Is this something that makes sense to support in C/igraph in the future? I'm primarily interested in the theory behind this, not the implementation.

[schochastics]

@szhorvat Sure! The technical details are in this paper.
When you project signed two mode networks, a third type of tie can occur (called the "ambivalent tie"). To support it in signnet, I use an edge attribute type with values "N", "P", and "A" and those get transformed to a complex adjacency matrix with P=1+0i, N=0+1i and A=0.5+0.5i. It was convenient to build it with as_adj(g, attr="type") and then convert "P" "N" and "A" entries to complex values, but it was trivial to work around this.

I would like to keep the "N", "P", and "A" nomenclature, because it is easier to understand for users and it is enough for most of the functionality of signnet. The complex matrix part is still very experimental but I think there are some other papers out there that work with complex adjacency matrices (in different context), so maybe it is something to support in future versions.

[sarahleavitt]

I just checked on this for my package and it is not an issue for me. I simply carried over a large dataframe as the dataframe for creating the edge list. I have removed the irrelevant columns and resubmitted my package with the changes. So, my use-case does not require a character edge attribute. Thank you, Sarah

…

________________________________ From: David Schoch ***@***.***> Sent: Saturday, January 6, 2024 8:13 AM To: igraph/rigraph ***@***.***> Cc: Sarah V. Leavitt ***@***.***>; Mention ***@***.***> Subject: Re: [igraph/rigraph] feat!: `as_adjacency_matrix()` no longer supports attributes of type `character` (PR #1072) @szhorvat<https://github.com/szhorvat> Sure! The technical details are in this paper<https://doi.org/10.1080/0022250X.2019.1711376>. When you project signed two mode networks, a third type of tie can occur (called the "ambivalent tie"). To support it in signnet, I use an edge attribute type with values "N", "P", and "A" and those get transformed to a complex adjacency matrix with P=1+0i, N=0+1i and A=0.5+0.5i. It was convenient to build it with as_adj(g, attr="type") and then convert "P" "N" and "A" entries to complex values, but it was trivial to work around this. I would like to keep the "N", "P", and "A" nomenclature, because it is easier to understand for users and it is enough for most of the functionality of signnet. The complex matrix part is still very experimental but I think there are some other papers out there that work with complex adjacency matrices (in different context), so maybe it is something to support in future versions. — Reply to this email directly, view it on GitHub<#1072 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADXLE5QOIO2DQ2V3SLF73RTYNFEYJAVCNFSM6AAAAABBKSFEASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZGY4DGNBSGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>