▼
Posts: 312
Threads: 25
Joined: Jan 1970
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 stackmanipulating commands, the readability problem can range from serious to unreal. Forth, like APL, is best used as a throwaway 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 22yearold article, for it describes my feelings exactly. I've done my share of programming on "extended" RPN calculators (e.g., the HP28C, HP48GX, 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
▼
Posts: 142
Threads: 24
Joined: Jan 1970
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 4levelplusLASTX 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 FORTHwithdressing, 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 yellowpagessized
'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 HP12C:
"Write a program to compute a root of the general equation
of degree N:
a(n)*x^n + a(n1)*x^(n1)+...+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+
yearsold HP12C in some *18 steps* (i.e.: eighteen bytes) or less. Try to accomplish the same in your RPL wonder,
without using the builtin solver (or even using it),
and see how many hundreds of bytes does it take you.
I, for once, can write that 18step RPN program in my
head, no need to use paper, the 4level 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.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, ExPPC;
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, easytocompute 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.
▼
Posts: 142
Threads: 24
Joined: Jan 1970
Luiz C. (Brazil) wrote:
"You have shown us once a fast, clever, easytocompute
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/cgisys/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.
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, ExPPC;
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.
Posts: 1,193
Threads: 43
Joined: Jul 2005
Mr. ExPPC: 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 nonintuitive 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...
Posts: 25
Threads: 2
Joined: Jan 1970
>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 HP12C:
>"Write a program to compute a root of the general equation of degree N:
>a(n)*x^n + a(n1)*x^(n1)+...+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+ yearsold HP12C in some
>*18 steps* (i.e.: eighteen bytes) or less. Try to accomplish the same in
>your RPL wonder, without using the builtin solver (or even using it),
>and see how many hundreds of bytes does it take you.
Well, with the HP48 builtin function you can enter the coefficients
as elements of a vector in the stack: [A(n) A(n1) ... 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
builtin 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.
▼
Posts: 142
Threads: 24
Joined: Jan 1970
Rupert (Northern Italy, EU) wrote:
" Well, with the HP48 builtin function you can enter the coefficients as elements of a vector in the stack: [A(n) A(n1) ... 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 HP71B, 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 builtin 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 prestored just once
initially. And those 14 steps include such finesses as
autodetecting 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 HP12C:
Find a root of this classic italian, cubic equation:
x^3 + 2*x^2 + 10*x  20 = 0
You should take your HP12C, key in you 17step (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.
▼
Posts: 180
Threads: 23
Joined: Apr 2012
Mr./Mrs./Ms. "ExPPC 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 prestored just
once initially. And those 14 steps
include such finesses as autodetecting
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 HP12C:
Find a root of this classic italian, cubic equation:
x^3 + 2*x^2 + 10*x  20 = 0
You should take your HP12C, key in you
17step (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. "ExPPC Member":
Once again, I ask, why is it that most
everyone here can share their Email
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
peopleincluding myselfhave 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 giveandtake. 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 startedin 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 mistakenbecause
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
"tripledogdare" you to provide the code,
by claiming that it doesn't existthat
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 Email address I have provided
above. I also have provided youand
everyone elsemy full name. Would you
do us that courtesy?
▼
Posts: 610
Threads: 53
Joined: Aug 2005
This kind of attitude (boasting about programming capabilities, but never sharing codes) reminds me my college years... we used TRS80 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...
▼
Posts: 30
Threads: 0
Joined: Sep 2005
Hi, I’m a newcomer to this forum, but I’m quite sure that Mr. ExPPC does indeed have the 18step 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. ExPPC 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. ExPPC 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. ExPPC, 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. ExPPC 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!
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
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. ExPPC 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!)
▼
Posts: 30
Threads: 0
Joined: Sep 2005
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.
Posts: 142
Threads: 24
Joined: Jan 1970
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 builtin
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 HP12C 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 builtin IRR function, so we have the paradoxical
fact that a business calculator like the HP12C can solve
nth degree equations simpler and faster than, say, the
HP11C or even the HP15C despite its SOLVE feature !
Thanks again to Fernando who, if I remember
correctly, *is* also an ExPPC member, namely #6995 if I'm
not wrong ! Aaahh, those were the days ... ! :)
▼
Posts: 30
Threads: 0
Joined: Sep 2005
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?
▼
Posts: 610
Threads: 53
Joined: Aug 2005
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.
Posts: 1,193
Threads: 43
Joined: Jul 2005
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 userentered coefficient, as Mr. ExPPC 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. ExPPC 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.
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi, falks.
I read both posts briefly and I cannot agree with both ExPPC and John Hirsch IF WE CONSIDER other not directly stackrelated features. I'd consider using, for example:
« > n
«
commands (if needed, `n` STO to update n, as for Tregister 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...
ExPPC Member mentioned using a 10series 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 email... 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, lesspowered 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 RP 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.
Posts: 32
Threads: 16
Joined: Jan 1970
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 oneline 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
▼
Posts: 1,841
Threads: 54
Joined: Jul 2005
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
Posts: 1,841
Threads: 54
Joined: Jul 2005
Hello,
I don't agree here.
For me RPL/FORTH isn't a 'throwawaylanguage'.
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 4level 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 oneline display of the classic RPN machines
forces the user to make at least as much notes as
on the newer RPL machines like the HP48.
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 4level
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 reuse after a function
call on an RPN machine like the HP41.
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 4level 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 4level 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
▼
Posts: 32
Threads: 16
Joined: Jan 1970
Hello,
Raymond writes that RPL/Forth are not throwaway languages, but surely they are: they have been abandoned on every other programming platform!
David
▼
Posts: 1,841
Threads: 54
Joined: Jul 2005
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
▼
Posts: 78
Threads: 6
Joined: Jan 1970
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
Posts: 136
Threads: 22
Joined: Aug 2010
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 FX602P). 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 inbuilt 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.
