Refactor observe_process function

[athowes]

New plan

• Create add_event_vars function to add upper and lower given either lower and window or lower and upper
• Enforce our names structure which is ptime_lwr and ptime_upr (i.e. change the names)
• Find a way to slot the back into existing functionality so as not to break anything for now

Old

I've just used observe_process(). Some notes on possible refactor:

• The name "observe process" is vague and seems misleading for what it is doing. For my understanding, what it is doing is implementing interval censoring. If so, the name should reflect that.
• If it is implementing interval censoring, then I think that there should be arguments available for specifying the censoring intervals. At the moment it looks like it's just using daily intervals, and some kind of fixed upper and lower.

[seabbs]

I think its implementing the observation process which in this instance is censoring but agree it can be renamed.

FYI I think this should be organised under some kind of simulation label (as this is part of the simulation/validation code) - in general if we start organising issues like this it may help us gain some clarity around what is happening

[athowes]

Even in this instance I'd think of the observation process as having multiple stages, including but not limited to censoring. I think having functions to modularly implement each part of the observation process would be nice.

[seabbs]

Yes agree

[athowes]

As a part of this issue, I propose to:

• rename observe_process() to something to represent interval censoring,
• include arguements for the intervals to be used,
• create unit tests for the function,
• fill out the roxygen2 documentation for the function.

[athowes]

As a part of this issue, I propose to:
* [ ] rename observe_process() to something to represent interval censoring,
* [ ] include arguements for the intervals to be used,
* [ ] create unit tests for the function,
* [ ] fill out the roxygen2 documentation for the function.

I am now working in this direction.

[athowes]

Note on implementation:

• I think we should be using .floor_mult here to round down to the nearest multiple of x
• I guess there is a question about whether people are censoring their data or they are taking already censored data and adding some columns. Maybe it just works the same either way...
• I think we should be letting users input x
• Probably we can let there be different censoring windows used for primary and secondary
  • Then I think we can re-use the names pwindow and swindow for the sizes of these
• I don't know why we have _daily as new columns. If I just delete these does it do anything? Use code search to find all instances of _daily

[athowes]

I've drafted a function that would look like this:

observe_process <- function(linelist, pwindow = 1, swindow = 1) {
  assert_numeric(pwindow, lower = 0)
  assert_numeric(swindow, lower = 0)
  
  linelist |>
    mutate(
      ptime_lwr = .floor_mult(.data$ptime, f = pwindow),
      ptime_upr = .data$ptime_lwr + pwindow,
      stime_lwr = .floor_mult(.data$stime, f = pwindow),
      stime_upr = .data$stime_lwr + swindow,
      delay_lwr = pmax(0, .data$stime_lwr - .data$ptime_lwr - 1),
      delay_upr = .data$delay_lwr + pwindow + swindow
    )
}

If users provide data where stime and ptime are already censored to the lower bound then this would do nothing and add the upper bounds.

I'm also interested as to why in the original code the upper bound for the delay was the lower bound plus one. Isn't this wrong? The upper bound should be plus two?

[athowes]

Expanding upon

if users provide data where stime and ptime are already censored to the lower bound then this would do nothing and add the upper bounds.

then I think we can do two things with this function:

1. Add the upr columns needed for input into future model functionality to data that already is censored to the lower
2. Add the lwr and upr columns to data that has no censoring

Things to be worried about here:

• What if data are censored to the upper? This would seem weird to me

[athowes]

To me, the function should also be renamed. I am thinking of it as a "add censoring" function, which might exist as some part of a more modular observation process collection of functions. As I write above, I think this function can also be used within preprocessing for data that are censored but don't have the windows in the data.frame.

add_censor_columns is a example bad name from the top of my head to show where I am thinking about going with this.

[athowes]

Tag @seabbs for comment on above before I begin working on PR #352 again (don't want to go off in wrong direction).