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

Update Engine prototype

Glen Whitney 2024-02-08 23:01:27 +00:00
parent 15d387b772
commit 76ffbe5d5b
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Engine-prototype.md

@ -27,7 +27,7 @@ Some of these are obvious, but we may as well write them down. Note we may want
* Keep the network of entities (or variables?) and constraints. Only ever work on one connected component of this at a time. * Keep the network of entities (or variables?) and constraints. Only ever work on one connected component of this at a time.
* 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, leving 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).
## Overall solver approaches ## Overall solver approaches