-
-
Notifications
You must be signed in to change notification settings - Fork 42
Resource monitoring: before or after seize/release #28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
my 2¢ the end user should have access to all activity stats (this includes the last observation). imo this puts us in the after scenario (where some reengineering has to realign the vectors). |
On the other hand, one could argue that the after scenario deprives the user of the first observation... 😉 |
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! 😄 |
indeed 😬 something related:
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. |
I understand the reasoning behind it, just adding to the discussion (trying to speak from the side of the end-user 😃 ). |
This is interesting as a separate question (#36 opened), but I think it is not important for this discussion (the resource will never be seized). |
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. |
great 👍 |
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:
The text was updated successfully, but these errors were encountered: