▼
Posts: 203
Threads: 29
Joined: Nov 2009
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^23*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?
<Build 721 on 30b hardware>
Edited: 23 Apr 2011, 4:19 p.m.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Hey Norman. Glad you got the cable! :)
On build 725 in Fix 4, it returns 1 in about 1520 seconds.
With guesses of 0.98 and 1.02, it returns 1 in about 2 seconds. :)
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Maybe I should put this short program into flash and introduce a command to invoke it :)
 Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
The next build will include a function SLVQ solving quadratic equations :)
Walter
Posts: 203
Threads: 29
Joined: Nov 2009
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I can guarantee that the integration isn't going to deal with badly behaved functions very well. It isn't an adaptive method.
 Pauli
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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!)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 nonvolatile RAM for these.
 Pauli
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 Solveimplementations 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, 1E5 and 1E10 would test true as they are both rounded to zero?
Dieter
Edited: 24 Apr 2011, 7:27 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: I beg to differ. The Solveimplementations 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, 1E5 and 1E10 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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
