StudioInfinity/dyna3

Fork 2

Rewind through the descent history #114

Merged

glen merged 2 commits from Vectornaut/dyna3:rewind-history into main

2025-09-18 23:31:18 +00:00

Vectornaut commented

2025-08-23 04:10:37 +00:00

Member

On the incoming branch, you can rewind through the descent history of the last realization using the Step control that's been added to the diagnostics panel.

The starting value of the Step control depends on the realization status. After a successful realization, we show the realized state (the last step). After an unsuccessful realization, we show the initial guess (step zero).

Shortcomings

Awkward factorization of realization results

On the incoming branch, the application gets all the configuration information it needs from the history field of the Realization structure that realize_gram returns. The config field in Realization::result is never read. In fact, the config field is never read from any ConfigNeighborhood structure.

The config field is still used in tests and examples, however, so we compile it conditionally to avoid a dead code warning.

If the history rewind feature ends up being a long-term part of the application, we should refactor the Realization structure to avoid this awkward orgnization. Since this feature is engine-dependent, however, I don't think we should plan for its long-term presence yet.

Nudging from previous steps

On the main branch, nudging requires a valid tangent space. Right now, we only have a valid tangent space for the last step of a successful realization and (usually) the initial step of a failed realization. On the incoming branch, this raises the question of what to do when we try to nudge from other steps. I've chosen an expedient answer: simply disable nudging from other steps.

We can revisit this shortcoming if we find that it might be useful to nudge from other steps, or if we redesign the tangent space system (which I think we should consider at some point).

On the incoming branch, you can rewind through the descent history of the last realization using the *Step* control that's been added to the diagnostics panel. The starting value of the *Step* control depends on the realization status. After a successful realization, we show the realized state (the last step). After an unsuccessful realization, we show the initial guess (step zero). ## Shortcomings ### Awkward factorization of realization results On the incoming branch, the application gets all the configuration information it needs from the `history` field of the `Realization` structure that `realize_gram` returns. The `config` field in `Realization::result` is never read. In fact, the `config` field is never read from any `ConfigNeighborhood` structure. The `config` field is still used in tests and examples, however, so we compile it conditionally to avoid a dead code warning. If the history rewind feature ends up being a long-term part of the application, we should refactor the `Realization` structure to avoid this awkward orgnization. Since this feature is engine-dependent, however, I don't think we should plan for its long-term presence yet. ### Nudging from previous steps On the main branch, nudging requires a valid tangent space. Right now, we only have a valid tangent space for the last step of a successful realization and (usually) the initial step of a failed realization. On the incoming branch, this raises the question of what to do when we try to nudge from other steps. I've chosen an expedient answer: simply disable nudging from other steps. We can revisit this shortcoming if we find that it might be useful to nudge from other steps, or if we redesign the tangent space system (which I think we should consider at some point).

Vectornaut added 1 commit 2025-08-23 04:10:38 +00:00

Rewind through the descent history

/ test (pull_request) Successful in 3m47s

Details

36036141b5

glen commented

2025-08-23 20:50:54 +00:00

Owner

This all looks reasonable. Two things:

when you're not allowed to nudge and you hit the nudge key, there's no feedback that you just tried to do something that failed. The situation can be confusing because sometimes it's tricky to observe the result of nudging.
When the search fails and you are looking at step 0, it seems as though you can't nudge from there, even though presumably it's the same configuration as the result of the last operation, from which you could nudge. This limitation is of practical interest because quite possibly you had a line search failure from too much symmetry in the previous configuration (say two coinciding points that you constrain to have positive distance), and so you just want to nudge to break the symmetry. Instead you have to do some other operation to get back in the nudge-able state, then nudge, then re-try your new constraint.

If either of these is a reasonably quick and simple fix, please go ahead. Otherwise just file (prospective) issues for them (and in any case file a prospective issue for the "awkward factorization" point above) and let me know, and I will merge this PR. Thanks!

This all looks reasonable. Two things: * when you're not allowed to nudge and you hit the nudge key, there's no feedback that you just tried to do something that failed. The situation can be confusing because sometimes it's tricky to observe the result of nudging. * When the search fails and you are looking at step 0, it seems as though you can't nudge from there, even though presumably it's the same configuration as the result of the last operation, from which you could nudge. This limitation is of practical interest because quite possibly you had a line search failure from too much symmetry in the previous configuration (say two coinciding points that you constrain to have positive distance), and so you just want to nudge to break the symmetry. Instead you have to do some other operation to get back in the nudge-able state, then nudge, then re-try your new constraint. If either of these is a reasonably quick and simple fix, please go ahead. Otherwise just file (prospective) issues for them (and in any case file a prospective issue for the "awkward factorization" point above) and let me know, and I will merge this PR. Thanks!

Vectornaut added 1 commit 2025-08-28 07:54:58 +00:00

Nudge from initial step of failed realization

/ test (pull_request) Successful in 3m36s

Details

43a65eba65

Vectornaut commented

2025-08-28 08:01:53 +00:00

Author

Member

The code now allows nudging from the initial step of a failed realization. I've updated the pull request description accordingly.

The description no longer mentions issue #100, because I noticed that it may already have been fixed by pull request #105. Since #100 no longer has a working reproduction procedure, we can't tell how this pull request might affect it.

The code now allows nudging from the initial step of a failed realization. I've updated the pull request description accordingly. The description no longer mentions issue #100, because I noticed that it may already have been fixed by pull request #105. Since #100 no longer has a working reproduction procedure, we can't tell how this pull request might affect it.

Vectornaut commented

2025-08-28 08:06:34 +00:00

Author

Member

when you're not allowed to nudge and you hit the nudge key, there's no feedback that you just tried to do something that failed. The situation can be confusing because sometimes it's tricky to observe the result of nudging.

I've now filed issue #115, which covers this.

> when you're not allowed to nudge and you hit the nudge key, there's no feedback that you just tried to do something that failed. The situation can be confusing because sometimes it's tricky to observe the result of nudging. I've now filed issue #115, which covers this.

Vectornaut referenced this pull request

2025-08-29 08:24:48 +00:00

Awkward factorization of realization results #116

Vectornaut commented

2025-08-29 08:25:42 +00:00

Author

Member

(and in any case file a prospective issue for the "awkward factorization" point above)

This is now filed as issue #116, so I think the pull request should be ready to merge!

> (and in any case file a prospective issue for the "awkward factorization" point above) This is now filed as issue #116, so I think the pull request should be ready to merge!