The current behavior for the cost model is to allow users to specify weights at runtime but fail if any of the state variables that those weights correspond to are not in the current traversal model. For example, if we load the 2016 Toyota Camry model and then we pass a query that looks like this:
We'll get an error back saying there are unknown state variables in query:.
This is helpful behavior to make sure we're not mistakenly passing a weight with a typo (which silently reverts to a default) but, when doing a grid search, it is undesirable since we might want to search over multiple vehicle models and our current grid search mechanism doesn't allow us to specify different weights for different vehicles.
So, perhaps we provide a new configuration parameter that defines the behavior for setting weights, something like expect_exact_state_variables, where if it's set to true, we get the current behavior but if it's set to false, we allow extra weights to exist in the query but then we just don't use them.
The current behavior for the cost model is to allow users to specify weights at runtime but fail if any of the state variables that those weights correspond to are not in the current traversal model. For example, if we load the 2016 Toyota Camry model and then we pass a query that looks like this:
We'll get an error back saying there are
unknown state variables in query:.This is helpful behavior to make sure we're not mistakenly passing a weight with a typo (which silently reverts to a default) but, when doing a grid search, it is undesirable since we might want to search over multiple vehicle models and our current grid search mechanism doesn't allow us to specify different weights for different vehicles.
So, perhaps we provide a new configuration parameter that defines the behavior for setting weights, something like
expect_exact_state_variables, where if it's set to true, we get the current behavior but if it's set to false, we allow extra weights to exist in the query but then we just don't use them.