Are redundant coordinates helping in satisfaction? #40
Labels
No labels
bug
duplicate
enhancement
prospective
question
todo
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: glen/dyna3#40
Loading…
Add table
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?
An apparent complication in nudging is that our valid coordinates are themselves constrained: they must lie on either a hyperboloid in the full coordinate space (in the case of spheres) or a sphere (?, in the case of points -- I think it is the intersection of a cone and a plane, hence a sphere?). I have the intuition that this is entangling the coordinates, and making our gradient descent more prone to e.g. change the radius of a sphere when nudging. Are the redundant coordinates paying for themselves in some way, e.g. helping the optimization converge? Or since we are currently pursuing a gradient-descent-based engine, should we just remove the redundancy from the coordinate systems we are using and just write out the relations between the remaining coordinates that the redundancy was standing in for?
I am thinking of systems based entirely on Euclidean points and scalars and the relationships between them. In such a system a sphere is just a couple of a point and a radius scalar, and any constraints on the sphere are just translated into constraints on the point and the radius. Is it worth trying such an engine for comparison's sake? (Speed/quality of constraint satisfaction, quality of nudging, etc.?)