Hi, John;
first of all, you should express the expression to be solved in terms of a program, with a unique label in memory and a RTN as its last step (no [R/S] because it would stop SOLVE execution after a first scan, as well). The RTN is not necessary if the program is the last program (or the only one) in memory.
Consider that your program uses the stack information as the estimative for your reference variable, the one that the expression must be solved for. The SOLVE internal routine samples your program with the given estimates, so it leaves the a copy of the estimated value in all of the four stack registers, as an aid to help writing your program. Like this: solve the following equation for x.
y=x^32×LN(ABS(x)+1)A possible program that represents this expression could be:
f LBL 0As you can see, we consider that a copy of the estimated x is available in all of the four stack registers.
3
y^x
x<>y (x xchange y)
g ABS
1
+
g LN
2
×

g RTN
After loading this program, enter two initial guesses (separated by [ENTER]) where the program should start searching for a root and press
f SOLVE 0The [0] after f [SOLVE] means the SOLVE routine will search for a LBL 0 and sample it till it returns a zero.
If the root is not in the range you suggest, chances are that the SOLVE routine finds it anyway.
Hope this helps for now. If you need further advice, let us know.
Best regards and success.
Luiz (Brazil)
Edited: 15 Aug 2005, 12:52 p.m.
Hello, Luiz 
Your example for John was actually a tough equation to solve, and especially for the HP15C! Was that intentional? He might be disappointed in the performance of his fine HP calculator...
y=x^32×LN(ABS(x)+1)
This equation has solutions for y = 0 at x = 0 and x = 1.153299. There is a local minimum of y = 0.727258 at x = 0.637971. The solution at x = 0 is also a local maximum.
However, the solution at x = 0 is difficult for the HP Solve routine to obtain, because of the characteristics of equation's absolute value and natural logarithm functions at or near that point.
The slope dy/dx of the equation is
3x^{2}  2/(x+1) for x > 0
3x^{2}  2/(x1) for x < 0
So, the slope is +2.00 for x = 0, and 2.00 for x = 0+, and not defined at x = 0.
The 15C could obtain the solution at x = 1.153299 with certain choices of first guesses (including 0.1 and +0.1), but unsuccessfully tried to "home in" on x = 0 for first guesses near, but straddling 0. "Error 8" (NO ROOT FOUND) would result for some other choices.
The HP32S and HP32SII did better at obtaining the root at 0, but also tended to find the other root.
 KS
Edited: 18 Aug 2005, 2:04 a.m.
Hi, Karl;
thank you for your comments. You`re right about the equation, but I did not mean to show such a 'darn' example... I actually did not take much care about the equation behavior, though.
I thought about an example were programming skills would be needed and I wrote the expression solely based on programming. I added 'ABS' and '+1' to avoid forbiden conditions, but I was aware of poles as I used 'x^3' and 'LN'.
After writing and loading the program from the equation, I ran it twice, first with x=1 and then with x=2. As the y values returned with reversed signal, I ran the SOLVE with 1 and 2 as initial estimates. After a few seconds, the 1.1533 was shown in the display.
I was waiting for John's comments and feedback so I'd explain why I used such example. Now I see that I could use a better, more reasonable (and perhaps more generous) one. Anyway, now that you added such detailed analisys, I think my 'not so good' choice served with another purpose, instead.
Thanks, Karl. I myself added some of your considerations to my own after reading your post. I understood and, in fact, am aware of them, I actualy was lazy enough not going ahead as you've gone. My bad...
Best regards.
Luiz (Brazil)
Luiz 
Yes, indeed, your problem was (unintentionally?) revealing about the behavior of HP Solve on several RPN calc's. I'll try it on an RPL model or two.
The solution at x=0 lies in the "crook of a roofpeak", and the 15C/32S/32SII tend to approach the solution asymptotically, in eversmaller increments, if they don't give up first. Solutions are readily obtained if a positive offset is added to the equation (say, 0.2). Then there are three solutions for the equation.
BTW, have you tried out my updated AC Power Transfer program in the MoHPC Software Library for the 32/33 models? It may be the finest power engineering program ever written for those platforms. (Of course, it's not a real powerflow solver, such as you wrote for the 42S.)
 KS
Hi, Karl;
you wrote:
Quote:You bet I did not intend to! d8^)
Yes, indeed, your problem was (unintentionally?) revealing about the behavior of HP Solve on several RPN calc's.
Now for the oter facts: thanks for telling me about the AC Power Transfer with the HP32/33. I have not been visiting the library for a while, now I have a good reason to go there. About the HP42S, you brought to my mind that I still need to correct the output of my Load Flow program for the HP42S. Now that I have a 32K RAM HP42S, I'm gonna test it with a large array... I remember solving a 10line power array with the original 8K RAM HP42S and it computed the output array correctly, just failled to show it. The original version was 510 steps long, and as soon as I have it working properly I`m posting about it.
I still have the 144step partial listing of a first version writen for the HP41CX (could only build the Ybus). As I bought the HP42S at that time, I ported the program and used the HP42S complex and matrixhandling resources to go ahead with less subroutines and program steps. I wonder if it would have been possible to do what I wanted to in the HP41CX; I mean, if it would be possible to perform all necessary operations to compute the final current array with the HP41CX... I guess so!
Best regards and thanks again, Karl.
Luiz (Brazil)