I think I'll have to add a big *CAVEAT* here. The method I suggested works well if the solver produces a strictly convergent series of estimates, i.e. the current estimate is as least as accurate as the difference between the last two:

|x_new - x_exact| < |x_new - x_old|

This is not (always) true for the 34s solver, and it does not apply to various other algorithms eiher.

Here's an example. Let's consider the following simple function:

ln(x) - 1 = 0

It has a root at x = e. With 2 and 5 as initial guesses The 34s solver produces the following sequence of estimates:

estimate abs. error

-------------------------

2,00000000000 -7,18E-1

5,00000000000 2,28E 0

3,00465761171 2,86E-1 // here the estimate is 0,286 off

2,99797706383 2,80E-1 // but the solver adjusts it by only 0,0068

2,49898853191 -2,19E-1 // which may lead to the conclusion that

2,71681463363 -1,47E-3 // the estimate is already that exact

2,85739584873 1,39E-1

2,71828330193 1,47E-6

2,71828215475 3,26E-7

2,71754839419 -7,33E-4

2,71828182846 -9,00E-15 // here the estimate is almost exact

2,71828199161 1,63E-7 //

2,71828182846 0,00E+0 // and here the estimate evnb is dead on

2,71828191003 8,16E-8 // but due to roundoff the function result

2,71828186925 4,08E-8 // is not exactly zero and the solver again

2,71828184885 2,04E-8 // moves away from the exact solution.

2,71828183866 1,02E-8 // Starting with an estimate that's 8,16E-8 off

2,71828183356 5,10E-9 // it now switches to bisection

2,71828183101 2,55E-9 // so that it takes more than 20 iterations

2,71828182973 1,27E-9 // to find the final digits

2,71828182910 6,37E-10

2,71828182878 3,19E-10

2,71828182862 1,59E-10

2,71828182854 7,97E-11

2,71828182850 3,98E-11

2,71828182848 1,99E-11

2,71828182847 9,96E-12

2,71828182846 4,98E-12

2,71828182846 2,49E-12

2,71828182846 1,25E-12

2,71828182846 6,23E-13

2,71828182846 3,11E-13

2,71828182846 1,55E-13

2,71828182846 7,70E-14

2,71828182846 3,90E-14

2,71828182846 1,90E-14

2,71828182846 9,00E-15

2,71828182846 5,00E-15

2,71828182846 3,00E-15

So the current solver eventually comes to a solution, but it may take a while (which is fine if on the other hand a solution is reliably found in more complex cases). Line 3...5 show why the proposed method of comparing the current estimate with the previous one does not work here.

Here is the sequence returned with 1 and 5 as initial guesses:

estimate abs. error

-------------------------

1,00000000000 -1,72E+0

5,00000000000 2,28E+0

3,48533973824 7,67E-1

2,24266986912 -4,76E-1

2,68993254763 -2,83E-2

3,08763614293 3,69E-1 // here the solver moves away from the solution

2,71846362445 1,82E-4 // ...comes closer

2,71839999019 1,18E-4

2,70416626891 -1,41E-2 // ...moves away again

2,71828182711 -1,35E-9 // ...comes very close

2,71834090865 5,91E-5 // ...but then moves away again

2,71828182846 0,00E+0 // Here x is exact but f(x) is not zero

2,71828182846 2,00E-15 // so the solver prefers this solution

Finally I tried the same with the 35s and 34C solvers.

HP 35s HP-34C

estimate abs. error estimate abs. error

-------------------------------------------------------

1,00000000000 -1,72E+0 1,000000000 -1,72E+0

5,00000000000 2,28E+0 5,000000000 2,28E+0

3,48533973824 7,67E-1 3,485339739 7,67E-1

2,75051645695 3,22E-2 2,442055911 -2,76E-1

2,71892340384 6,42E-4 2,756337820 3,81E-2

1,85946170192 -8,59E-1 2,720245459 1,96E-3

2,71814296203 -1,39E-4 2,718268115 -1,37E-5

2,71828182743 1,03E-9 2,718281833 5,00E-9

2,71828182846 0,00E+0 2,718281828 0,00E+0

2,71828182846 0,00E+0 2,718281829 1,00E-9

Which leads to the question if there are some deeper insights on how HP Solve (resp. a particular implementation) works in detail. I found an interesting discussion here in the forum back in 2003, cf.

this thread.

Dieter