Re: Fast Quadratic Formula for the HP41C Message #4 Posted by Luiz C. Vieira (Brazil) on 17 July 2012, 10:09 p.m., in response to message #3 by Gerson W. Barbosa
Hi, Gerson;
please, forgive me: I did not notice the stack contents preservation, just crossed my mind the idea of using fewer steps.
And indeed, quadratic equation is written as you mention. But as we all know, sometimes the entering order in RPN/RPL calculators follows different directions, like entering coordinates: we write (x,y) and enter y [ENTER] x. Yep, I know this is for 'data'<>'stack register' consistency, as it happens with statistics data entering. And so it follows the polar coordinates entering: angle [ENTER] radius.
A different input consistency, kinda 'backwards' as I see if compared to the one above, is observed with the attribute operator '>' in the 28/48 series: if you have something like > a b c , we know that a, b and c must be in stack levels #3, #2 and #1, respectively. So, the first variable after the '>' will 'grab' data in the highest stack level. If we have> a b c d instead, then variable 'a' grabs data in level #4, but it is still the first variable after the attribute operator.
But if we take algebraic input it is just 'as is'.
I must confess I like to write programs considering data is input, say, 'backwards', if I can say so. I like to think Xregister will hold the first variable (a, in this case), Yregister will hold the second data (b) and so on. To make this happen, data must be entered 'backwards', right? As you see, the first step of the program  X<> Z  provides data to be arranged this way.
But what matters is the brainy discussion, the learning and the teasing/challenging of optimizing within limits (or rules). Or else the task looses focus.
Thanks for that! And good programming, indeed!
Cheers.
Luiz (Brazil)
Edited: 17 July 2012, 10:11 p.m.
