Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a paragraph on golden section search #1119

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

SYury
Copy link
Contributor

@SYury SYury commented Jul 11, 2023

No description provided.

@github-actions
Copy link

Visit the preview URL for this PR (for commit f1a01b7):

https://cp-algorithms--preview-1119-onu0hmd3.web.app

(expires 2023-07-18T16:36:20.301594370Z)

@adamant-pwn
Copy link
Member

adamant-pwn commented Jul 14, 2023

Thanks for the pull request! Do you think you can also provide some implementation and benchmarks for this method? I'd really like to know how much it improves on practice. Also when we say that "only once at each iteration" we should as well note that the number of iterations increases to, I assume $\log_\phi n$, while the original ternary search, if split at $n/2 \pm \varepsilon$ can terminate in only $\log_2 n$ iterations.

So, we reduce the number of function computations per iteration by a factor of $2$, but we increase the number of iterations by a factor of $\log_\phi 2 \approx 1.44$. So, theoretically the improvement should just be by a factor of $2 \log_2 \phi \approx 1.38$, I wonder if it stands in practice.

Also, maybe we should highlight more that it is especially important in nested search, as the improvement multiplies in this case.

@SYury
Copy link
Contributor Author

SYury commented Jul 15, 2023

Thanks for the pull request! Do you think you can also provide some implementation and benchmarks for this method? I'd really like to know how much it improves on practice. Also when we say that "only once at each iteration" we should as well note that the number of iterations increases to, I assume logϕ⁡n, while the original ternary search, if split at n/2±ε can terminate in only log2⁡n iterations.

So, we reduce the number of function computations per iteration by a factor of 2, but we increase the number of iterations by a factor of logϕ⁡2≈1.44. So, theoretically the improvement should just be by a factor of 2log2⁡ϕ≈1.38, I wonder if it stands in practice.

Also, maybe we should highlight more that it is especially important in nested search, as the improvement multiplies in this case.

I'll try to design some benchmarks, I think finding largest inscribed circle will be a good one. I definitely encountered some problems which I couldn't pass with ordinary ternary search and passed after choosing points with golden section, but they mostly appeared on Petrozavodsk contests, so I doubt I can find them now.

@SYury
Copy link
Contributor Author

SYury commented Jul 15, 2023

Also could you elaborate on choosing $n/2 \pm \varepsilon$? This approach looks kinda strange, with big $\varepsilon$ there will be problems when $r - l \sim \varepsilon$ and with small $\varepsilon$ function values in splitting points will be too close to compare.

@adamant-pwn
Copy link
Member

I don't write ternary search that often... Perhaps, using lm = l + (r - l) / 2.1 and rm = r - (r - l) / 2.1 is better than $n/2\pm \varepsilon$, as suggested here? In any case, the point is that splitting in three equal parts is likely sub-optimal for the number of iterations, and it's better to pick points closer to the middle.

@adamant-pwn
Copy link
Member

@SYury hi, do you have any updates on this? Do you plan to move forward with benchmarks?

Copy link

Visit the preview URL for this PR (for commit 49a3759):

https://cp-algorithms--preview-1119-ciidekzq.web.app

(expires 2023-12-27T01:56:42.672782340Z)

@adamant-pwn
Copy link
Member

Another important point is, I would really appreciate it if the change also included the implementation for this approach.

@jxu
Copy link
Contributor

jxu commented Dec 20, 2023

Can you confirm this

Golden-section search does the same as ternary search, except each iteration the interval size is multiplied by 1/phi = 0.618... instead of 2/3 = 0.666.... The Wikipedia page is way too verbose. Both run in O(log n) time so I don't think there's much practical benefit.

Originally posted by @jxu in #1159 (comment)

@adamant-pwn
Copy link
Member

I think there is a significant practical benefit in terms of constant term optimization if function computation is costly. Especially in the case of nested search, the constants multiply which makes it even more important.

@adamant-pwn
Copy link
Member

@SYury hi, do you plan any further work on this?

@SYury
Copy link
Contributor Author

SYury commented Feb 25, 2024

@SYury hi, do you plan any further work on this?

Currently I'm very busy, so probably not. Maybe in a couple of months, if someone doesn't pick this work up

@NaimSS
Copy link

NaimSS commented Apr 25, 2024

I did some simple tests with f(x) = x^2 + 1, L = -4e6, R = 4e6 and eps = 1e-9 just to get a feel.
As a result:

  • the usual ternary search did 182 calls,
  • the modified ternary search (the one with (r-l)/2.1)) did 114 calls
  • Golden section search did 79 calls.

As said in the comment section of the blog linked, this is more useful for interactive problems, there are even some examples. Anyways, the implementation from kactl is neat and I can make a more clever benchmark if you give me some ideas on how.
We could try to test it in a recent WF problem or some other problem with nested ternary searches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants