The Museum of HP Calculators

HP Forum Archive 20

 wp34s SLV questionsMessage #1 Posted by Norman Dziedzic on 23 Apr 2011, 4:19 p.m. While using SLV is it normal that when one of the initial guesses is a root that it returns 0.0 instead of the root? Is the convergence criteria determined by the number of decimals displayed like other calculators? I ask this because answers seem to return very quickly with FIX 1 but goes up drastically with FIX 2. I'm using a simple quadratic 2*x^2-3*x+1 with initial guesses of -1 and 2. Program: ```LBL B STO 99 X^2 2 * RCL 99 3 * - 1 + RTN ``` with FIX 1 I get an answer almost instantly. With FIX 2 it's about 16 seconds? Is this right? Edited: 23 Apr 2011, 4:19 p.m.

 Re: wp34s SLV questionsMessage #2 Posted by gene wright on 23 Apr 2011, 5:41 p.m.,in response to message #1 by Norman Dziedzic Hey Norman. Glad you got the cable! :-) On build 725 in Fix 4, it returns 1 in about 15-20 seconds. With guesses of 0.98 and 1.02, it returns 1 in about 2 seconds. :-)

 Re: wp34s SLV questionsMessage #3 Posted by Gerson W. Barbosa on 23 Apr 2011, 7:39 p.m.,in response to message #2 by gene wright Quote: With guesses of 0.98 and 1.02, it returns 1 in about 2 seconds. :-) While this is not improved, for quadratic equations I would suggest the following: ``` X Y Z T L 001 LBL A c b a T L 002 RCL/ Z c/a b a T c 003 X<> Z a b c/a T c 004 ST0+ X 2a b c/a T c 005 / b/(2a) c/a T T 2a 006 +/- -b/(2a) c/a T T 2a 007 STO Z -b/(2a) c/a -b/(2a) T 2a 008 x^2 b^2/(4a^2) c/a -b/(2a) T -b/(2a) 009 x<>y c/a b^2/(4a^2) -b/(2a) T -b/(2a) 010 - b^2/(4a^2)-c/a -b/(2a) T T c/a 011 SQRT sqrt(b^2/(4a^2)-c/a) -b/(2a) T T b^2/(4a^2)-c/a 012 STO L sqrt(b^2/(4a^2)-c/a) -b/(2a) T T sqrt(b^2/(4a^2)-c/a) 013 x<>y -b/(2a) sqrt(b^2/(4a^2)-c/a) T T sqrt(b^2/(4a^2)-c/a) 014 STO+ Y -b/(2a) -b/(2a)+sqrt(b^2/(4a^2)-c/a) T T sqrt(b^2/(4a^2)-c/a) 015 RCL- L -b/(2a)-sqrt(b^2/(4a^2)-c/a) -b/(2a)+sqrt(b^2/(4a^2)-c/a) T T -b/(2a) 016 RTN keystrokes display 2 ENTER 3 +/- ENTER 1 A 0.5 (instantly :-) x<>y 1 ``` Edited: 23 Apr 2011, 7:41 p.m.

 Re: wp34s SLV questionsMessage #4 Posted by Paul Dale on 23 Apr 2011, 8:04 p.m.,in response to message #3 by Gerson W. Barbosa Maybe I should put this short program into flash and introduce a command to invoke it :-) - Pauli

 Re: wp34s SLV questionsMessage #5 Posted by Walter B on 24 Apr 2011, 2:25 a.m.,in response to message #4 by Paul Dale The next build will include a function SLVQ solving quadratic equations :-) Walter

 Re: wp34s SLV questionsMessage #6 Posted by Norman Dziedzic on 24 Apr 2011, 8:53 a.m.,in response to message #2 by gene wright Gene, I should have sent you a thank you for the cable. "Thank You" I wrote my PGM that way because I didn't know exactly how the solver worked but I knew if I stored the value in a register, then no matter how it worked my PGM would work. I don't have a 15C nor a manual for one so the reference in the wp34s manual didn't give me any guidance. But really, I was just playing around and the main thing was that I had expected a result in less than a sec. And, looks like I found some anomalies that are being fixed. Quadratic solver sounds like a good addition.

 Re: wp34s SLV questionsMessage #7 Posted by Paul Dale on 24 Apr 2011, 9:01 p.m.,in response to message #6 by Norman Dziedzic Quote:But really, I was just playing around and the main thing was that I had expected a result in less than a sec. And, looks like I found some anomalies that are being fixed. I guessed as much. They aren't being fixed, they are fixed in subversion. We need a lot more testing to find the rough spots (of which I'm sure there are many). - Pauli

 Re: wp34s SLV questionsMessage #8 Posted by gene wright on 24 Apr 2011, 9:45 p.m.,in response to message #7 by Paul Dale No worries on thanks for the cable. Join the party now. I'll be trying the integration stuff shortly. All of the examples from the PPC rom should be tested, for sure.

 Re: wp34s SLV questionsMessage #9 Posted by Paul Dale on 24 Apr 2011, 10:24 p.m.,in response to message #8 by gene wright I can guarantee that the integration isn't going to deal with badly behaved functions very well. It isn't an adaptive method. - Pauli

 Re: wp34s SLV questionsMessage #10 Posted by gene wright on 24 Apr 2011, 10:53 p.m.,in response to message #9 by Paul Dale Probably dumb question... has the integration code been published and how much room is left if someone suggests an improvement? (which is not likely to be me!)

 Re: wp34s SLV questionsMessage #11 Posted by Paul Dale on 24 Apr 2011, 11:06 p.m.,in response to message #10 by gene wright Quote:Probably dumb question... has the integration code been published Of course. In subversion there is a version in library/integrate.txt and the actual code that is used internally is in trunk/xrom.c. Quote:how much room is left if someone suggests an improvement? As much as is required. This is a sufficiently important function that we'll remove other things to ensure it fits in. If required, we can also partially merge the code into C as has been done with solve. What we are short of is registers for the integrator to use. Five are currently dedicated and we could squeeze a sixth out of RAM. A seventh is when things would get very difficult. Unfortunately, we've got to use non-volatile RAM for these. - Pauli

 Re: wp34s SLV questionsMessage #12 Posted by Dieter on 23 Apr 2011, 6:37 p.m.,in response to message #1 by Norman Dziedzic Solve should work independent from the display setting. But I wanted to mention another point: you have stored x in R99 in order to recall it a second time later in the formula. This is not necessary - the whole stack is filled with x, so you can recall it anytime you like from there. However, "real cowboys" of course would use the Horner scheme here - it's virtually made for RPN calculators: ``` conventional Horner approach scheme   LBL B LBL B X^2 2 2 * * 3 X<>Y - 3 * * 1 - + 1 RTN + RTN ``` BTW - on the 35s it takes not much more than a second to obtain the result x = 1 from the initial guesses -1 and 2. Since the 20b and 30b are blazingly fast compared to the 35s, it sounds like something does not work the way it is supposed to. But let's wait for the software specialists. ;-) Dieter

 Re: wp34s SLV questionsMessage #13 Posted by Paul Dale on 23 Apr 2011, 7:26 p.m.,in response to message #12 by Dieter Quote:Solve should work independent from the display setting. No. Solve iterates until successive estimates are the same based on the display setting. It uses the x[approx]? conditional test. This is the same as HP's solve has always done (i.e. from the 34c onwards). Quote:the whole stack is filled with x, so you can recall it anytime you like from there. Again no. X, Y, Z and T are filled with the estimate. If you are using an eight level stack then A, B, C & D aren't filled. Is anyone using an eight level stack? Quote:BTW - on the 35s it takes not much more than a second to obtain the result x = 1 from the initial guesses -1 and 2. Since the 20b and 30b are blazingly fast compared to the 35s, it sounds like something does not work the way it is supposed to. But let's wait for the software specialists. ;-) Try putting a short pause at the start of the routine and watching the successive estimates to see what is going on :-) The only way I could see this taking a long time is if the initial estimates cause a wild divergence from the true solution which then has to be found anew. If your initial estimates bracket the solution, this can never happen. The returning zero for an initial guess of the root is wrong and will be fixed. It should return the guess -- probably just some stack management gone awry. For those who are interested, sample source code for the solver is in the top level library folder in subversion. The real source is in xrom.c in trunk and this is ever so slightly different. - Pauli

 Re: wp34s SLV questionsMessage #14 Posted by Dieter on 24 Apr 2011, 7:25 a.m.,in response to message #13 by Paul Dale Quote: Quote: Solve should work independent from the display setting. No. Solve iterates until successive estimates are the same based on the display setting. It uses the x[approx]? conditional test. This is the same as HP's solve has always done (i.e. from the 34c onwards). I beg to differ. The Solve-implementations I know of return a full precision result at any display setting (as opposed to Integrate, here the display setting matters). As far as I remember the 34C manual even suggests a method to cut down solving times by rounding the result at the end of the function call (return zero if the result is small enough). The display setting really does not matter here. Which, in most cases, is a good idea, I think. However, I also like the idea of additional user control offered by changing the display setting. ;-) The 34s manual says the user interface is the same as in the 15C. That's why I said Solve should work independent from the display setting. Obviously it doesn't. So I think either the manual or the algorithm should be changed. You mentioned the X~= test in the 34s. I think this is an interesting feature... once you know how it works exactly. ;-) The manual says it tests true if the rounded values agree. So at FIX 4, for example, 1E-5 and 1E-10 would test true as they are both rounded to zero? Dieter Edited: 24 Apr 2011, 7:27 a.m.

 Re: wp34s SLV questionsMessage #15 Posted by Paul Dale on 24 Apr 2011, 7:46 a.m.,in response to message #14 by Dieter Quote:I beg to differ. The Solve-implementations I know of return a full precision result at any display setting (as opposed to Integrate, here the display setting matters). Now you know one that does :-) Maybe I was misremembering integrate when I did this. Changing from approximately zero to exactly zero is easy. Which is better here? Our integrate doesn't depend on the display setting, it uses a fixed Gauss/Kronrod quadrature. Fast, small and a limited number of registers required. Quote:You mentioned the X~= test in the 34s. I think this is an interesting feature... once you know how it works exactly. ;-) The manual says it tests true if the rounded values agree. So at FIX 4, for example, 1E-5 and 1E-10 would test true as they are both rounded to zero? Try it and find out :-) Fortunately, the full source code is available so you can work out exactly how it works if you need to and far better than the manual could explain. - Pauli

 Re: wp34s SLV questionsMessage #16 Posted by Paul Dale on 23 Apr 2011, 7:52 p.m.,in response to message #1 by Norman Dziedzic The bad stack when an initial guess is correct has been fixed and will be in the next build. A roll up fixes things for a 4 level stack. The slowness to converge is as I suspected, the estimates send the solver wandering around due to the secant step. - Pauli

 Re: wp34s SLV questionsMessage #17 Posted by Paul Dale on 23 Apr 2011, 8:45 p.m.,in response to message #16 by Paul Dale I've forced a bisection step to occur if the two initial estimates are both on the same side of zero. This should stop the solver drifting far away from the solution here and having to work hard to get back. - Pauli Edited: 24 Apr 2011, 12:51 a.m.

Go back to the main exhibit hall