wp34s SLV questions « Next Oldest | Next Newest »

 ▼ Norman Dziedzic Member Posts: 203 Threads: 29 Joined: Nov 2009 04-23-2011, 04:19 PM 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. ▼ Gene Wright Posting Freak Posts: 1,545 Threads: 168 Joined: Jul 2005 04-23-2011, 05:41 PM 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. :-) ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 04-23-2011, 07:39 PM 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. ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-23-2011, 08:04 PM Maybe I should put this short program into flash and introduce a command to invoke it :-) - Pauli ▼ Walter B Posting Freak Posts: 4,587 Threads: 105 Joined: Jul 2005 04-24-2011, 02:25 AM The next build will include a function SLVQ solving quadratic equations :-) Walter Norman Dziedzic Member Posts: 203 Threads: 29 Joined: Nov 2009 04-24-2011, 08:53 AM 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. ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-24-2011, 09:01 PM 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 ▼ Gene Wright Posting Freak Posts: 1,545 Threads: 168 Joined: Jul 2005 04-24-2011, 09:45 PM 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. ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-24-2011, 10:24 PM I can guarantee that the integration isn't going to deal with badly behaved functions very well. It isn't an adaptive method. - Pauli ▼ Gene Wright Posting Freak Posts: 1,545 Threads: 168 Joined: Jul 2005 04-24-2011, 10:53 PM 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!) ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-24-2011, 11:06 PM 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 Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 04-23-2011, 06:37 PM 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 ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-23-2011, 07:26 PM 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 ▼ Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 04-24-2011, 07:25 AM 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. ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-24-2011, 07:46 AM 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 Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-23-2011, 07:52 PM 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 ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 04-23-2011, 08:45 PM 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.

 Possibly Related Threads... Thread Author Replies Views Last Post [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 429 10-04-2012, 04:59 PM Last Post: Paul Dale WP34S V3 : STATUS questions Miguel Toro 4 547 12-30-2011, 11:12 AM Last Post: Marcus von Cube, Germany [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,670 12-06-2011, 11:07 AM Last Post: Namir [wp34s] Romberg Integration on the wp34s Les Wright 2 540 12-04-2011, 10:49 PM Last Post: Les Wright [WP34S] SLV returns "Failed" when it finds a root just fine. Les Wright 6 728 11-27-2011, 04:31 PM Last Post: Paul Dale [WP34s] Questions about extended precision fhub 7 754 10-28-2011, 05:20 PM Last Post: Marcus von Cube, Germany WP 34s: Trying to understand SLV Miguel Toro 31 2,274 10-23-2011, 03:55 PM Last Post: Miguel Toro A few WP34s questions Cristian Arezzini 8 817 08-13-2011, 05:51 AM Last Post: Walter B Issues with the SLV command in WP34s fhub 1 318 08-08-2011, 06:43 PM Last Post: Paul Dale wp34s 1.17 Build 838 SLV Norman Dziedzic 20 1,549 05-12-2011, 10:18 AM Last Post: Marcus von Cube, Germany

Forum Jump: