Here's a simple relaxation visualizer: http://worrydream.com/VisualizingRelaxation/ It seems to me like what you'd like to see and compare is: - the state of the system at each step of the relaxation process - the error of each constraint (and the total error) at each step In order to compare, they have to be in the same visual domain (ie, the system states in the same visual state space, and the errors plotted with a common baseline). That's what I've tried to do here. The most important thing, I think, is decoupling "solver time" from "UI time". Just because the solver iterates through a series of steps over (computer) time doesn't mean that the appropriate representation is an animation over (human) time. In this case, it's best to show all the steps simultaneously. This allows you to see the convergence, as well as skim your mouse over a chart to "pick out" particular steps and study them. ("stepping down" the ladder of abstraction) For this example, I used the "chain" example from Sketchpad 14, but I think the general idea would work with most constrained systems if you can visualize the state space and constraint space. On Dec 15, 2014, at 11:31 AM, Alan Kay <****************> wrote: > Hi Folks > > Alan Borning and Alex have been talking about "visualizing relaxation" (and this would be great to see and to have). > > This also got me thinking about relaxation from the "visualization inward" (as Bret and Toby often do), and as a "did you ever look at this from this POV?" (as Vi often does). > > In particular it would be great for kids in 5th grade (maybe earlier) onwards to think about solving problems that have multiple conditions by searches that try to minimize errors. (I wonder what that would look like for them?) > > This is the kind of thing that the National Council of Teachers of Math would hate (could be a good reason all by itself!), but it also has the big sweet property of being amenable to non-linear problems right from the start, and not be confined to examples that work relatively simply via algebraic manipulation. Instead you'd be using visualizations of the conditions right from the start, you could see approximate solutions *right there*, and these would provided a lot of motivation for how a computer program could really home in on the intersections, etc. > > The spring project in Etoys is a good example, and it could have been even more powerful if we had used "manipulable vectors" in Etoys to show and use the differential relationships (still, a great followup to the excellent approach to 5th graders and Galilean gravity that we used). > > (I'll admit that I was dropped on my head this way from the only math teacher I really liked in high school ... he was really interested in what could be *meant* by mathematical representations ... so he liked to solve lots of intractable problems graphically (and there they weren't intractable. I had a similar experience in grad school via a course in signal processing by the wonderful Tom Stockham which completely illuminated in a powerful ways what I had "learned" but "didn't understand" as an undergrad math major (as Sherlock Holmes said: "Watson, you look but you do not see!") > > I think a lot of us in CDG have interestingly overlapping thoughts about these areas! > > Cheers > > Alan > > >