Closed krivit closed 1 month ago
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.
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.
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.
@CarterButts , @martinamorris , @drh20drh20 , @kecoli thoughts?
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.
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
dyads
present
and absent
, if passed by name, raise an error for nonconforming networks.
The constraint simply takes the provided edgelist and fixes the corresponding dyads. It doesn't check if the edges in
present
are present, inabsent
are absent, and it doesn't modify the network such that they are. Passing an argument aspresent
has the exact same effect as passing it asabsent
.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?