You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing the simplex techniques (Torczon in particular) with integer parameters, I‘ve noticed that the simplexes lose vertices as they move through the search space and degenerate into low-dimensional simplexes. Apparently this happens because the vertices are “rounded” to the nearest valid configuration during the reflection/expansion/contraction step, so two different vertices can end up on the same position end effectively become a single point. Is there a particular reason for why you’ve chosen this approach instead of using floating point coordinates and mapping the vertices to configurations afterwards?
I’ve auto-tuned the same application with the latter approach (using a different framework), and this seemed to produce better and more consistent results. The Torczon implementation of OpenTuner converged very early, and the quality of the result was heavily dependent on the initial simplex.
The text was updated successfully, but these errors were encountered:
Torczon is one of the less optimized techniques so hasn't gotten a lot of attention. It tends to only work on simple+smooth search spaces, while opentuner is designed for more difficult search spaces which the other techniques available handle much better.
Feel free to submit a PR to remove the rounding in simplex techniques (just store the unrounded values in the technique), that seems like a reasonable change.
While testing the simplex techniques (Torczon in particular) with integer parameters, I‘ve noticed that the simplexes lose vertices as they move through the search space and degenerate into low-dimensional simplexes. Apparently this happens because the vertices are “rounded” to the nearest valid configuration during the reflection/expansion/contraction step, so two different vertices can end up on the same position end effectively become a single point. Is there a particular reason for why you’ve chosen this approach instead of using floating point coordinates and mapping the vertices to configurations afterwards?
I’ve auto-tuned the same application with the latter approach (using a different framework), and this seemed to produce better and more consistent results. The Torczon implementation of OpenTuner converged very early, and the quality of the result was heavily dependent on the initial simplex.
The text was updated successfully, but these errors were encountered: