Monotonicity constraints: Simplifying SSP (x,y) Input Variable

[njericha]

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".

[JacquesCarette]

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.

[JacquesCarette]

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.

[niazim3]

Summary of relevant information: coords is defined in Unitals.hs as a ConstrConcept https://github.com/JacquesCarette/Drasil/blob/24a63b3c4ab064c373de09bee3e2b8074a2dc9b2/code/Example/Drasil/SSP/Unitals.hs#L123-L127

• is used in sspOutputs https://github.com/JacquesCarette/Drasil/blob/24a63b3c4ab064c373de09bee3e2b8074a2dc9b2/code/Example/Drasil/SSP/Unitals.hs#L53-L54
• is mentioned in A1 (monotonicF Sentence) https://github.com/JacquesCarette/Drasil/blob/24a63b3c4ab064c373de09bee3e2b8074a2dc9b2/code/Example/Drasil/SSP/Assumptions.hs#L24-L27
• is used in the definition for sspInputDataTable https://github.com/JacquesCarette/Drasil/blob/24a63b3c4ab064c373de09bee3e2b8074a2dc9b2/code/Example/Drasil/SSP/Requirements.hs#L67-L69

Re: "Can this constraint be simplified to "Monotonically Increasing"?" If we are going to be simplifying the constraints, I believe we'd need 2 constraints: one in relation to monotonically increasing x-values, and one in relation to having the start and end independent values (i.e. x-values) be equal to each other.

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"" Since it is mentioned only once in the input data table, can it be considered as already compressed into 1 input variable?

(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 sspInputDataTable for each layer and then inputting the coordinates (only) for the water table (if any).)

[niazim3]

How about adding to the current Constrained core of

data ConstraintReason = Physical | Software
data Constraint where
  Range          :: ConstraintReason -> RealInterval Expr Expr -> Constraint
  EnumeratedReal :: ConstraintReason -> [Double]               -> Constraint
  EnumeratedStr  :: ConstraintReason -> [String]               -> Constraint

something similar to the following:

data Monotonicity = Increasing | Decreasing
data Constraint where...
  EnumNature     :: ConstraintReason -> Monotonicity           -> Constraint

?

This way, monotonicity will be handled in a similar way to how ranges and space constraints are currently handled.

[niazim3]

And perhaps adding an Other constraint type for the constraints that are pretty specific to the examples (i.e. in this case "the start and end independent values should be equal to each other.").

[JacquesCarette]

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 Data.Drasil.*) rather than in its core data-structures.

To be honest, I'm not that keen on EnumeratedReal and EnumeratedStr either. I would prefer to migrate them out, rather than add new things like it.

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).

[balacij]

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:

As commented in 1f17b36e, the monotonicity constraint was deleted (by me) because it was encoded using an awful pile of hacks. It needs to be re-implemented properly. (Originally posted by @JacquesCarette)

[smiths]

@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 $t \geq 0$. Other constraints will be derived from the axioms and other theories, like the constraint that $p_{land} > 0$. I think the starting point is looking at how we are going to write our theories. The tables summarizing constraints would then just be generated from going through the theories and pulling out the constraints.

[JacquesCarette]

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 ModelExpr (but not Expr since we don't know what to do with these in CodeExpr).