You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By having a 64-bit integer tw_stime rather than a floating-point, you can basically eliminate any precision issues while still having a very long time-frame available. For instance, if you work in picoseconds (1e-12), the max time you can have is approx 213 days. Bumping that up to nanoseconds would get you 213,000 days.
Not sure what the implications are of changing this type - I know for example the RNG is floating point. Though I would think that most uses of tw_stime in ROSS are comparisons, as the users drive event times.
The text was updated successfully, but these errors were encountered:
I believe that we use floating points so that users can easily add jitter (via RNG) and avoid ties. Ties would be one negative to switching to integer time-stamps.
Another thought to document...
By having a 64-bit integer tw_stime rather than a floating-point, you can basically eliminate any precision issues while still having a very long time-frame available. For instance, if you work in picoseconds (1e-12), the max time you can have is approx 213 days. Bumping that up to nanoseconds would get you 213,000 days.
Not sure what the implications are of changing this type - I know for example the RNG is floating point. Though I would think that most uses of tw_stime in ROSS are comparisons, as the users drive event times.
The text was updated successfully, but these errors were encountered: