15c solver



#10

Hi folks,
In the solver instructions for the 15c, it says that the calculator fills the stack with the trial value of X, so that it's always available to be used in the calculation. But, what if my equation uses all four stack registers at some point...would that not push the trial value of X off the top of the stack? Would it not also work to save the trial value of x to a register as the first step in my subroutine, as then recall it as necessary?
Your thoughts and advice appreciated.
Hal


#11

But, what if my equation uses all four stack registers at some point...would that not push the trial value of X off the top of the stack?

Absolutely.

Would it not also work to save the trial value of x to a register as the first step in my subroutine, as then recall it as necessary?

Yes, that's the easiest way of coping with the limited stack space issue. If I remember correctly, the HP-15C solver maintains all its internal state in "invisible" registers, so you're free to use the numbered registers any way you wish. (I'd have to check the manual to make sure.)

- Thomas


#12

Hi Thomas, Hal, folks;

you are right, Thomas, the HP15C´s SOLVE does not use any of the available numbered registers, so they can be used when the HP15C is 'solving'. Anyway, the internal [SOLVE] procedure uses 23 registers that must be available in the so called 'common segment' part of the user memory, meanning that if it does not have at least 23 registers available in this segment, it cannot perform [SOLVE]. The same happens with integration, but it uses only 5 registers (if SOLVE and INTEGRATE are used with each other, only 23 registers). The HP34C used 'hidden registers', meanning it could integrate or solve anytime, even if there were no free registers at all.

About the stack being filled with the current probable root. In the HP34C, the value to be tested as root was returned to the X-register only, so if the function to be solved used it many times, as in a polynomial expression, the first steps in the routine with the 'to be solved' function might save a copy of it prior to compute F(x). The HP15C [SOLVE] is able to find one root at a time and it must be related to one variable only. It´s been shown a technique here some time ago (a couple of years, maybe more) where the variable to be solved could be changed thru the index register instead of changing the whole program, but I do not rememeber if it was post as an article. Anyway, I for one believe that the stack filled with the guessed root is a good technique when the function to be solved uses the (x) value many times, and there are not too many constants; at least I guess that the main concerns here are for constants, right?

Hope this gives you a bit more info.

Cheers.

Luiz (Brazil)


#13

Hi, Vieira:

Luiz posted:

"Anyway, the internal [SOLVE] procedure uses 23 registers [...] The same happens with integration, but it uses only 5
registers"

    Nope. Exactly the opposite. "X<>Y" your 5's and 23's and it'll be Ok.
Best regards from V.

#14

Hi, Valentin;

thanks again! As always, your posts add important info, when not correcting ours. That's what happens when you believe your head's memory contents cannot be corrupted... Oops! This is a 'void' word in Brazil. If the right people read this, I'm in trouble. If the wrong people read this, I'll have my bank account used for 'dirty' purposes... But this is not the subject for this forum.

Again, Valentin, thanks.

Best regards from the Brazilian V(ieira)!

#15

Thanks for the info...
Yes, the large number of constants and the convoluted nature of the equation I'm finding the root for is the main issue. When I keyed it into my 33S's equation storage register algebraically, the thing had 16 sets of brackets! Might I also say at this point that the 33S equation editing function (or lack thereof) stinks!

I'm thinking putting it into a subroutine using RPN will be much easier.

Thanks and best regards, Hal


#16

Yes, the 22s, 32sii, and now 33s equation editor is, well, not an editor...whereas the 17b/19b/27s etc have real editing.

You are correct to stay in RPN (or rather with the 33s) in PRGM mode when doing long oe convoluted equations--as they can be edited without erasing the whole thing!

I feel that the best way to view the "equation list" and "equation mode" of the 32sii/33s is to see it as a nice "bonus" feature rather than a core component. This bonus feature can be used to advantage where you see fit, but has limitations. The programming space is a core feature which can accomplish everything the machine is capable of.

Edited: 3 Apr 2006, 2:35 p.m.

#17

Hi Luiz,

as for the indirect solve...that is a key component of the arsenal that is the 15c---the method was posted here at MoHPC by Karl, some archives back. I have a hard copy of it at home...as it makes the 15c capable of solving for any root in much the same way that the 27s or 19b can.

#18

Hal --

Lots of good info from Thomas, Luiz, Bill, and Valentin to your queries. I'll try to summarize it:

HP-15C solver:

The SOLVE and INTEG functions on the HP-15C were taken directly from those implemented on the HP-34C. These functions load the stack with the current value of the variable to be solved or integrated, as a convenience to the user. Of course the variable can also be saved to a numbered storage register, and taken directly from there in the user-defined function. This technique, using the indirect register, is the basis for using this implementation of SOLVE and INTEG adroitly with multiple-input, single-output (MISO) functions.

The HP-15C requires 5 user-allocatable "common pool" registers to run SOLVE (and 23 to run INTEG, or to run INTEG and SOLVE together). The HP-34C has the same memory requirements for SOLVE and INTEG, but it uses non-allocatable registers that are hidden from the user and cannot be used for data storage or programming.

My discussion of the implementation of SOLVE and INTEG, along with the MISO-function technique, was developed into Article #556 posted in the MoHPC Articles Forum.

HP-33S Equation Editor:

Yes, the lack of full "insert/delete" mode of the HP-33S equation editor is annoying, but it stems from display capabilities and cursor-movement keys that are limited. The equation functionality was originally implemented in the algebraic HP-22S, and transferred to the HP-32SII, which replaced the HP-32S. All the functionality of the HP-32SII was ported to the HP-33, but not much was added. Also, none of these calc's offer the HP-17B/27S/42S high-resolution dot-matrix display that allows softkey menu labels to be displayed on the keyboard.

Bill made a very good point that the equation editor on the HP-33S should be treated as a "bonus", not as a core capability. Long equations can be hard to read, decipher, and edit. Furthermore, any supported capability -- including branching by conditional tests and loops -- can be used in a keystroke program, but not necessarily in an equation. Also, SOLVE and INTEG run faster when using a keystroke program instead of an equation.

-- KS


Edited: 4 Apr 2006, 3:25 a.m.


Possibly Related Threads...
Thread Author Replies Views Last Post
  hp-prime solver and variable name fabrice48 22 4,141 12-10-2013, 03:25 AM
Last Post: fabrice48
  HP Prime Triangle solver BruceH 29 4,169 11-28-2013, 12:03 AM
Last Post: Dale Reed
  Using units in Numeric Solver Harold A Climer 1 639 10-13-2013, 10:44 AM
Last Post: Tim Wessman
  Does Prime Have a Multiple Equation Solver? Norman Dziedzic 2 700 09-20-2013, 09:43 AM
Last Post: Norman Dziedzic
  Just a lazy solver algortihm PGILLET 1 638 06-28-2013, 11:47 PM
Last Post: Namir
  [43s] : How the solver will be implemented Miguel Toro 3 885 03-14-2013, 06:09 PM
Last Post: Walter B
  TVM-Solver for the PC fhub 14 2,128 12-26-2012, 03:24 PM
Last Post: fhub
  [WP34s] New TVM-solver version fhub 43 5,534 12-26-2012, 06:12 AM
Last Post: fhub
  HP-Solver Mike (Stgt) 2 618 10-10-2012, 02:44 AM
Last Post: Mike (Stgt)
  WP34S solver question Reth 22 3,103 07-13-2012, 06:55 PM
Last Post: Paul Dale

Forum Jump: