From a82304d6382a44ad20460b649644ac157059d9c8 Mon Sep 17 00:00:00 2001 From: Glen Whitney Date: Tue, 13 Feb 2024 22:44:50 +0000 Subject: [PATCH] Update Engine prototype --- Engine-prototype.md | 1 + 1 file changed, 1 insertion(+) diff --git a/Engine-prototype.md b/Engine-prototype.md index 8495497..8a8310e 100644 --- a/Engine-prototype.md +++ b/Engine-prototype.md @@ -46,6 +46,7 @@ Some of these are obvious, but we may as well write them down. Note we may want * Conversely, track rigid subnetworks, and replace them with fewer working variables. [What do we do about/how do we display over-constrained subnetworks? Do we display the configuration "nearest" to satisfying all the constraints in some sense but show in some bright alarm state the violated constraints, perhaps graded by "how badly" the constraint fails? If we can do this well -- and numeric near-solutions would suffice in over-determined cases, I don't think there's any point in trying to find exact algebraic near-solutions -- then dyna3 could actually be useful working with over-determined systems; it would be doing some sort of optimization that could actually be telling us interesting things.] * Track the current displayed witnesses of satisfying the constraints (after all, we need those at least numerically to update the screen). Hopefully we can actually get exact algebraic current witnesses, at least when we're not in the midst of fast motion. If so, then in lightly constrained networks, we can temporarily add constraints fixing all the entities except for the ones that are being moved, backing off on some temporary constraints by distance in the constraint network until we get a low-dimensional component that we are on, and move just along that component. This will have consequences in the "feel" of the interface: it will make the system "conservative" in the sense of trying to move a small number of entities to keep constraints satisfied in a drag, leaving as much as possible of the construction fixed. One potential problem with that conservative approach is that in many cases it will break symmetry. For example, if M is defined as the midpoint of AB, and you drag M along line AB, you could at most fix one point, but it could be either A or B, so how do you choose? "Least-squares" motion will mean you simply drag the whole segment AB along its line -- is that the "intuitive" motion of the system when its midpoint is dragged? Or is some arbitrary symmetry-breaking OK to maximize the number of stationary entities? * We may be able to take good advantage of the fact that fixing some of the entities will linearize the remaining constraints, so we can very rapidly check if there are any overall solutions with those points fixed, and even tell something about conditions on the values of those entities that do or don't allow the linearized system to be solved. We might want to try to keep track of minimal sets of entities which, when fixed, linearize everything else (in their connected component, per the general simplification). +* Try to emulate Geometry Expressions to some extent and convert some (sets of) constraints into constructions, e.g. if A,B,C collinear and AB=BC, we can just construct B as the midpoint of A and C, and it never need have any variables associated to it. These are basically hand-picked examples of the second bullet, i.e., we might want to have both heuristic and automatic means of detecting rigid subnetworks. Some limitations of this approach, at least as implemented by Geometry Expressions, can be found on pp 18-21 of the [Geometry Expressions manual](https://www.wolfram.com/products/applications/geometryexpressions/manual.pdf). ## Overall solver approaches