make tergmLite use ergm terms

[chad-klumb]

It appears to me that tergmLite could be made to use ergm terms with relatively minor modifications to each.

Specifically, tergmLite will need to call the relevant InitErgmTerm function when updating term inputs (rather than the currently used updateInputs_termname function), and should allow default argument settings to be handled by check.ErgmTerm (rather than get_formula_term_args_in_formula_env, which currently sets defaults in tergmLite).

ergm will need to make these InitErgmTerm functions available (exporting them, or exporting a function that can call them), and will also need to accommodate networkLite representations of network data in the relevant portions of ergm. The latter can be accomplished by replacing calls to network accessors (like %v%, %n%, is.directed, is.bipartite, network.size, network.dyadcount, etc.) with calls to generic functions that can dispatch to network methods or appropriate networkLite analogues. These changes need to be made in check.ErgmTerm and the relevant InitErgmTerm functions. Such changes should not affect ergm's behavior on network objects, but should open up the modified parts of ergm to other network data representations (including networkLite objects).

I have made changes along the above lines to tergmLite and ergm and will be pushing those to new branches (rather than forks, per request) shortly for scrutiny, testing, and discussion. I have defined a (minimal) nds API (nds = network data structure or network data storage) which defines the generic accessors, and placed those definitions in ergm (for the time being), along with the network class methods. The networkLite class methods are in tergmLite, which also houses a trivial networkLite constructor.

Loosely related are term updates in EpiModel (which will also be placed in their own branch). I would recommend getting the updated (branch) versions of all three packages if testing. Incidentally, if we agree to these changes, EpiModel and tergmLite will need their ergm version dependencies updated to whatever the version of ergm is after these changes are made.

For now tergmLite will only support the terms it already did, but those terms will use the corresponding InitErgmTerm function. More ergm terms could be opened up to tergmLite relatively easily after these changes (just change the accessors in InitErgmTerm, and change the list of allowed terms in tergmLite).

I think these changes bring up many questions, like how closely ergm should be tied to network, and whether we should define a more complete template class or API for network data representations that can be plugged into ergm. My guess is that some parts of ergm will be easier to make "generic" than others, but even if these changes don't go beyond the terms themselves, I still think it's worth the effort to make things more flexible.

[chad-klumb]

build errors appear related to nlme version

apparently a similar thing happened a few years ago (might have some ideas for fixing):

travis-ci/travis-ci#5756

[krivit]

I've already put this in a commit comment, but just to make sure everyone gets the message, this is not a good idea, and someone should have checked with me before starting to implement this. We are already in the process of making the network package methods generic, so efforts should be directed there and not into the nds_* functions.

[krivit]

@CarterButts , @martinamorris , @smjenness

[chad-klumb]

Okay, I can try to make changes in network instead.

The nds thing was just my way of thinking about generalizing access to network information, which I think we do want to do. I didn't know it was already underway in network.

We will still need to make InitErgmTerm functions available to tergmLite though.