[Free42] root finder

[Marcio]

I have been playing with the Free42 app lately and must say it's of superb quality. The option to change GUI is also top-notch.

Anyway, while programming it to find zeros of equations, I noticed something interesting:

On page 184 of the 15C's user guide, one can find the following equation:
\[h = 5000\left(1-e^{-t/20}\right)-200t \]
which is solved for \(t\) when \(h=0\). The 15C manual recommends 5 and 6 as initial estimates. In fact, if the estimates are smaller than 4, it will converge to zero (which is also correct), and that was when I suspected Free42's solver was keeping some sort of cache. No matter what other values I entered for \(t\), the app wouldn't find the the root for \(t>0\), which is 9.2843...

A work-around is to integrate the function (ie the program), which somehow clears the "cache", and then solve for \(t\) again.

Is this a feature or an oddity/bug? Or did I miss something?

Thanks.

[Gerson W. Barbosa]

(06-15-2016 12:23 AM)Marcio Wrote:  On page 184 of the 15C's user guide, one can find the following equation:
\[h = 5000\left(1-e^{-t/20}\right)-200t \]
which is solved for t when h=0.

That's a job for WP 34S and its buit-in Lambert W function:

5 ENTER 4 +/- / f e^x RCL* L Wp 20 * 25 + --> 9.284255087576332994076124612599270

Not the answer to your question, sorry, but at least 34 digits for you to check upon the Free42 result :-)

[Dieter]

(06-15-2016 12:23 AM)Marcio Wrote:  Is this a feature or an oddity/bug? Or did I miss something?

What exactly did you do? Please give provide every single step and key you pressed.
How did you enter the two initial guesses?

Dieter

[Marcio]

This is the program, quite straight-forward, no optimization attempt:

Code:

LBL "BALL"
MVAR "T"
RCL "T"
+/-
20
/
EXP
+/-
1
+
5000
x
RCL "T"
200
x
-
RTN

Free42 requires one estimate only. I tried a bunch of them now (2,3,4,5) and couldn't replicate the problem I had last night. However, if you enter T as 0.25, Free42 will return a *very* small value, which we assume to be zero. After this, Free42 will give the correct answer for t >0 if t is greater than 3*, sometimes greater 9. I will have to elaborate on this. If you keep playing with it, you will notice this "minimum" value required for the estimate to work changes. I suspect some kind of non-deterministic algorithm is being called here.

Once it finds the root for t>0, which is 9.2843... it won't converge to 0 zero again unless the estimate is also zero. That is when you can't do anything further and some sort of "reset" on the solver is necessary so that other roots (different from 0) can be found. A simple integration will do the job.

*The 15C's solver is even less tolerant and demands the estimates be greater than 5.

[Dieter]

(06-15-2016 01:39 PM)Marcio Wrote:  This is the program, quite straight-forward, no optimization attempt:

OK. An optimized version would of course use e^x–1. ;-)

(06-15-2016 01:39 PM)Marcio Wrote:  Free42 requires one estimate only.

And here is the reason for your problem.

Free42 should behave like a real 42s. And a real 42s uses a solver algorithm similar to earlier versions, which in turn require two guesses (or at least two that bracket the root are recommended).

After starting the solver and selecting the program to solve, you enter two (!) guesses by pressing the T menu key. For instance 1 [T], then 10 [T]. A third [T] then starts the calculation and returns the root.

If you only provide one single guess the solver seems to take the initial value of T (which is also displayed) as the other guess. If this value happens to be zero and you enter e.g. 3 or 5 or 10 as the now actually second guess, the solver runs with these two initial estimates. Since T=0 solves the equation, this result is returned immediately – regardless which other T estimate you provided. A solution has been found and so it is returned.

Try storing 0 in variable T. Start the solver. Enter 10 as only (but actually second) guess. Press [T] again to start the calculation. It will return 0 (the previous content of T) which immediately solves the equation. Although the second guess 10 is close to another root.

Now store 1E-6 in T. Start the solver again, enter 10 as (only, but second) guess, press [T] and get T=9,284255...

Or simply do it the way it was intended by HP: Start the Solver, enter two (!) guesses for T (e.g. 1 [T] 10 [T]), press [T] again without any entry, and get T=9,284255...

There always is a second guess. It's up to you to set it so that it fits your needs, or use the (random) content the solver variable happens to hold (producing more or less random results).

(06-15-2016 01:39 PM)Marcio Wrote:  Once it finds the root for t>0, which is 9.2843... it won't converge to 0 zero again unless the estimate is also zero. That is when you can't do anything further and some sort of "reset" on the solver is necessary so that other roots (different from 0) can be found. A simple integration will do the job.

Maybe you now realize why this happens. Once the root at T=9,28 has been found, this is the content of variable T. In subsequent runs of the solver you may enter any other value as the (second) guess you like – the solver has 9,28 as one of the estimates, this solves the equation, and so it is returned. This may change only if you enter another root like T=0. This also solves the equation, so this time T=0 is returned.

No integration or other "reset" is required. Just provide two guesses. Or only one while you realize that there already is a second one (the one in variable T) that influences the result.

(06-15-2016 01:39 PM)Marcio Wrote:  *The 15C's solver is even less tolerant and demands the estimates be greater than 5.

