-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Monotonicity constraints: Simplifying SSP (x,y) Input Variable #295
Comments
A 2D coordinate can be treated as 2 values and 1 value (and often is). We need to have Space be able to track that. Experience has shown that the more you think of n-space as having points (i.e. forget the details of the coordinates), the better off you are. But the details can be tricky to manage. |
I'm going to draw @niazim3 's attention to this issue. The point isn't to just go and 'fix' this (it needs some design first), but it is something worth pondering. |
Summary of relevant information: Drasil/code/Example/Drasil/SSP/Unitals.hs Lines 123 to 127 in 24a63b3
Re: "Can this constraint be simplified to "Monotonically Increasing"?" Re: "And should these be compressed into 1 input variable? I ask because my input data table only includes a sing entry for "(x,y): cartesian position coordinates"" (Note: Assumption 2 states "The geometry of the slope, and the material properties of the soil layers are given as inputs."; the input file has the format of inputting the # of soil layers, followed by the properties described in |
How about adding to the current Constrained core of
something similar to the following:
? This way, monotonicity will be handled in a similar way to how ranges and space constraints are currently handled. |
And perhaps adding an |
I am not very keen on this. The current constraints (with variations on ranges) already teach Drasil about some mathematical concepts in a 'deep' way. The reason this is not-too-bad is because of how pervasive these concepts are, and how much we can leverage that knowledge once we have it. Monotonicity is not like that. It is one of many mathematical concepts. It should be 'taught' to Drasil using features of Drasil made to extend the knowledge base of Drasil in a more dynamic way (i.e. via data in To be honest, I'm not that keen on I realize that my answer is not necessarily helpful (at least, it isn't regarding a design to solve this problem). We do need a proper design for constraints and properties. And we don't have one (yet). |
It appears that #453 and this ticket are in conflict. I do think we want 'monotonicity' somehow attached to variables. Constraints in Drasil at the moment are problematic in that we don't really derive them from anywhere -- I understand where @JacquesCarette is coming from there. I think the course of action is to merge these two tickets and discuss what actually goes into constraint tables, how we came about learning what to put in the constraint tables, and when said constraints are associated with variables. Content from #453:
|
@balacij I think at one time we fell into a trap of thinking that constraints are simply upper and lower bounds for a single variable. In many cases they are, but in other cases there is more going on. Some constraints will involve the relationship between more than one variable and others will be properties of the inputs or the output, like monotonicity. Some constraints will be derived from other constraints, some will come from physics, some will come from practical considerations. In metamorphic testing domain experts look for properties they know will be true based on their knowledge. As we discussed in #26 constraints should often (always?) be accompanied by a rationale. We need to track that information too. I think some constraints are axioms that are attached to our theories, like the assumption that for projectile motion |
Right - this is where we desperately need theories. Constraints are then (relational) axioms on the variables of that theory. Note that we could re-add some of the vocabulary of constraints to |
Jump to bottom comment for latest information.
I have the following constraint on three of my input variables.
Consecutive vertexes have increasing x values. The start and end vertices of all layers go to the same x values.
The variables are "(x,y) of water table vertices'", "(x,y) of slip vertices'", and "(x,y) of slope vertices'". Can this constraint be simplified to "Monotonically Increasing"? And should these be compressed into 1 input variable? I ask because my input data table only includes a sing entry for "(x,y): cartesian position coordinates".
The text was updated successfully, but these errors were encountered: