gw*() terms no longer actually need fixed= parameter.

[krivit]

It used to be that in terms such as gwesp() in curved mode, we would specify the initial parameter value in the term and then set fixed=FALSE (or leave it blank, since it's the default), e.g., gwesp(.2). This is no longer needed, nor is a valid way to specify initial parameter value. In fact, it issues a warning:

library(ergm)
data(faux.mesa.high)
summary(faux.mesa.high~gwesp(.5))
#> Warning: In term 'gwesp' in package 'ergm': When 'fixed=FALSE' parameter
#> 'decay' has no effect. To specify an initial value for 'decay', use the
#> 'control.ergm()' parameter 'init='.

The decay parameter is passed if and only if fixed=TRUE. And so, why not infer the fixedness from the parameter?

1. If decay= is passed, fixed=TRUE is assumed.
2. If decay= is NULL, fixed=FALSE is assumed.
3. Passing fixed= directly is deprecated and then removed.

To summarise, gwesp() or just gwesp fits a curved model, whereas gwesp(.2) fits a fixed model.

For a softer transition, we can set the default for fixed= to NA (i.e., infer from decay=), so that code that's not too old still works. After a few releases, we could remove fixed= altogether.

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

[krivit]

As an alternative, we could deprecate the decay= parameter instead and use fixed= to specify the value, e.g., gwesp() vs. gwesp(fixed=.2).

[handcock]

Hi Pavel:

i like you original suggestion. The curving is used less often and so the simpler notation is helpful to new users. It will mean older code will be altered, but hopefully most use fixed=TRUE when they mean it.

[mbojan]

I'm for the first option, i.e. keep decay and deprecate fixed.

For completeness, what's the current way of specifying the starting value for decay for the curved model?

[krivit]

I'm for the first option, i.e. keep decay and deprecate fixed.

For completeness, what's the current way of specifying the starting value for decay for the curved model?

control = control.ergm(init=...), with NAs set for the elements whose initial values are to be determined by MPLE, CD, etc..

[CarterButts]

I think fixed=TRUE needs to be left in indefinitely.  It's been a standard for *years*, and a ton of code is going to be broken if that is taken out.  Moreover, it can just be silently ignored, so it doesn't do any obvious harm.  Unless there is a very pressing reason to remove it (it sounds like there isn't, other than generic cleanup), I vote for the general principle of *don't break user code.*  (Or developer code, for that matter.)  Ideally, statnet code written today ought to run 30 years from now, and we should only undermine that goal when there's really no viable alternative.  Sometimes, there isn't, but it doesn't sound like this is one of those times....

…

On 6/4/23 2:57 PM, Pavel N. Krivitsky wrote: I'm for the first option, i.e. keep |decay| and deprecate |fixed|. For completeness, what's the current way of specifying the starting value for |decay| for the curved model? |control = control.ergm(init=...)|, with |NA|s set for the elements whose initial values are to be determined by MPLE, CD, etc.. — Reply to this email directly, view it on GitHub <#532 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJM3GB75TTESR7FMGFQXXLXJUAEPANCNFSM6AAAAAAYZT5YEE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[krivit]

@CarterButts , point well taken. I am less reluctant to break things, since all older versions of ergm are available, and as our algorithms evolve, so will the arguments. For example, ergm(nw~gwesp(.1) already behaves differently between pre-4.0 and post-4.0 versions, because pre-4.0's initial decay parameter can be set in control.ergm(init=) vector. We also have a mechanism for globally telling terms to emulate behaviour from prior versions (e.g., control.ergm(term.options=list(version="3.4"))), though that requires implementing the backwards compatibility within the term.

[drh20drh20]

I took Carter's main point to be that there ought to be a strong reason for breaking code, or it shouldn't be done. I fully agree. What's the upside of the proposed change, other than getting rid of the warning? (Is that even an upside? Without the warning, isn't there a danger that someone will unknowingly misuse the term?)

[krivit]

The upside is streamlining the user interface.