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
We have had several requests for supporting arbitrary tw_stime types (see #58 and #34). Could we provide an API for developers to specify their own tw_stime type? What would we need to change?
The text was updated successfully, but these errors were encountered:
The toughest part from a modeling perspective IMO is handling the relationship between tw_stimes and RNGs. For example, floating-point random functions are used fairly extensively in models to add random noise to functions, many of which are less than 1 - tw_rand_unif, for example, returns values in the range (0.0, 1.0) (not sure whether the range is exclusive or not). We'd need to make our models aware that we may no longer be using fractional values. Similarly, we'd likely want to drop down below nanosecond granularity if using integer tw_stime, so handling units correctly would be important (more of a CODES issue than a ROSS one, but mentioning here for completeness).
A cmake option at ROSS build time for controlling the type of tw_stime would be sufficient (this is probably obvious, but wasn't sure whether you were talking about a programmatic API or a build option).
As to @JohnPJenkins 's comment: This is the responsibility of the model developers. The model developers must determine which type they are using for tw_stime and adjust accordingly. Since it's a build-time thing, there should be no impact to codes.
We have had several requests for supporting arbitrary tw_stime types (see #58 and #34). Could we provide an API for developers to specify their own tw_stime type? What would we need to change?
The text was updated successfully, but these errors were encountered: