WP34S solver question



#16

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.


#17

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


#18

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.


#19

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.


#20

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

#21

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.

#22

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

What makes you think I'm not?
#23

Initial guess 0.001 is too small.Try 0.01.

Damir


#24

It is good enough for all other mentioned calculators.

#25

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


#26

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

So the 34s SLV command is in fact a combined root&pole finder. ;-)

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


#27

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


#28

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.


I'm not so much into the theory, but I can't remember HP solver getting stuck - for the problems I had to solve, or at least in this way (giving -/+90 degrees). Isn't it possible SLV to give up instead?

Cheers

#29

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,


#30

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


#31

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.


#32

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

#33

.
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.


Forget that old article, it's quite nebulous and incomplete and thus can't be used to re-engineer the original HP Solve code.

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.


#34

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


#35

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.


#36

I know that document well :-)


- Pauli

#37

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.


#38

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


Possibly Related Threads…
Thread Author Replies Views Last Post
  hp-prime solver and variable name fabrice48 22 8,570 12-10-2013, 03:25 AM
Last Post: fabrice48
  HP Prime Triangle solver BruceH 29 8,880 11-28-2013, 12:03 AM
Last Post: Dale Reed
  Using units in Numeric Solver Harold A Climer 1 1,306 10-13-2013, 10:44 AM
Last Post: Tim Wessman
  Does Prime Have a Multiple Equation Solver? Norman Dziedzic 2 1,429 09-20-2013, 09:43 AM
Last Post: Norman Dziedzic
  Just a lazy solver algortihm PGILLET 1 1,120 06-28-2013, 11:47 PM
Last Post: Namir
  Simple? programming question [WP34S] Shawn Gibson 3 1,500 03-15-2013, 11:56 AM
Last Post: Didier Lachieze
  [43s] : How the solver will be implemented Miguel Toro 3 1,655 03-14-2013, 06:09 PM
Last Post: Walter B
  [wp34s] xtal question jerome ibanes 9 3,056 02-05-2013, 05:35 PM
Last Post: Massimo Gnerucci (Italy)
  TVM-Solver for the PC fhub 14 4,171 12-26-2012, 03:24 PM
Last Post: fhub
  [WP34s] New TVM-solver version fhub 43 11,135 12-26-2012, 06:12 AM
Last Post: fhub

Forum Jump: