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
It would be useful to implement a discrete-continuous variable type for uncertainties and policy levers. As an example, a user may want to have a policy lever to add a new transit line or not, and if added, what level of service will be provided on the new transit line. This can be approximated by two levers instead of one, but it may be easier to manage and interpret if it's only one.
This also could be useful in automating experimental design, as for instances of the "no build" experiments, the level of service lever is meaningless, and so we will need fewer "no build" experiments than "build" experiments.
The text was updated successfully, but these errors were encountered:
As an interim solution to this kind of problem, I suggest using two parameters: one Boolean parameter controlling the build/no build status, and another continuous variable to represent the level of service, which is effectively ignored in a model run if "no build" is selected (this must be done in the bespoke model API or implicitly in the core model itself). To control the design of experiments to over-weight the "build" solution (more experiments are needed to explore the "build" space that contains more diversity than the "no build"), use a binary setting for the distribution in the scope, and set p_true to a value larger than 0.5. The scope YAML should have a part that looks approximately like this:
new_transit_los:
ptype: policy lever
dtype: int
default: 30
min: 5
max: 50
new_transit_build:
ptype: policy lever
dtype: bool
default: False
dist:
name: binary
p_true: 0.75
It would be useful to implement a discrete-continuous variable type for uncertainties and policy levers. As an example, a user may want to have a policy lever to add a new transit line or not, and if added, what level of service will be provided on the new transit line. This can be approximated by two levers instead of one, but it may be easier to manage and interpret if it's only one.
This also could be useful in automating experimental design, as for instances of the "no build" experiments, the level of service lever is meaningless, and so we will need fewer "no build" experiments than "build" experiments.
The text was updated successfully, but these errors were encountered: