The Museum of HP Calculators

HP Forum Archive 07

[ Return to Index | Top of Index ]

Throw away programming?
Message #1 Posted by Ernie Malaga on 8 Dec 2001, 2:09 a.m.

The old PPC Journal contained in V6N3P27 (May 1979) an article titled "Forth: RPN on Microcomputers" by John Hirsch (2552). I read it this afternoon (from the CD set) and found a paragraph that, IMHO, applies to today's graphical calculators as well:

The implementation of RPN logic in a computer language brings up a problem which is not apparent in the more limited calculator versions. Efficient programming usually requires intricate stack manipulation. RPN calculator programs are readable if a running picture of the stack is kept in mind. But when you are dealing with two stacks of arbitrary length and many stack-manipulating commands, the readability problem can range from serious to unreal. Forth, like APL, is best used as a throw-away language. When lengthy programs require revision, it is quicker to discard them and begin over. (Please note that the opinions in this article are the author's alone and do not necessarily represent the views of the management.)

I couldn't believe I was reading this in a 22-year-old article, for it describes my feelings exactly. I've done my share of programming on "extended" RPN calculators (e.g., the HP-28C, HP-48GX, etc.), and have found their programs virtually unmaintainable because of the large stack.

I just wanted to find out how others feel about this subject. Care to comment?

-Ernie

      
Re: Throw away programming?
Message #2 Posted by Ex-PPC member on 8 Dec 2001, 3:28 a.m.,
in response to message #1 by Ernie Malaga

I couldn't agree more. Though I know that what I'm going to say will probably bring some hot debate or even flames, it would do well to remind everyone that what follows it's just *my* opinion, humble or not, and I'm as entitled to it as you are to yours own.

And here's what I think about RPL versus RPN: All classic machines, such as the wonderful 41C and 42S, had a simple but powerful and elegant RPN keystroke programming language, with an efficient 4-level-plus-LAST-X stack, which was easy to understand and easy to visualize while programming. They also had some simple looping devices (decrement and increment), storage arithmetic and indirection, and a fairly useful, uncomplicated filesystem.

Now, they've been 'replaced' by these new machines, using RPL, which is kinda some FORTH-with-dressing, which only transforms the intuitive and simple RPN programming paradigm into something so arcane and complicated that matter of fact, a lot of people desist from writing programs in that 'language' not to mention trying to understand them. You need several yellow-pages-sized 'advanced' manuals just to try and grasp the basics and fundamentals of their programming, the thousands of whimsical functions and their complicated syntax and expected parameters, to the point where you can do almost nothing without such a manual or hefty guide always at hand.

Tha sad truth is that the extremely simple, useful and elegant RPN paradigm has been 'improved' to utterly preposterous extremes. The typical RPL program is a nearly unfathomable mess where you actually need paper (lots) and a pen plus the manuals, just to attempt to understand what it's going on. It's kinda some 'obfuscated C' contest, if you know what I mean.

Not to mention its efficiency, or lack of it. Where you could do wonders in RPN on a 41C in just 224 bytes, you'll find yourself using more and more kilobytes for the simplest programs. So what ? After all, those RPL machines do have hundreds of Kbytes, even a Mb or two, so who cares anymore for elegant, efficient programming ?

Doubt it ? Well, here's an example, and I won't use the powerful 41C/42S, but one of the humblest RPN programmables, and probably the worst suited for this particular task, namely the business model HP-12C:

"Write a program to compute a root of the general equation of degree N:

a(n)*x^n + a(n-1)*x^(n-1)+...+a2*x^2+a1*x+a0 = 0

The program must accept all the (n+1) coefficients, a0, a1, ... , a(n), then it must try to compute the root as fast as possible, without needing any other information, such as initial guesses, or iteration limits, etc"

Believe it or not, this program can be written in RPN for a *business model* (not scientific) venerable, 20+ years-old HP-12C in some *18 steps* (i.e.: eighteen bytes) or less. Try to accomplish the same in your RPL wonder, without using the built-in solver (or even using it), and see how many hundreds of bytes does it take you.

I, for once, can write that 18-step RPN program in my head, no need to use paper, the 4-level RPN stack doesn't force me to.

To summarize, RPL is RPN's "Peter's Principle" come true: It's RPN rised to its saddest level of incompetence. And like it or not, there it will remain forever, no turning back.

            
Re: Throw away programming?
Message #3 Posted by Vieira, Luiz C. (Brazil) on 8 Dec 2001, 8:49 a.m.,
in response to message #2 by Ex-PPC member

Hi, Ex-PPC;

Just wondering. You proved having knowledge and capability I myself envy (please, no pun intended at all!). I would like to know what is the math procedure you use to compute these roots. You have shown us once a fast, clever, easy-to-compute way to get trig series for sine, cosine and tangent in a 12C. Would you share your version for the polynomial roots too? I`m a lot curious...

Thanks and regards.

                  
Re: Throw away programming?
Message #4 Posted by Ex-PPC member on 9 Dec 2001, 7:22 p.m.,
in response to message #3 by Vieira, Luiz C. (Brazil)

Luiz C. (Brazil) wrote: "You have shown us once a fast, clever, easy-to-compute way to get trig series for sine, cosine and tangent in a 12C"

I think you've mistaken me for someone else. I've never published any code of mine to do such computations in this forum. Matter of fact, I *asked* if someone could point me to that kind of code, including specially the inverse functions, in order to see how someone else managed to overcome the problems I found, and to compare his/her version to mine, and some person called Viktor Toth was kind enough to publish his own version, which you can find at this URL:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=225

So, you see, Viktor Toth is most probably the person you're referring to, not myself. Credit where credit is due.

                        
Re: Throw away programming?
Message #5 Posted by Vieira, Luiz C. (Brazil) on 9 Dec 2001, 10:25 p.m.,
in response to message #4 by Ex-PPC member

Hi, Ex-PPC;

I'm sorry not expressing myself precisely. In fact, at the time the trig programs were shown here, I remember well you showed a better, fast way to compute the sine series, from wich came cosine. If I am not wrong again, Cameron or Andrés asked for the precise description of the calculus involved, and you again showed how to simplify the series (some factorial sequencies). That`s what I was reffering to.

Anyway, I am always collecting procedures (more than calcs), cause math procedures are gold! And you shown some precious procedures at that time. Would you share the procedures you have for the polynomial roots? Ahn?

Thanks. And regards.

            
4-level RPN vs. RPL
Message #6 Posted by Andrés C. Rodríguez (Argentina) on 8 Dec 2001, 2:40 p.m.,
in response to message #2 by Ex-PPC member

Mr. Ex-PPC: I am 100% in agrrement with your posting. What is easy and fun to do in a HP25, 41 or 42 is unnecesarily hard to do in a 48xx. The 48G+ (the one model of RPL I have)is non-intuitive for use, simple things like DROP are error prone, there is no hint for argument prompting, there is no NULL to avoid an error message...

            
Re: Throw away programming?
Message #7 Posted by Rupert (Northern Italy, EU) on 8 Dec 2001, 5:58 p.m.,
in response to message #2 by Ex-PPC member

>Doubt it ? Well, here's an example, and I won't use the powerful 41C/42S, >but one of the humblest RPN programmables, and probably the worst suited >for this particular task, namely the business model HP-12C: >"Write a program to compute a root of the general equation of degree N: >a(n)*x^n + a(n-1)*x^(n-1)+...+a2*x^2+a1*x+a0 = 0 >The program must accept all the (n+1) coefficients, a0, a1, ... , a(n), >then it must try to compute the root as fast as possible, without needing >any other information, such as initial guesses, or iteration limits, etc" >Believe it or not, this program can be written in RPN for >a *business model* (not scientific) venerable, 20+ years-old HP-12C in some >*18 steps* (i.e.: eighteen bytes) or less. Try to accomplish the same in >your RPL wonder, without using the built-in solver (or even using it), >and see how many hundreds of bytes does it take you.

Well, with the HP48 built-in function you can enter the coefficients as elements of a vector in the stack: [A(n) A(n-1) ... A(0)], and then issue the command PROOT (polynomial roots). That's all. :-)

I have had a look at the various polynomial roots finding algorithms in order to refresh my memory, and cannot believe that it's possible to fit any of those algorithms in just 18 steps, if the HP12C doesn't have related built-in functions (and I guess it doesn't). Even the polynomial roots finding program on the HP32SII manual is bigger than 18 steps, as well as the POLY program in the Math I rom module of my good ol' 41CX.

                  
Re: Throw away programming?
Message #8 Posted by Ex-PPC member on 9 Dec 2001, 7:56 p.m.,
in response to message #7 by Rupert (Northern Italy, EU)

Rupert (Northern Italy, EU) wrote:

" Well, with the HP48 built-in function you can enter the coefficients as elements of a vector in the stack: [A(n) A(n-1) ... A(0)], and then issue the command PROOT (polynomial roots). That's all. :-)"

Should I clap ? ;-) That kind of functionality isn't new to the HP48, but simply a straightforward copycat from the much older HP-71B, where you could do this:

MAT INPUT A @ MAT X=PROOT(A) @ MAT DISP X

to prompt the user for the coefficients, find all roots real and/or complex, then display the roots, without even writing a program.

Your 'solution' has nothing to do with my 'challenge' (let's say for lack of a better term), and even doing it that way still doesn't meet the requirements, since there are is no input or output methods. Just doing a simple loop to ask/input the coefficients from the user one at a time would take longer than 18 bytes.

Rupert continued:

"I have had a look at the various polynomial roots finding algorithms in order to refresh my memory, and cannot believe that it's possible to fit any of those algorithms in just 18 steps, if the HP12C doesn't have related built-in functions (and I guess it doesn't). Even the polynomial roots finding program on the HP32SII manual is bigger than 18 steps, as well as the POLY program in the Math I rom module of my good ol' 41CX."

If you can't believe it, that's your choice. Matter of fact, I eased the conditions. It can be done in as little as 17 steps, including the final, always present 17 GTO 00. Excluding it, it's just 16 steps, which can be reduced to just 14 if a constant is pre-stored just once initially. And those 14 steps include such finesses as auto-detecting end of input by simply pressing R/S without inputting any number.

Just to give a numerical example of how the solution program should work in the HP-12C:

Find a root of this classic italian, cubic equation:

x^3 + 2*x^2 + 10*x - 20 = 0

You should take your HP-12C, key in you 17-step (or less) solution program, and do the following:

f PRGM, 1, R/S, 2, R/S, 10, R/S, 20, CHS, R/S, R/S

and after only 10 seconds, it should show the root, accurate to 10 digits: 1.368808108

The last R/S without inputting any number signals the program that all coefficients have been entered and it should then proceed to compute the root, if any. Of course, the solution program should not be limited to cubics, but it must work for quartics, quintics, ..., as well.

If you feel like it, see if you can cope. Else, there's always an HP48 with PRL and PROOT at hand.

                        
Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #9 Posted by W. Bruce Maguire on 10 Dec 2001, 1:30 p.m.,
in response to message #8 by Ex-PPC member

Mr./Mrs./Ms. "Ex-PPC Member" wrote:
--------------------------------
If you can't believe it, that's your choice. Matter of fact, I eased the conditions. It can be done in as little as 17 steps, including the final, always present 17 GTO 00. Excluding it, it's just 16 steps, which can be reduced to just 14 if a constant is pre-stored just once initially. And those 14 steps include such finesses as auto-detecting end of input by simply pressing R/S without inputting any number.

Just to give a numerical example of how the solution program should work in the HP-12C:

Find a root of this classic italian, cubic equation:

x^3 + 2*x^2 + 10*x - 20 = 0

You should take your HP-12C, key in you 17-step (or less) solution program, and do the following:

f PRGM, 1, R/S, 2, R/S, 10, R/S, 20, CHS, R/S, R/S

and after only 10 seconds, it should show the root, accurate to 10 digits: 1.368808108

The last R/S without inputting any number signals the program that all coefficients have been entered and it should then proceed to compute the root, if any. Of course, the solution program should not be limited to cubics, but it must work for quartics, quintics, ..., as well.

If you feel like it, see if you can cope. Else, there's always an HP48 with PRL and PROOT at hand.
--------------------------------

Mr./Mrs./Ms. "Ex-PPC Member":

Once again, I ask, why is it that most everyone here can share their E-mail addresses (or at the very least their names), yet you continue to hide your identity? It is humorous to me that you hide your code as well! Many people--including myself--have asked you to post different programs for the 12C (code that you unabashedly bragged about), but you have never posted any of your code.

You are an enigma. Sometimes you seem to write intelligent posts. But when it comes to coding bravado, you repeatedly show your true colors. This community thrives on give-and-take. As I said before, you seem only interested in taking. You seem willing to give your opinion, but nothing of any value. You ask for code from others. You insult others' inferior coding capabilities. But when asked to post your code, you change the subject or go "radio silence."

Congratulations on your excellent display of condescension yet again. You know, it would have been nice if you had taken the high road to the comments by "Rupert (Northern Italy, EU)". Rather, you started-in with your arrogant claims of programming superiority. When I read Rupert's post, I took it that he was amazed that you could fit such a program in so little space. Rather than thanking him for his indirect compliment about your programming capabilities and sharing your code with him, you chose to insult.

"Vieira, Luiz C. (Brazil)" asked you to share your code for the polynomial roots. Will you do that? If you remember right, I asked you to share your "magnificent" code for finding the trigonometric functions (save one) for the 12C; you never did.

Your response to Luiz that he was mistaken--because you have never shared any of your code (on that subject)--was pretty funny to me. It almost sounded like you were proud of that fact!

I'm assuming that you really have accomplished the programming feats that you brag about. For the life of me, I just can't figure out your motivation to never share any of your code... I won't "triple-dog-dare" you to provide the code, by claiming that it doesn't exist--that would only provide you a grand stage for showcasing your "impossible" programming talents. So, I will say once again, I believe that you have done what you have said.

Please give something back to the community.

Bruce.

p.s. If you desire, you may reach me at the E-mail address I have provided above. I also have provided you--and everyone else--my full name. Would you do us that courtesy?

                              
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #10 Posted by Thibaut.be on 12 Dec 2001, 9:51 a.m.,
in response to message #9 by W. Bruce Maguire

This kind of attitude (boasting about programming capabilities, but never sharing codes) reminds me my college years... we used TRS-80 model 1 level II and most of the puberians who used the computer at school were very keen on receiving programs but never provided a copy of what they had. In addition, they were challenging the programs you had saying they had something much smarter but they never let the chance to load it (remember, it was stored on a audio tape !) and run it...

I remember I wrote a program on my 41CV that calculated the roots of an equation (not a big deal, but the MATH ROM was quite expensive at that time for my student's budget) and that I let a friend (?) of mine copying it. After an hazardous MEMORY LOST message (I also could not afford the HPIL cassette drive nor the card reader) I asked him if I could copy it again, but he wouldn't accept ! In addition, he was claiming to be the author of the program that fascinated our maths teacher... :-)

Such an attitude is childish, and if someone is hiding interesting codes such as trig functions, polynomial roots on a 12C or whatever, I think he does not deserve to be a member of this community... Bruce is tatally right when h talks about the giving and taking principle. I am personnally delighted that my tiny knowledge has sometimes been useful to some people, I don't see what is the interest of hiding hints and tips to people who want to keep the legend alive (even more important when HP closes the calc business). In French, we call this "sawing the branch on which you are sitting on".

So unless codes are provided, I would suggest to just ignore and disregard such messages of people talking about their gold mine without showing any gold sample...

                                    
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #11 Posted by Fernando del Rey on 14 Dec 2001, 8:45 p.m.,
in response to message #10 by Thibaut.be

Hi, I’m a newcomer to this forum, but I’m quite sure that Mr. Ex-PPC does indeed have the 18-step polynomial solving program he describes. He’s just challenging all of us with a nice little puzzle. Why not concentrate in the challenge rather that criticizing the guy for the way he poses it?

Here’s how I figure you can solve the problem on the 12C. Perhaps someone else can contribute the program that behaves exactly as Mr. Ex-PPC describes.

The 12C has the IRR function, which can be used as a polynomial root finder.

IRR calculates “i” in the expression:

0 = CF0 + CF1/(1+i) + CF2/(1+i)^2 + … CFn/(1+i)^n

Where “i” is the interest rate that makes a series of equally spaced cash flows equal to zero.

Well, with the simple variable change x=1/(1+i) , you can use the IRR function to calculate the root of a polynomial. Just remember that the calculator gives the result of IRR expressed as a percentage, so you have to divide it by 100 (perhaps the constant that Mr. Ex-PPC mentions would save two program steps) before adding 1 and the doing 1/x.

Using his example, just enter as follows on the 12C

20 CHS g CFo 10 g CFi 2 g CFi 1 g CFi f IRR 100 / 1 + 1/x

And you get the root: 1.368808108

In this case the coefficients of the polynomial are entered in the opposite order as in the example of Mr. Ex-PPC, but I don’t think that matters too much.

What I honestly don’t know is the way to automatically sense inside the program that the input of coefficients is finished. Perhaps someone else can tell us that part.

However, if the user does not mind to enter the polynomial coefficients using the “g CFo” and “g CFi” keys instead of using R/S (in my opinion this is a very minor inconvenience), then your polynomial root finder is just an 8 step program:

01 IRR 02 EEX 03 2 04 / 05 1 06 + 07 1/x 08 GTO 00

Try it!: 20 CHS g CFo 10 g CFi 2 g CFi 1 g CFi f PRGM R/S

And you get the right result: 1,368808108

I don’t know if Mr. Ex-PPC is using the same IRR function, or any of the other financial functions available in the 12C, but I truly don’t think he has boasting about any fantastic code. Just teasing us all with a little challenge!

                                          
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #12 Posted by Vieira, Luiz C. (Brazil) on 15 Dec 2001, 3:48 a.m.,
in response to message #11 by Fernando del Rey

Hi, Fernando;

You post is very clever. I`ve been thinking of some possibilities and I did not try the ones you are showing, but if you follow the thread since the very begining, Mr. Ex-PPC member mentioned using the humblest HP12C calculator as an example. The question is: Would he use a special feature that automatically computes the result at the same moment he blames someone else`s solution that does the same, say, uses a particular root finder? Strange, isn`t it?

About sensing the entry: the only functions that have this feature are the TVM set (PV, PMT, FV, i, n), again a set of special purpose functions. I do not know how to explore this input sensing in a program, but I believe they are the only ones that can do it in the 12C.

I hope you feel yourself at home in here and, please, do not take this particular thread as a reference. Sometimes focus is lost and the discussion takes other path than the proposed one. Criticising anyones` particular submition is not as often as it seems...

Cheers. (and I believe I speak for the others when I say Welcome!)

                                                
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #13 Posted by Fernando del Rey on 15 Dec 2001, 10:49 a.m.,
in response to message #12 by Vieira, Luiz C. (Brazil)

Thanks Luiz, I'll see if I can contribute here some more in the future.

Unfortunately, the only two HP calcs I have access to are my own 42S and my wife's 12C. Not much, but surely enough to still enjoy some old fashion RPN programming.

Thanks for the Welcome.

                                          
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #14 Posted by Ex-PPC member on 15 Dec 2001, 4:13 a.m.,
in response to message #11 by Fernando del Rey

Mr. Fernando del Rey wrote:

"Here’s how I figure you can solve the problem on the 12C." [ ... ] The 12C has the IRR function, which can be used as a polynomial root finder."

Congratulations ! :-) :-)

That's exactly the way to do it ! By using the built-in IRR function you get everything: a complex, refined algorithm to find a root which does not require initial guesses or given iteration limits, incredibly few steps to implement, and best of all, full microcode speed !

Also, this method will work for equations up to the 20th degree if there are no consecutive coefficients which are equal, and for equations up to 99*20 = 1980th degree or so, if there are groups of consecutive, identical coefficients.

As the IRR calculation will result in Error 3 (on the 12C) if the solution is IRR < -100%, finding some roots would require a previous trivial transformation to bring them to the positive side of the X axis, but this is quite easy to achieve. Also, in case of multiple positive roots, the IRR calculation may need some help to converge on a root. This can be achieved in the HP-12C this way, once you get the Error 3 in the display: just key in a reasonable guess and press RCL g R/S. This will restart the IRR calculation using your provided guess and hopefully quickly converge to the desired root. This happens, for instance, for the equation: x^3 - 6*x^2 + 11*x - 6, which has roots 1,2, and 3.

Fernando continues:

"Well, with the simple variable change x=1/(1+i) , you can use the IRR function to calculate the root of a polynomial. "

Though this change of variable does works, there is a simpler way. If you enter the highest coefficient (1 in the example) as the first cash flow (CFo), the 1/x is not needed, just dividing the IRR result by 100 and adding 1. This avoids a division by zero in some cases and it's faster and simpler. Also, it allows you to introduce the coefficients in their natural order, as they appear on the equation (CFo = 1, CF1 = 2, CF2 = 10, CF3 = -20) amd further simplifies the programming.

Fernando goes on:

"What I honestly don’t know is the way to automatically sense inside the program that the input of coefficients is finished."

It can be done in a number of ways. As the 12C doesn't have any flags who can detect input, the easiest and less costly way is simply to leave some suitable constant in the display before stopping to ask the next coefficient. Once the user has pressed R/S, you recall said constant to the X register again, and test against Y for equality. If false, the user entered something. If true, the user simply pressed R/S. Of course this would fail if one of the coefficients happened to be exactly equal to the constant, but using a suitable choice (say LN(7) or EXP(9)), this can have a probability so low as to never occur in practice.

By the way, I'm sure that this IRR method will also work for most other business calculators which do have a built-in IRR function, so we have the paradoxical fact that a business calculator like the HP-12C can solve n-th degree equations simpler and faster than, say, the HP-11C or even the HP-15C despite its SOLVE feature !

Thanks again to Fernando who, if I remember correctly, *is* also an Ex-PPC member, namely #6995 if I'm not wrong ! Aaahh, those were the days ... ! :-)

                                                
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #15 Posted by Fernando del Rey on 15 Dec 2001, 10:44 a.m.,
in response to message #14 by Ex-PPC member

With the clues you give, the program is now quite simple:

01 CFo
02 7
03 LN
04 ENTER
05 R/S
06 –
07 x=0
08 GTO 12
09 LSTx
10 CFi
11 GTO 02
12 IRR
13 1
14 %
15 1
16 +
17 GTO 00

17 steps counting the final GTO 00. And quite surely any experienced 12C programmer (which I'm not) can find a step or two to reduce. I would have never though the 12C capable of such feat!

You are right to say that I am a former member of PPC, and indeed those were fun times!! I bet many of the users of this forum are also former PPC members, right?

                                                      
Re: Please "show us the code" Mr./Mrs./Ms. "Ex-PPC Member"!
Message #16 Posted by thibaut.be on 15 Dec 2001, 11:39 a.m.,
in response to message #15 by Fernando del Rey

Great, thanks for posting the listing.

Yes, indeed, I guess most of us did not consider the specific functions of the 12C. I'm a bit ashamed not having thought about it as finance maths are someho my cup of tea. This is what I've developed on my site (http://hpcalc.multimania.com).

The thing is that, UMHO, the way it was presented is that any calc without a solver (the 12C seems quite nude in maths) should be able to calculate the root of a polynomial. Again, it was well done to ask it to be programed on a 12C.

So, without the internal solver of the 12C, it seems not possible to get a solution in less than 18 steps. For example, try to sort this out on a 10C or a 11C...

Anyway thanks for providing an answer, Mr del Rey, and welcome to the community. Just a word on the criticisms towerd Mr Ex PPC member : though he did proposed challenges, he (up to now) *NEVER* gave the solution, which is a bit against the give/take principle of the forum.

Anyway again congratluations for your cristal clear demonstration.

                                                      
Re: Polynomial challenge
Message #17 Posted by Andrés C. Rodríguez (Argentina) on 15 Dec 2001, 3:50 p.m.,
in response to message #15 by Fernando del Rey

Fernando:

Apart from saying "Hello, welcome!" and "Congratulations!" for an excellent description for your solution (theory and practice), I would like to suggest a little, cosmetic addition to the technique for detecting new values entered by the user. I understand the challenge was about using very few bytes, so I accept criticism in advance, because what I would suggest may enlarge the program a little.

First, while Ln(7) is rare enough to be a user-entered coefficient, as Mr. Ex-PPC states, I think that a large number will be even rarer. I would prefer the use of 10^x (or e^x, if you think it is more appropriate) to obtain the value to compare with, and will have used "9" instead of "7". The cost is the same, except if someone cares about more active LCD segments as a lack of elegance :-)

If the value left on the display by the CFi function is appropriate, you may save a step / byte here, using that value as the argument for 10^x.

Second, and at the cost of an extra byte, I would have put a CLx before the R/S, to have a blank display as a prompt for the user, instead of the Ln(7), which may be confusing. Again, this has nothing to do with Mr. Ex-PPC challenge, because the challenge was about program lenght and memory usage, not about user friendliness. Since the stack would not lift after a CLx, it would work the same.

So the modified version would look like:

...

02 9

03 10^x

04 ENTER

05 CLx

06 R/S

07 –

08 x=0

09 GTO 13

...

BTW, as I have no HP12 at hand, I cannot verify by myself these suggestions; so please disregard any missing detail. And thank you again for sharing your technique.

      
Re: Throw away programming?
Message #18 Posted by Vieira, Luiz C (Brazil) on 8 Dec 2001, 8:36 a.m.,
in response to message #1 by Ernie Malaga

Hi, falks.

I read both posts briefly and I cannot agree with both Ex-PPC and John Hirsch IF WE CONSIDER other not directly stack-related features. I'd consider using, for example:

« -> n
  «
    commands
(if needed, `n` STO to update n, as for T-register auto duplication)
  »
»

Using local variables definitely reduces stack levels` need AND program size (less stack manipulations), eases program reading, among other advantages. It will use more memory and execution time will increase, but ones compensate the others. I like having to track stack contents (it`s kind of a puzzle, sometimes better than chess...) and I am always trying to reduce the number of commands I use to achieve the results from a particular manipulation. It`s teasing...

Ex-PPC Member mentioned using a 10-series calc for programming the solution. I really like using any 10C, 11C, 15C, 16C, even the 12C (I like the scientifcs more than the financials), they are easy to use and program, but sometimes the bigger brothers will be irreplaceable. Consider more space to store program commands and user data, more results to be shown/printed and, mostly, transferring data to another system.

When I wrote my (first) book, I used an 80286, 2MB RAM, 200MB HD, running W3.1 and Windows Write. I would not use this again to write an e-mail... but if I have to, no matter. Nowadays, PC`s are 256MB RAM, 30GB HD, 800M to 1.5G Hz clock, Penguin Linux / Billagotcha W ME. And the bigger HW justifies itself for the bigger SW, that needs a bigger HW that... Doug expressed his thoughts about system, mainframe programming in previous threads that I believe get closer to this kind of discussion, respecting both weights.

