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
The idea here is that, for the3 context variables -- t0, v0, dt0 --, we want to have an input slider widget for dt0 to allow the user to change its value between the min/max interval provided, i.e., [90, 110], with the middle value being the initial value, 98, for generating the plot.
More generally, every variable in var_values would be either:
a constant -- no slider
a 3-tuple of min,default,max value -- add an input slider widget between min,max with the current value being the default.
The text was updated successfully, but these errors were encountered:
We would like to have sliders for dt0, dt1, dt2 so that the user could see how choices of these values affect the output, v4.
However, it is also possible that the set of admissible solutions -- the blue trangle below -- effectively moves up/down or left/right. For example, the triangle could move completely to the left -- i.e. a range of roughly dt3 \in [-6, -1]. In such a case, the admissible solutions would not be visible given the viewport bounds -- [0,10]. Currently, this situation would result in an error from Pacti's plotting library that the combination of the viewport bound constraints and those of the contract are unsatisfiable. Instead of showing such an error, the plotting library should issue an indication that the admisible region is outside of the viewport bounds and inform the user how to adjust the viewport bounds accordingly.
This example motivates adding sliders for both:
a selection of variables as sketched previously
the bounds of the viewport -- i.e. the x_lims, y_lims tuples.
Now that we have more experience plotting contracts, I wonder whether the best approach is to have lots of sliders or implement the variable projection idea you raised here #130 (comment)
We have seen that contracts tend to grow in variables a lot. Perhaps it would be better to call the plotting functions by just giving two variables: the x_axis and the y_axis (and their respective bounds). The function should project away the remaining variables of the contract and just show the polyhedron pertaining to the relevant variables.
I had argued that doing this could be too loose #130 (comment). However, considering that now we have optimization available, one can imagine the following flow:
We have a contract with 3 vars: $x$, $y$, $z$.
We plot $(x,y)$ and don't like the result.
We ask for the bounds of $z$ and realize that they are too loose.
We add new $z$-constraints to the contract and recompute the $(x,y)$ plot.
Consider the example below:
The idea here is that, for the3 context variables --
t0, v0, dt0
--, we want to have an input slider widget fordt0
to allow the user to change its value between the min/max interval provided, i.e.,[90, 110]
, with the middle value being the initial value,98
, for generating the plot.More generally, every variable in
var_values
would be either:The text was updated successfully, but these errors were encountered: