Handling inactive time periods

[marion-hoffman]

In some cases, there might be periods of time in our data for which we know interactions cannot happen (ex: nights when analyzing face-to-face interactions, or out-of-office periods when looking at teams interactions).

I want to add an option to specify these periods, that treat events before and after the removed periods like if they were happening directly one after the other (basically ignoring the removed period) while still updating the windowed events (two actors who interacted just before the cut period are not considered as having just interacted after the cut period). Currently just removing the cut periods does not allow to have windowed events updated correctly.

I will add this option in the dynam-i branch (for all dynam models) and it can be reviewed and merged later to the main branch if anyone thinks it is useful. Let me know if there are additional requests related to this topic.

[marion-hoffman]

Maybe @stadtfeldethz and @jhollway , you can tell me whether you have a preference on how to include this functionality, if it is merged with the main later. Options are:

A: put it as an argument of the estimate function (ex: estimate(formula, ..., inactivePeriods = inactivePeriods) ).
B: create a function defineInactivePeriods that should be called when defining all the objects, which links the inactivePeriods object to the dependent events object, such that it can be retrieved in the estimation.

(It cannot be a part of the EstimationInit argument, because it should be used for the preprocessing too).

[jhollway]

Thanks @marion-hoffman for this! I'd rather avoid another function if we can help it. Why can't it be an argument for the function defining the dependent events though (option C)?

Also, what kind of format do you suggest for users specifying the inactive periods? Is this a vector or list? Character string or numeric? For regular inactive periods (e.g. every night), or irregular inactive periods?

[marion-hoffman]

So actually, I realized that now some parameters of estimationInit are actual parameters for the preprocessing. So I propose to put it there too, so basically the interface stays super simple, and it's only in special cases people can add something in estimationInit.

For now I put it as a list, each element has a "start" and an "end", which are the starts and ends of the periods when no dependent event can happen, and for now these starts and ends should be in seconds but if the events also take posix times I will adapt this. I think we should allow the same format for the start and end times as what we allow for the times in the events, and that people should be able to define them as precisely as possible.

[jhollway]

Agreed: some people have data at the day level (or more) of granularity rather than in seconds. Let's aim for a consistent offering across the user interface.