I know it is not the kind of comparison to be made: using an 11C and a 49G is almost a personal choice (unless you have to solve an R,S,T unbalanced AC system for currents; piece o`cake for the 15C). What I mean is that systems grow as needs for bigger systems arise. And using a new, highly featured system to achieve results easily obtained with previous, less-powered systems, may result in more manual operations IF ONE TRIES TO KEEP SAME PROCEDURES. Why not using the new features in a different manner?

My book is entitled `Da HP41 para a HP48` (From the HP41 to the HP48) and I invite the reader to dare translating existing programs from the old fella to the new one, both using the new features and keeping former structure.

I use an example that's somewhat easy to understand: create a program that takes A and B from the stack (X and Y registers) and returns the hypotenuse of the defined rectangular triangle. The first possible result would be like this:

X^2
X<>Y
X^2
+
SQRT
Well, everybody knows that a simple R-P does the job, and it`s applicable to each of them (and any others, I know). If we try to apply the set of known math operations WITHOUT EXPLORING THE SYSTEM FEATURES we cannot go further.

Maybe I did not get to the point, maybe something else should be posted, but let's face it: new features must be at least known; one day or another we`ll have a situation where using them will be the difference of getting to the result or not.

Cheers.

      
Re: Throw away programming?
Message #19 Posted by David H Thompson on 8 Dec 2001, 5:55 p.m.,
in response to message #1 by Ernie Malaga

Hello everyone,

I totally agree with Ernie Malaga's view on stack based programming languages.

Viktor Toth provides a simple example of the power of TI and HP calc's on his site: www.rskey.com. The example demonstrates an arbitrary function being passed to a program which calculates the radius of curvature of the function at a point. I think this program satisfies Ernie's description of 'throwaway'. Compare the TI 89 solution to the HP 48 solution: the contrast is stark. The meaning of the TI's one-line solution is obvious: the HP's has to be read with care. The TI's doesn't even require familiarity with it's programming model: stunning.

I encountered the stack based model's unreadability in a recent project to provide myself with a graphics command language to enable the inclusion of Postscript diagrams in LATEX documents. At first I pursued the task by writing routines directly in Postscript which uses the stack model. The code was difficult to read, and I changed to writing Postscript generators in C++ and Perl.

Every programmer, casual or otherwise, is failiar with the stack paradigm; it's extension to the programming language itself would indeed seem to be frought with difficulty.

Thanks Ernie for raising this issue.

David

            
Re: Throw away programming?
Message #20 Posted by Raymond Hellstern (Germany) on 8 Dec 2001, 11:20 p.m.,
in response to message #19 by David H Thompson

Hello,

>[..PS programming..] >The code was difficult to read, >and I changed to writing Postscript >generators in C++ and Perl. >

usually it's a matter of documentation;-)

Some programming environments, like the Navision Financials/Attain Object Designer, or the Centura SQLWindows/32 Team Developer, only have poor support for standard documentation headers. Maybe because the developers of the mentioned systems thought that today's code explains itself... which is still a dream, of course.

Raymond

      
Re: Throw away programming?
Message #21 Posted by Raymond Hellstern (Germany) on 8 Dec 2001, 7:22 p.m.,
in response to message #1 by Ernie Malaga

Hello,

I don't agree here. For me RPL/FORTH isn't a 'throw-away-language'. The 'unlimited' stack of the RPL machines is a feature, not an obstacle. You don't need to use hundreds of stack levels, because you can use variables to ease overview. You can even group arguments into lists or arrays on the stack and/or in variables.

Of course it seldom makes sense using many many stack levels and loose overview of what happens, but even on the classical 4-level stak machines you have to use registers fore more complex programs. And you have to make notes about the register contents, if you don't want to loose overview;-)

The one-line display of the classic RPN machines forces the user to make at least as much notes as on the newer RPL machines like the HP-48.

I did programming on the 41 series for more than ten years, on the 28 series for nearly four years, then on the 48 series for more than eleven years so far.

First it was a bit difficult to break out of the 4-level stack scheme thinking with T duplication and LASTX, but after a while, the advantages were visible.

I had to take more care for the arguments of programs. If I wrote a program which used 2 arguments and returned 1 result I had to provide (at least) two arguments on the stack, and I could see the one result, so in the end the stack contained one level less than before;-)

