`bracket_and_solve_root` extraneous parameter `rising`

[JacobHass8]

The parameter rising for the function bracket_and_solve_root seems to be redundant. This is because the input function f is assumed to be monotonic in the half of the real axis containing the input guess. Since f is monotonic, couldn't rising simply be inferred by looking at the slope between two points on the half of the real axis containing guess?

In a similar vein, does/should bracket_and_solve_root throw an error if f is not monotonic? I would think this could be calculated via the slope at each step.

Having the wrong input for rising has caused quite a bit of trouble for me.

[jzmaddock]

I'm not sure it's that easy: the routine is quite robust and will cope with local minima/maxima reasonably well provide you get the overall direction of travel (the rising param) correct. It doesn't ever calculate the slope either: once the root is bracketed it uses interpolation to find the root.

BTW bracket_and_solve_root was only ever intended as a quick and dirty way to get a result - the underlying algorithm requires a bracketed root, and ideally we would always use our knowledge of the function being inverted to provide reasonably tight brackets (as in not [0, INF]) and a decent first guess. Of course it's not always so easy!

So while I'm not completely against it, I think it's a different function, and it does open a whole other can of worms.

[JacobHass8]

I'm not sure it's that easy: the routine is quite robust and will cope with local minima/maxima reasonably well provide you get the overall direction of travel (the rising param) correct. It doesn't ever calculate the slope either: once the root is bracketed it uses interpolation to find the root.

Oh, if the slope is never calculated then disregard calculating the slope at each step. Couldn't the direction of travel simply be calculated by taking a step in some direction and seeing if the function gets closer/further from 0? Then set the rising param accordingly?