I cannot reproduce this. On my 15C emulator estimates of 1 and 10 or 2 and 8 (although they do not bracket the solution) return the larger root at 9,28.

Dieter

[Marcio]

(06-15-2016 07:18 PM)Dieter Wrote:  

(06-15-2016 01:39 PM)Marcio Wrote:  Free42 requires one estimate only.

And here is the reason for your problem.

Free42 should behave like a real 42s.

You're right.
I think it's more of an oddity than a bug. The 35s also requires only one guess and the minimum seems to be between 4 and 5. If it is 3, the 35s will return zero "exactly" instead of a very small number.

(06-15-2016 07:18 PM)Dieter Wrote:  

(06-15-2016 01:39 PM)Marcio Wrote:  *The 15C's solver is even less tolerant and demands the estimates be greater than 5.

I cannot reproduce this. On my 15C emulator estimates of 1 and 10 or 2 and 8 (although they do not bracket the solution) return the larger root at 9,28.

Dieter

I'm sorry, I meant greater than 4. Try with 3 and 4 as guesses and the 15C will return a very small number which is interpreted as zero.

Thank you for your time and effort.

[Dieter]

(06-15-2016 09:12 PM)Marcio Wrote:  You're right.
I think it's more of an oddity than a bug. The 35s also requires only one guess and the minimum seems to be between 4 and 5. If it is 3, the 35s will return zero "exactly" instead of a very small number.

The 35s behaves exactly like the 42s in this regard. It uses two (2) guesses, where one is the value in the variable and the other is in X. When used in a program, the 42s solver does it exactly the same way. So on the 35s you would type 1 [STO][T] 10 if you want to start with 1 and 10, and then SOLVE T.

Of course you can always enter just one guess, or even nothing at all. Then the calculator uses what happens to be stored in the variable (T) and in X. I don't think this is a good idea.

(06-15-2016 09:12 PM)Marcio Wrote:  I'm sorry, I meant greater than 4. Try with 3 and 4 as guesses and the 15C will return a very small number which is interpreted as zero.

I think this is perfectly OK. There are two roots at 0 and 9,28. If you enter two guesses that are closer to zero the calculator returns this root, otherwise the other one.

Dieter

[Dieter]

(06-15-2016 01:31 AM)Gerson W. Barbosa Wrote:  Not the answer to your question, sorry, but at least 34 digits for you to check upon the Free42 result :-)

If the 34s still uses my Lambert's W code I can say that it usually gives 30+ digits, but not always all 34 can be considered correct. That's almost impossible with the same 34 digit working precision. ;-)

In this case the result you posted is less than 3 ULP off, so 33 out of 34 digits are correct.

Dieter

[Marcio]

Dieter,

You won, hands down.
Let's hope Thomas implements the second guess so this "cache" oddity disappears.

Thank you a million for the clarification.

[Dieter]

(06-16-2016 03:04 PM)Marcio Wrote:  Let's hope Thomas implements the second guess so this "cache" oddity disappears.

I do not think there is a "cache oddity". And of course the second guess is already implemented in Free42.

I don't know which version of Free42 you use, but everything I wrote was tested with Thomas Okken's Free42 Decimal v1.5.5 for Windows. It behaves just as the real thing. After starting the Solver and selecting the program to solve, simply enter the two guesses one after another. Enter first guess, press the "T" softkey, enter second guess, press the "T" softkey again. A third "T" then starts the solving algorithm and returns the root. Exactly as it is described in chapter 12 of the 42s manual.

Does your version behave differently?

Dieter

[Marcio]

No. Missed that detail.

[Thomas Okken]

The root finder in Free42 is supposed to behave just like the one in the real HP-42S, at least as far as starting guesses are concerned. (The actual numerical root-finding algorithm is a different matter.)

There are two modes of operation: using the SOLVER application menu interactively, and using the programmable SOLVE function.

When using the SOLVER application menu: you can provide up to two starting values by entering numbers and pressing X (I'm just going to say X to refer to the menu key that represents the variable you're trying to solve for.) When you try to solve without providing any starting values, the solver starts with 0 and 1; if you provide one starting value, only that value will be used (in other words, the two starting values are initialized to the same number); and if you provide two starting values, of course those two are used.

You provide two starting values by entering <value 1> X <value 2> X; while nominally the X menu key performs STO "X", the SOLVER menu actually keeps track of two values by saving whatever previous value was in the variable in an invisible "shadow" variable.

When you use the SOLVE function, the starting values are X (the variable) and the contents of the X register, or, if the variable X doesn't exist yet, the starting values are 0 and the X register.

When the solver finds a root, it sets the X variable to that root.

Now, the problem that got this thread started: if you want to find a *different* root, and provide only one new starting value, the solver will probably immediately return the root that it had found before, because it uses that as one of the starting values for the new run: when you enter the new starting value, the old value of the X variable is copied to the above-mentioned "shadow" variable, and will be used as a starting value.

So, if you want to find a different root, enter two new starting values, or if you only have one, enter it twice, and then solve: <number> X ENTER X X (using the SOLVER menu) or <number> STO "X" SOLVE "X" (programmatically).

All of this is supposed to behave just like on the original HP-42S; this logic hasn't changed since version 1.0. I'm pretty sure it is correct, or surely someone would have said something in the 11+ years since 1.0, but if there is a use case where Free42 doesn't handle starting values like the HP-42S, please let me know!