On the 41, I often used the LASTX feature to regain an argument for later use. This isn't an option on RPL machines, because you can't rely on an enabled LastStack, and it would even complicate things (IMHO)...

But, as on RPN machines, you can duplicate an argument just by hitting (or writing) DUP if it's one argument, or duplicate any number of arguments with the appriorate command, or save the argument(s) in a variable, and recall it later, or whatever. So you have more than one option, and can use the one that suits most.

Consider saving four arguments for re-use after a function call on an RPN machine like the HP-41. You have to use registers for that. On the RPL machines, you *can* use variables, but you don't need to do so. You can simply group the args into a list and save the list into one variable, or roll out the list to the top of the stack, or just duplicate the 4 arguments on the stack.

After all, I think the unlimited stack has more advantages than drawbacks, and it's simply more practicable than the limited 4-level stack. Consider you have to control the output of some report lists, which consists of daily sums and averages per employee, followed by a monthly sum and average per employee, and at the bottom of the report, some overall sums and averages.

On a classic RPN machine, you have to sum up intermediate results, such as the sums and averages of some days for a person, because the stack has only 4 levels. Consider you have say 20 employees which have report entries on nearly every day.

Of course I don't want to hold all results for every person at the same time, but even if you want to compare the sums or averages of all persons, you have to hold at least the final values for each person. So you have to use registers, like the Sigma block, which is available on the RPL machines, too.

