I noticed strange behaviour of the SLV function. Long story short:

comparing WP34S and (HP15C):

calculator in RAD mode, FIX 9;

formula: 2*R(tan(D) - D) - L = 0

34S:

LBL D

TAN

RCL- L

RCL* A

2

*

RCL- B

END

15C:

LBL D

TAN

LSTx

-

RCL* 0

2

*

RCL- 1

RTN

R = 6,371,000 in r.A(0)

L in r.B(1)

initial guesses: 0 ENTER 0.001;

L = 1; 

     34S               15C

-1.570796327       0.006174837

L = 0.1; 

     34S               15C

-1.570796327       0.002866172

L = 0.01;

     34S               15C

1.570796327       0.001330163

L = 0.001; 

     34S               15C

0.000617487       0.000617410

HP48G (and identically HP35S) and HP42S (Free 42) give similar to 15C, right within accuracy answers.

Am I missing something?

Timing is also interesting. 15C takes almost constant time unlike the 34S.

Edited: 12 July 2012, 8:27 a.m.

Not sure you are aware of: L is the LASTx register of the WP 34S.

Initial guess 0.001 is too small.Try 0.01.

Damir

The lack of dedicated stack registers is one of the few weaknesses of the WP 34s, IMHO. The user should not worry about not using these forbidden alpha registers for whatever purpose. No problem LastX occupying a position on the keyboard, ./, could gladly go away.

Easy rule: use numbered registers -- keep off the lettered registers! Unlike many Pioneers, the WP 34S doesn't feature lettered registers beyond the stack and specials. Please see p.23 of the manual.

Sorry! I'll be patient and wait for the wp43s :-)

L is used correctly as lastX here. A and B may only be used as general registers if the stack size is set to 4, not 8. Even if the solver itself runs with the stack size fixed at 4, this is not true for the called function which uses whichever stack size is set by the user.

It is good enough for all other mentioned calculators.

Quote:

---

Not sure you are aware of: L is the LASTx register of the WP 34S.

---

Quote:

---

comparing WP34S and (HP15C)

---

Don't. The algorithms used underneath are very different.

In order to get faster convergence, the 34S is using more advanced algorithms than HP's solver. HP's solver is a guarded secant from my understanding whereas the 34S uses this plus quadratic and Ridder's steps.

The 34S is finding a pole rather than a root which is unfortunate but by no means impossible with either solver.

- Pauli

Quote:

---

The 34S is finding a pole rather than a root which is unfortunate but by no means impossible with either solver.

---

Won't it be possible to check for a pole with the following method:

If for the last iterations xk,xk+1,... the values |f(xk)|,|f(xk+1)|,... are increasing (instead of decreasing), then it must be a pole instead of a root.

Franz

That might work but leaves the questions:

• How to know for sure that there isn't a solution in the interval?
  
• How to sensibly look elsewhere?
  

The solver is being trapped because f(a) > 0 and f(b) < 0. For a continuous function there must be a root between a and b (by the intermediate value theorem). The solver can't just blindly abandon the search because the absolute value increased or it will miss legitimate roots.

HP's solver can and does get stuck in exactly the same way when it encounters a zero crossing discontinuity.

Still, there seems to be some scope for improvement here.

- Pauli

Thanks for the explanation, I suspected so... Apparently I got fouled by the way SLV is used as described in the manual and the reference to the HP15C. Never the less, I'd prefer the old working horse, never had such problems with it.
Cheers,

Quote:

---

HP's solver can and does get stuck in exactly the same way when it encounters a zero crossing discontinuity.

Still, there seems to be some scope for improvement here.

---

Cheers

If I had the code for the old solver, I'd likely have just implemented it identically. Unfortunately, HP's code isn't available.

- Pauli

Quote:

---

Unfortunately, HP's code isn't available.

---

Sure, but would Prof. Kahan's article help in any way?

Hewlett-Packard Journal December 1979

"Personal Calculator Has Key to Solve Any Equation f(x) = 0" starts at page 20.

Gerson.

I read through that article multiple times :-) It is good and I do do most of what is written about but it isn't quite complete I think.

Regardless, if someone wants to do work on the solver it would be appreciated. The code is: solve.wp34s.

- Pauli

.
Hi, Gerson:

Quote:

---

Sure, but would Prof. Kahan's article help in any way?

Hewlett-Packard Journal December 1979

"Personal Calculator Has Key to Solve Any Equation f(x) = 0" starts at page 20.

---

I suggest you peruse instead this much more complete, 63-page PDF document, somewhat heavier on the math side but then it's the real thing, not a brief article:

Lecture notes on Real Root-Finding

Have a nice weekend and best regards from V.

I don't mean to add controversy and this is probably not useful anyway, but the HP code (at least the Advantage's MCODE) *is* available - as long as one doesn't mind a bit of reverse-engineering.

If you remove all the Buffer#14 handling routines it's a sizable but relatively understandable task.

FWIW, feel free to ignore it and persue a new approach. After all it may also flunk with the same example,- I didn't try it but being based ont he 15C I guess it won't.

Cheers,
ÁM

Edited to add: tried the example in question and not surprisingly it yields the same results as the 15C.

Edited: 13 July 2012, 3:10 p.m.

Thanks for this far more up to date reference. I hadn't seen it.

I'm not in the least bit scared of a bit of heavy mathematics :-)

Now to try to find some free time....

- Pauli

I hadn't thought of this possibility, it would give us compatibility. The MATH pack solver is another option I guess.

I'd like to think that there has been some worthwhile progress in automatic solving in the last forty odd years though.

- Pauli

Quote:

---

I'm not in the least bit scared of a bit of heavy mathematics :-)

---

I am. I'm glad Valentin's reference has reached the right audience :-)

Mathematics Written in Sand might also be a good reading.

Gerson.

I know that document well :-)

- Pauli