Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixedas(present, absent) constraint does not actually ensure edges are present or absent. #572

Closed
krivit opened this issue Jul 18, 2024 · 6 comments

Comments

@krivit
Copy link
Member

krivit commented Jul 18, 2024

The constraint simply takes the provided edgelist and fixes the corresponding dyads. It doesn't check if the edges in present are present, in absent are absent, and it doesn't modify the network such that they are. Passing an argument as present has the exact same effect as passing it as absent.

It was originally implemented by Kirk Li in response to a ticket by @CarterButts (https://github.com/statnet/ergm-private/issues/49), so the question is, what do we do with it?

@krivit
Copy link
Member Author

krivit commented Jul 20, 2024

One option would be to add another argument in front, e.g., fixed.dyads, which doesn't get checked, then if the user passes present or absent by name we check for presence and absence on initialisation and errors out if violated. In principle, we could come up with a mechanism to bring the LHS network into conformance with the constraint, but that requires developing a whole new API.

krivit added a commit that referenced this issue Jul 20, 2024
… fixes the dyads. Both fixedas() and fixallbut() constraints now warn when given a network whose size does not match the LHS network's.

references #572
@martinamorris
Copy link
Member

I guess I'm not sure what the use case is here. Was the goal to constrain some dyads to their initial values, and allow others to be toggled? Or was it supposed to fix some dyads' statuses to present/absent and allow others to be toggled.

@krivit
Copy link
Member Author

krivit commented Jul 20, 2024

The main use case is to fix (i.e., condition on) a specific set of dyads at their initial values. I don't know if anyone has relied on the present/absent functionality---in which case they would get incorrect results.

@krivit
Copy link
Member Author

krivit commented Aug 18, 2024

@CarterButts , @martinamorris , @drh20drh20 , @kecoli thoughts?

@martinamorris
Copy link
Member

I don't have strong feelings about this -- but unless there's a strong use case made for the present/absent arguments, it seems easiest to deprecate them and just use this constraint for setting a passed edgelist to the observed values.

@krivit
Copy link
Member Author

krivit commented Sep 29, 2024

Since there isn't currently an API for a constraint to modify the network, the most it can do anyway is to raise an error. So, I guess the best I can do is

  • add an argument dyads
  • have present and absent, if passed by name, raise an error for nonconforming networks.

@krivit krivit closed this as completed in c982534 Sep 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants