Tridiminished icosahedron: line search failed #104
Labels
No labels
bug
design
duplicate
enhancement
maintenance
prospective
question
regression
stub
todo
ui
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: StudioInfinity/dyna3#104
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
To reproduce: starting from the assembly produced by selecting tridiminished tetrahedron, fill in each A-A, A-B, B-C, and C-C inversive distance at -0.25 (as prescribed by the comments in the test assembly code) in turn from top to bottom, then start filling in the A-C inversive distances at -0.6545084971874737. Line search failed for me upon adding the A_1 C_3 distance (the second such distance after A_1 C_2.
This could use independent reproducing to see if it is consistent across machines. Once replicated, it should be labeled "bug".
Trying to reproduce now. There are no B–B inversive distance regulators; did you mean A–A?
Yes typo fixed now.
Huh: I don't get a line search failure. In fact, once I've set all the inversive distances except the A–C ones, I find that the A–C ones already have the desired values. This is consistent with our conjectural yes answer to the tridiminished icosahedron rigidity problem. Could you post the values you get for some of the A–C inversive distances once you've set all the others?
OK will try again post-merge.
To help check whether we're following the same procedure: I'm setting distances in this order. The ordering of the elements in the To column might be machine-dependent, because the regulator lists in the outline view are sorted only by number of subjects, leaving the order otherwise arbitrary. (Maybe it would be useful to do a secondary sorting by subject identifiers, to match the current hard-coded outline order—but we're still planning to replace the outline view anyway.)
A_1
B_2
B_3
A_3
A_2
A_2
A_3
B_3
B_1
A_3
B_1
B_2
B_1
C_1
B_2
C_2
B_3
C_3
C_1
C_3
C_2
C_2
C_3
OK, worked this time. Perhaps the first time I accidentally put a -0.25 into one of the A-C boxes, which would of course ultimately create an impossible configuration.
@glen wrote in #104 (comment):
Yes, I recall experiencing some realization failures like that when I was playing with this assembly! I think it's an encouraging example of dyna3 working as we'd hoped (although it also highlights a pain point in the interface).
I mean neither of this thinks this is a usable app for actual modeling. I may be doing an impossible solid build at CSU-Pueblo in September. If that is confirmed, I would like to try dyna3 with it displaying its best fit upon realization failure to see if I can (a) reproduce orchidpalms' result on its nearest-miss dome over a 5-5-4 vertex and in fact (b) see if the quality-of-fit improves by replacing the rigid octagon on top by a dome of equitriangles (so there are only triangles besides the initial vertex). In that case, we would totally pump up the priority of (I) being able to display the best fit even when realization fails, and (II) having easier ways to set segment lengths and/or manipulate the display.