二等分検索アルゴリズム

計算方法が正しいと思いますが数字が正解に合いません。しかし正解を読んでも分かりません。
The objective is to find the minimal time needed to walk vertically along 4 islands and to swim horizontally and (possibly) vertically across three rivers. My algorithm considers how to allocate the vertical distance to be traversed, as the horizontal distance is fixed (each river must be swum across). I start by allocating 1.0 to walking and 0 to swimming. Then I reduce the allocation to .5 for walking and compare times. In order to compute the total crossing time for a walking allocation, a recursive call is made to allocate the remainder of the vertical distance to the three rivers. Two recursive calls are needed: one to allocate the left-over distance from walking between river 1 and rivers 2-3, another to allocate the remainder from walking plus river 1 between river 2 and river 3.
Strangely, the algorithm and the formulas upon which it is based seem correct, but the bisecting search does not reach either the correct allocation of vertical distance to walking or the correct time.
I reach an allocation of about 0.046 for the walking allocation, when the optimal solution is 0.007. The time I output is 3.20756, but 3.20635 is expected. The incorrect behavior seems to occur when the ratio to walking is at .03, as here the delta changes to a positive value (indicating that time is increasing). It is unclear whether the error is due to the walking time computation or the swimming time computation (in the root time method or a recursive call).
Looking at the solutions, the design of my algorithm (3-tiered recursion with interval-based search at each stage) was correct. However, my search fails to find the correct allocation to the (walk,river1,river2,river3) tuple. The key point seems to be that, given a convex function, when a decrease in output becomes an increase, you have bypassed the minimum. However, my code seems to reach this behavior for a sub-optimal allocation. It seems that the problem was that I move the allocation to a river using a shifting delta, which moves in decreasingly smaller steps, each step size being one half of the predecessor. This causes some values to be unreachable, given an initial start of -.5. I tried changing the multiple from .5 to .8 for the decrease, which yielded output within 10^-6 of the solution. It seems that the only correct way is to store not only the "delta" but instead the left and right bounds of the search interval (e.g. 0 and 1 to start) and continue to move these closer together. The search can be bounded at 100 iterations.
Basically, I did solve the problem correctly in terms of creating a "sliding window" in which to search for an allocation to each river. However, I basically: 1. create a window 2. check the time obtained using the center of the window against previous 3. reduce window by half 4. if new time was less than old, shift window left, else shift it right. The use of the center instead of endpoints and the shrinking of window size seems to make some values impossible to obtain. Instead, a sliding window search where 1. both endpoints of the window are used to obtain a time (based on an allocation that is at an offset from the endpoints, 2. the min of these 2 times is compared to shortest time found so far and the shortest time updated if necessary, 3. If left side is better, shift the right endpoint to the offset used in calculation. If the right side is better, shift the left endpoint to the offset used in calculation.
This approach ensures that all points can be checked with equal probability and that points are discarded only when another point with a better time output is found.