Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Resource monitoring: before or after seize/release #28
This is just a reminder for me to think about it, but also a discussion forum for throwing pros/cons and, eventually, deciding. Wrapping up:
Let's bring some code to the discussion. This is what we are doing now:
mutate(mean = cumsum(value * diff(c(0,time))) / time)
And I recovered what we were doing when monitoring was performed after:
mutate(mean = c(0, cumsum(head(value,-1) * diff(time)) / tail(time,-1)))
So the reengineering consisted of removing the last observation!
What would be the expected/desired output in this case? Currently it returns:
Intuitively I would expect one row were finished is
Arrival reporting is executed when an arrival leaves the trajectory: because 1) it has reached the end or 2) it was rejected. In this case, the arrival is requesting 2 units when the resource has only 1, so the arrival will be enqueued forever. But it has not finished its lifetime, so nothing is reported.
This is a consequence of the very flexibility that the trajectory-based seize/release system offers: the programmer is responsible for creating well-formed trajectories, and simply this is not.
referenced this issue
Dec 8, 2015
After giving much thought, I think that probably you are right: the user would expect an observation to be the snapshot of that instant, not of the last interval. The definitive argument that I've found in favour of your point is the behaviour of
So, I'll perform the monitoring after, starting from the next release. This requires a minor version change and a careful explanation.