Visit the preview URL for this PR (for commitf1a01b7):

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

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

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.

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.

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.

I don't write ternary search that often... Perhaps, usinglm = l + (r - l) / 2.1 andrm = r - (r - l) / 2.1 is better than$n/2\pm \varepsilon$, as suggestedhere? 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.

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

Visit the preview URL for this PR (for commit49a3759):

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

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

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

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)

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.

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

@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

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 fromkactl 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.

In BOI 2018, there was a problem that explicitly required to use the golden section search:https://boi18-day1-open.kattis.com/contests/bhptqq/problems/worm

Okay, there are still some things here in the discussion that I'd prefer added (mention some benchmarks, add implementation, etc), but it doesn't seem like it's going to be implemented, so I will merge in the current state.

@NaimSS@SYury if anybody has some more time in the future, I would appreciate new PRs to add benchmarks, implementation, etc.