This lesson will delve into the two types of Constraints available in the Constraints screen: 1) Bound Constraints 2) Mutually Bound Constraints.
“Bound Constraints” are a constraint for your m to ensure that certain values only appear with certain other values; these two values must appear together. Knowing which type to use depends on your goals and parameter/value structure.
Bound Constraints
Bound Constraints are used when a certain value can only appear with a certain other value. Let’s make a bound constraint between ‘Internet Browser = IE’ and ‘Operating System = Windows.’
In this example, ‘Internet Browser = IE’ must appear with ‘Operating System = Windows.’ In other words, whenever ‘IE’ appears in your set of tests, ‘Windows’ tags along. It’s as if ‘IE’ can only “see” ‘Windows’ when it looks for a value from ‘Operating System.’ Likewise, ‘IE’ is unable to appear with ‘OSX’ nor ‘Linux.’
Check out the confirmation to the left of the inputs to confirm that the logic is what you need for your model.
So what about the other values from ‘Internet Browser?’ Although ‘Chrome,’ ‘Firefox,’ and ‘Safari’ are part of the same parameter as ‘IE,’ they are able to pair with any value from ‘Operating System’ as usual, including ‘Windows.’ The bound constraint does not directly concern the other Internet Browsers values. The image above illustrates how ‘Internet Browser = IE’ will only pair with ‘Operating System = Windows’ when concerning those two parameters.
Another way to think about it is that you want ‘Internet Browser = IE’ to appear with ‘Operating System = Windows,’ but you don’t mind if ‘Internet Browser = Chrome,’ ‘Internet Browser = Firefox,’ or ‘Internet Browser = Safari’ also appear with ‘Operating System = Windows.’ However, ‘Internet Browser = Safari’ pairing with ‘Operating System = Windows’ doesn’t make sense and would additionally need to deal with that appropriately. Check the area to the left of the inputs to see what you have already bound.
If more parameters were present, their values would still be able to combine normally with values included in a bound constraint. The bound constraint does not concern those “outside” values, so it combines with those “outside” values as usual.
Right to Left Bound Pair
Like a Left to Right pair, a certain value can only appear with a certain other value. Let’s use a different set of inputs to make a Right to Left married pair between ‘Type of Animal = Cat’ and ‘ Breed of Animal = Persian.’ This type of married pair makes it so ‘Breed of Animal = Persian’ can only pair with ‘Type of Animal = Cat.’
This time, ‘Breed of Animal = Persian’ will only “look” at ‘Type of Animal = Cat.’ If the values were analogous to dancers at a ball, ‘Breed of Animal = Persian’ will only take the hand of ‘Type of Animal = Cat;’ in this case, ‘Type of Animal = Dog’ is unacceptable.
On the other hand (pardon the pun), ‘Type of Animal = Cat’ doesn’t mind anyone from ‘Breed of Animal.’ Again, parameter values outside of the married pair are still tested with any value from either parameter as normal. In other words, you want ‘Type of Hotel = 5-Star’ to appear with ‘Add Hotel Reservation = Add hotel’ but you don’t mind if ‘Type of Hotel = 3-Star’ or ‘Type of Hotel = 4-Star’ are also able to appear with ‘Add Hotel Reservation = Add hotel.’
The order in which you set the pair matters!
Mutually Bound Constraints
With Mutually Bound Constraints, the values in the constraint are exclusive to each other. This is great for situations with ‘not applicable’ (N/A) values. With the inputs below, whenever ‘Add Hotel Reservation = Do not add’ appears in your set of tests, ‘Type of Hotel = N/A (skip – no hotel reservation)’ appears with it, and vice-versa. All other values from ‘Add Hotel Reservation’ can no longer combine with ‘Type of Hotel = N/A (skip – no hotel reservation),’ and all other values from ‘Type of Hotel’ can no longer combine with ‘Add Hotel Reservation = Do not add.’
Take a look in the top left of the image above. This indicates that ‘Add Hotel Reservation = Do not add’ will only ever combine with ‘Type of Hotel = N/A (skip – no hotel reservation)’ when DesignWise combines values of the parameters ‘Add Hotel Reservation’ and ‘Type of Hotel.’
Just like with regular Bound Constraints, values from ‘No-Smoking Room’ combine normally with values from ‘Add Hotel Reservation’ and ‘Type of Hotel’ because ‘No-Smoking Room” is not involved with the Mutually Bound Constraint. Using a similar metaphor as above, the ballroom dancers ‘Do not add’ and ‘N/A (skip – no hotel reservation)’ will only take each other’s hand to dance, when choosing partners between Add Hotel Reservation’ and ‘Type of Hotel.’
You may have noticed that ‘No-Smoking Room? = N/A (skip – no hotel reservation)’ wouldn’t make sense with ‘Add Hotel Reservation = Add hotel.’ Good eye! This should also have a Mutually Bound Constraint for itself and ‘Add Hotel Reservation = Do not add.’ Let’s do it!
DesignWise automatically recognizes that ‘Add Hotel Reservation = Do not add’ already has a Mutually Bound Constraint with ‘Type of Hotel = N/A (skip – no hotel reservation).’ Not only will the Mutually Bound Constraint between ‘Add Hotel Reservation = Do not add’ and ‘No-Smoking Room? = N/A (skip – no hotel reservation)’ be generated, ‘No-Smoking Room? = N/A (skip – no hotel reservation)’ will automatically be assigned to a Mutually Bound Constraint with ‘Type of Hotel = N/A (skip – no hotel reservation).’
In essence, Bound Constraints and Mutually Bound Constraints do a similar task as Invalid Constraints: they ensure that certain values only appear together or separately, respectively. From a different point of view, Bound Constraints and Mutually Bound Constraints actually invalidate many values and Invalid Constraints bind many values, behind the scenes.