Ok, this example may be not the best possible, but I think it gives a clue what can be done relatively easy on RPL machines, compared to the classic 4-level stack machines.

Don't get me wrong, I *love* my classic RPN machines, and I carry an 11C or 15C nearly all the time, because most of the time, simple arithmetic on a few numbers is sufficient for me. But for checking a grater amount of data with intermediate results, I prefer Emu48.

Regards,

Raymond

            
Re: Throw away programming?
Message #22 Posted by David H Thompson on 8 Dec 2001, 8:10 p.m.,
in response to message #21 by Raymond Hellstern (Germany)

Hello,

Raymond writes that RPL/Forth are not throwaway languages, but surely they are: they have been abandoned on every other programming platform!

David

                  
Re: Throw away programming?
Message #23 Posted by Raymond Hellstern (Germany) on 8 Dec 2001, 11:22 p.m.,
in response to message #22 by David H Thompson

Hello,

that's right, but I thought we're talking about languages used in HP calculators;-)

And these machines surely not tend to get thrown away, even if they might not be produced any more in the future.

Raymond

                        
Purist or pragmatist?
Message #24 Posted by Joe Panico on 10 Dec 2001, 3:25 p.m.,
in response to message #23 by Raymond Hellstern (Germany)

Group;

These are all interesting comments, but leading where? Any language has advantages and limitations. I've found use for all the programmable platforms I own (even the lowly video recorder) and seldom find the need to pit one against the other. Pragmatist.

Of course, purists are never happy, so they're thirst ultimately goes unfullfilled. They, however, push the development further, with some concessions that it was already moved far enough.

I can live with either.

Joe

      
Re: Throw away programming?
Message #25 Posted by Chris Randle (Lincoln, UK) on 10 Dec 2001, 7:29 p.m.,
in response to message #1 by Ernie Malaga

I'll comment, since you asked.

I started my HP experience with a 48SX and enjoyed programming it. I never felt 100% comfortable with RPL having come from a key stroke programmable calculator (a Casio FX-602P). However, I was impressed by the power of the machine - more like a small computer than a calculator. I agree that the code was difficult to understand, especially a few weeks after you had written it.

12 years later, I bought a 42S because everybody was raving about them. I realised that this was the machine I should have bought all those years ago. Fantastic! Clean, yet powerful programming concepts.

Six months ago I bought a 28S. Having seen both sides of the coin, this became my favourite. I could see how cleverly the development team had kept most of the keystroke programmable ability for those that demanded it, and yet had "morphed" (for want of a better word) the programming side into RPL. I think the 28S had a purity of design the the 48 series had obscured by too much in-built functionality.

I've come to realise that few, if any, HP calculators stand alone. Only experience of the machines that came before and after can offer a true appreciation of any given model.

Isn't it odd that the 28S is my favorite and the 48SX my least favourite? Two machines so close chronologically.

I tried to make my comments generic, but couldn't leave without saying that RPL allows you to span a whole range of programming styles, from plain keystroke style to masochistic huge stack manipulation to local variable assignment followed by more modest stack manipulation and on to local variable assignment followed my an algebraic expressions. This is incredible power and flexibility.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall