Default Strength & Weight?

[D4 Tocchini]

Cassowary.js currently defaults to Required Constraints. After a little experience in common layout situations using Cassowary in GSS, it became increasingly clear that a default Required Strength too easily leads to unsolvable solver states & can frustrate debugging.

I recently had a pow-wow with Badros, and he confirmed my suspicion. From what I now understand, Required Constraints are special cases that shouldn't run rampant, that they are more like aliases than a level above Strong.

The question is, what should the default Strength & Weight be? Are the defaults in a layout system a special case? I'm assuming defaults ought to be configurable per SimplexSolver...

Another point, for a given collection of constraints, Cassowary's weighted-sum-better solution can be confusing when dealing with many Equality Constraints of the same Strength, as with:

        var s = new c.SimplexSolver();      
        var x = new c.Variable({ name: 'x' });
  var strength = c.Strength.strong;

        s.addConstraint(new c.Equation(x, 1, strength))
        .addConstraint(new c.Equation(x, 2, strength))
  .addConstraint(new c.Equation(x, 3, strength))
  .addConstraint(new c.Equation(x, 4, strength))
  .addConstraint(new c.Equation(x, 5, strength));

        assert.isTrue(c.approx(x.value, 3.0)); // hmm... not so straight forward...

Throw in some random Weights, and it becomes hard to mentally compute how the error functions will be minimized & reason this to humans:

        var s = new c.SimplexSolver();      
        var x = new c.Variable({ name: 'x' });
  var strength = c.Strength.strong;

        s.addConstraint(new c.Equation(x, 1, strength, 1))
        .addConstraint(new c.Equation(x, 2, strength, 2))
  .addConstraint(new c.Equation(x, 3, strength, 3))
  .addConstraint(new c.Equation(x, 4, strength, 4))
  .addConstraint(new c.Equation(x, 5, strength, 5));

        assert.isTrue(c.approx(x.value, 4.0)); // those tricky error functions

This makes Required defaults seem attractive, but maybe the above examples are too contrived. After all, constraint satisfaction is not all or nothing, and it should be well documented how an optional a == b is treated...

With GSS I added a configurable defaultStrength & defaultWeight, and I've been liking a default of Medium & Weak for layouts, so at least Strong Constraints will completely overcome defaults without resorting to Required and without any potential Weighted error function confusion - allows for more "responsive" layouts. It probably makes sense to have a default Weight, but not sure about that one... need more practice with it...

Depending on such defaults, different gotchas & best practices emerge, would love to hear y'alls thoughts on this...

[Greg Badros]

Yea, you definitely do not want the default to be required -- if I did it over again, I'd use a different set of functions for "Required" strength constraints to make a strong point that they're very different than non-required strength.

I don't love the idea of making the defaults be baked into the solver.  That makes the reader of code have to reason about something non-local (what the solver was initialized with in terms of the default strength) everytime they read constraint-related code.  It's a nice syntactic convenience, but I wouldn't make that tradeoff since reasoning about the constraints and how they interact can already be challenging.

Regarding weights: I never got much mileage out of changing the weights... they're much more confusing to model. If you feel like you need more levels of constraints, I'd create more strength levels -- there was nothing magical about Strong/Medium/Weak + Required, we just thought it covered most of the cases and there were easy names for them. Put differently, unless there's a specific situation that you really need weights to solve, by default, I'd leave the weights alone at the same default.

Hope that helps!

Greg

--
You received this message because you are subscribed to the Google Groups "overconstrained" group.
To unsubscribe from this group and stop receiving emails from it, send an email to overconstrain...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[D4 Tocchini]

Thanks Greg, I ended up using weak as the default strength in GSS.  The more I thought about it, the less it made sense to use a strength weaker than default.  I later noticed that was the default in CCSS, thus confirming my assumptions!  The unresolved question is what should be the default for Cassowary.js...  I don't think the higher level CSS use cases are fundamentally different, so I'm assuming it should be weak as well...

Tweaking weights definitely feels like a last resort measure.  The idea of adding more strength levels is cool, but the 3 + required have been adequate thus far.

Dan

[Greg Badros]

Cool, yea.  The primary need for more constraint strengths is if the semantics of the application are specifically more fine-grained than 3 levels.  Technically, raw CSS does have that has earlier rules in a file trump later rules (or the other way around, I can't remember) but in practice people choose to avoid using that most of the time.

Keep up the great work!

Greg

[Alex Russell]

I've also noticed (as I was trying to re-implement basic box layouts) that Required is too strong a default. See the default value here:

    https://github.com/slightlyoff/cassowary.js/blob/master/demos/css/layout.js#L43

I'm happy to move the system over to Weak-by-default if everyone's cool with the potential breakage.

Thoughts?