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

Drop gw*() terms' cutoff= argument in favour of the term.option? #533

Open
krivit opened this issue Jun 5, 2023 · 1 comment
Open

Drop gw*() terms' cutoff= argument in favour of the term.option? #533

krivit opened this issue Jun 5, 2023 · 1 comment

Comments

@krivit
Copy link
Member

krivit commented Jun 5, 2023

This is loosely related to #532. Since #485, cutoff= behaviour for gw*() terms when encountering a network whose statistic of interest (degree, SP, etc.) exceeds the cutoff is to stop immediately with an error (as opposed to silently returning incorrect results).

cutoff is set in one of two ways: as an argument to the term, (e.g., gwesp(cutoff=50)) or as a term option, which can, in turn, be set as a control parameter (e.g., control.ergm(term.options=list(gw.cutoff=50))) or as a global option for all subsequent runs (e.g., options(ergm.term=list(gw.cutoff=50))).

I wonder if as a part of a general term cleanup, it might make sense to deprecate cutoff= argument as well, to rely on the global setting. This has two possible benefits:

  1. Cleaner calls, e.g., gwesp(.1, type="OSP") becomes gwesp(.1, "OSP"), though type= is still required if decay is not given (though we could handle that too, if we anted to).
  2. Encouraging to separate "what to fit" from "how to fit it": the model ergm() would actually when the observed or simulated network feature of interest exceeded cutoff were always poorly defined, and now it will refuse to fit them at all, so cutoff is not a part of the model specification but a computational tuning setting like MCMC sample size.

@drh20drh20 , @handcock , @mbojan , @sgoodreau , @CarterButts , @martinamorris ?

@sgoodreau
Copy link
Contributor

I don't have a strong opinion on this one. I see the benefit of the cleanup, but also the downside of breaking code. That said, in general I lean more than @CarterButts does towards accepting some long-term breaking for the value of cleaning, especially when it involves features that I suspect are not that commonly used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants