glen/dyna3
1
0
Fork 0
Code Issues 14 Pull Requests 1 Actions Projects Releases 2 Wiki Activity

Update Engine prototype

Glen Whitney 2024-02-13 22:44:50 +00:00
parent 1352af7a3f
commit a82304d638
1 changed files with 1 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
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.] * 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? * 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). * 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 ## Overall solver approaches