Open glopesdev opened 1 year ago
This should preferably be done always on the input side (rather than output side)
for reference:
Timestamping of state transitions has been solved at the moment for the very specific case of patches, but the rest of the issue remains valid for all environment states in general.
Foraging patches can have their parameters updated due to either intrinsic or extrinsic events.
The most common source of events in the current task is extrinsic due to distance travelled crossing a threshold, and we would like to know both for analysis and debugging purposes what is the exact sample that caused this threshold to be crossed. Right now this is not possible to determine since logging of patch changes is done by latest timestamp association in software.
Going forward, it is highly desirable that all deterministic state transitions are logged using the original timestamp of the event which is the cause of the transition. This will allow timing of task logic evolution to be accurately assessed independently of CPU clock variability.