Threaded Mode | Linear Mode

robve · (This post was last modified: 06-19-2024 05:27 PM by robve.)

I realize dumping a set of results with code isn't helping much to further this discussion. I'm happy to comment on questions and to avoid confusion.

(06-19-2024 12:20 PM)Albert Chan Wrote:
(06-19-2024 02:01 AM)robve Wrote: - optionally allow one or more retries after overshooting, this is parameter g. When g=0 we stop. When g=1 we allow one retry to run iterations again after overshooting from the current I%.

I assumed when you say overshoot, it means f changes sign.

No. See code of the termination test. It's when the magnitude of npmt increases rather than monotonically drops in magnitude. Sign is completely ignored. Sign changes are fine and can happen as an overshoot, but that can be an overshoot that is not necessarily detrimental. It can be auto-corrected and often will.

I don't understand why sign change should be treated differently. In fact, I initially tried your suggestion to take sign changes into account in the termination test. But the experimental results were worse for several tests in C double precision and on a 10 BCD calculator. The npmt sign can flip due to overshooting, but it is not necessarily bad and we should never stop right after the sign flips as was shown in the HP-71B code. It can be auto-corrected. So we want to keep iterating. This put me on the wrong path and I eventually dropped it from the termination tests.

(06-19-2024 12:20 PM)Albert Chan Wrote:
Quote:- if the final iteration when we stop y=npmt() is nonzero, then we should pick the previous i%, not the last that overshot.

If previous i% from the outside, overshoot is not really an overshoot, we should keep it.

The term "overshoot" is confusing perhaps. An overshoot is not necessarily bad. I'm talking about non-monotonicity, i.e. when moving away from the root when the npmt magnitude increases. If we move away and we stop when that happens, then experiments show it is better to use the previous i% since we made a bad overshoot. A bad overshoot can be many orders of magnitude away from the root! There are plenty of examples, such as this TVM problem:

n=480 pv=100000 pmt=-208.333333333333343 fv=0
evals=4, i%=-1.39404957469160446e-17%, FVerror=5.4e+05

(06-19-2024 12:20 PM)Albert Chan Wrote: If previous i% from the inside, we don't really know which is better.
All we know is true rate is somewhere between the two.

Yes. For example, I tested the use of a weighted average of i% after stopping with a sign change to judge where the root might be. But it didn't help to improve the result. Experimenting with this showed that taking the previous i% appears to reduce errors in i%. There is no theoretical argument why this should be bad. After all, it all is part of the solving sequence of points. But taking the last value when things go haywire is sure to be terrible. See the example above.

(06-19-2024 12:20 PM)Albert Chan Wrote:
Quote:- I'm measuring FVerror to check the TVM model's accuracy with the i% solved, not the i% rate places because some final digits simply don't matter, it's not anomalous.

If i% getting very accurate (error of few ULP's), FVerror probably not that useful
Example, here we compare, for a given rate, calculated PMT vs FV

lua> n,i,pv,pmt,fv = 10,nil,50,-30,80 -- sample #23
lua> i = tvm(n,i,pv,pmt,fv)
lua> for k=0,5 do print(i, tvm(n,i,pv,nil,fv), tvm(n,i,pv,pmt,nil)); i=nextafter(i) end

Code:

-0.36893369874177734 -29.999999999999996 80.00000000000001 -0.3689336987417774 -30.000000000000004 80.00000000000001 -0.36893369874177745 -30.000000000000007 80 -0.3689336987417775 -30.00000000000001 79.99999999999999 -0.36893369874177756 -30.000000000000014 79.99999999999999 -0.3689336987417776 -30.00000000000002 79.99999999999997

Since rate search is solving npmt=0, it look like our solved i is good, so does (i+1ULP)
Using Plus42 for reference, true rate is (i+0.87ULP) = (i+1ULP) - 0.13 ULP

But from FV numbers, true rate = (i+2ULP)

I am not suggesting PMT_error is better test than FV_error.
It is just that solved i is too accurate for these tests to work.

Perhaps FV error, or PV error (also when "time reversed") or PMT error are all OK. When testing dozens of TVM cases I saw that FV error is more sensitive to an i% deviation.

By contrast, comparing i% digits to a higher precision i% solver is not meaningful when finding "better" values with a lower precision solver is impossible both theoretically and practically. A solver should just do its job well enough to limit the TVM model error to ensure TVM computations are reversible in most cases. Getting 1 or 2 ULP error in the other TVM parameters after solving to is attainable and should suffice to maintain TVM model equilibrium.

(06-19-2024 12:20 PM)Albert Chan Wrote:
Quote:- for termination test I use for the Secant, Newton and Hybrid implementations:

Code:

} while (y != 0.0 && fabs(y) < fabs(w)) } while (y != 0.0 && y != w && g-- > 0);

From wrong guess, we don't know if y is always improving (toward 0).
Unless your guesses are from the outside, (fabs(y) < fabs(w)) is probably wrong.

There is no sign change test to stop at, so starting inside/outside shouldn't matter as much. We can't control the error in the slope to avoid a sign change in the first place. It will happen. The fabs(y) < fabs(w) was also in your code, so...

(06-19-2024 12:20 PM)Albert Chan Wrote:
Quote:... Newton's derivate expression has subtle evaluation errors that get worse as we get closer to the root.

Since both Newton and Secant are self-correcting, we can simply look at last 2 points.
With 2 points close together, Secant's slope is going to be much worse than Newton's.

How? I don't see it in the experiments. You're assuming the two point npmt values have errors in different directions. Then it is worse. But expression evaluation errors in two close points are highly correlated, not independent. Claiming Secant is going to be much worse in general, i.e. assuming these errors are independent, is a stretch.

Furthermore, if the two points are very close so that expression evaluation for the two points return the same npmt value, then we should stop because the two points are very close to the root numerically and we can pick either point. Let me also add that self-correcting can also mean over-correcting when the correction suffers from inaccuracies, which the Newton derivative is not immune to, far from it

(06-19-2024 12:20 PM)Albert Chan Wrote: With both methods use the *same* f, and Newton get better f', I would think Newton is better.
Of course, final f is tiny, and not very accurate. Perhaps more accurate f' make no difference.

I never said Secant is better than Newton. All I'm saying is that the Hybrid appears to be a promising approach (see code and results in the PDF). I'm not sure why you seem so skeptical when the evidence is there using a set of TVM problems I took from the HP forums (i.e. unbiased). Try the code if you don't believe the numbers.

I'm not completely happy about the iguess() (it's your guess_i() code by the way), which works fine in END mode, but is not as good in BEGIN mode. It also can return an overflow >100% causing NaN. I can replicate your symbolic derivation and understand it, but inserting a BEGIN mode adjustment that requires i% itself that we want to guess is something to figure out.

EDIT: I don't use "time reversal" when testing TVM rate solving, because I want to test and compare the solvers on whatever inputs are given, not on modified input that suits the solver. After all, the TVM problems are meant to test TVM rate solving under strain.

- Rob

EDIT: fixed typo