The following warnings occurred:
Warning [2] Undefined array key 31955 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 31968 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 31985 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32039 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32047 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32049 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32050 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32119 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32129 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 275 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $thread - Line: 295 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 295 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Trying to access array offset on value of type null - Line: 295 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 295 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $fid - Line: 295 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 295 errorHandler->error_callback
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32129 - Line: 331 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 331 errorHandler->error_callback
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 304 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined array key 32049 - Line: 331 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php 331 errorHandler->error_callback
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 332 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 304 ThreadedMode::buildtree
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $theme - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Trying to access array offset on value of type null - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $theme - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Trying to access array offset on value of type null - Line: 3 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 3 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Undefined variable $lang - Line: 5 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 5 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks
Warning [2] Attempt to read property "messages_in_thread" on null - Line: 5 - File: inc/plugins/threaded_mode.php(305) : eval()'d code PHP 8.1.2-1ubuntu2.14 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/inc/plugins/threaded_mode.php(305) : eval()'d code 5 errorHandler->error_callback
/inc/plugins/threaded_mode.php 305 eval
/inc/plugins/threaded_mode.php 23 ThreadedMode::showthread_threaded
/inc/class_plugins.php 142 threaded_mode_showthread_threaded
/showthread.php 918 pluginSystem->run_hooks





Re: Newcomer has questions



#10

Hi Ernie,

you're missing my point.

Maybe so. I do see your point that RPN and RPL are different, and I
agree with that. But I think that RPL is easy to understand and well
worth learning. "Classic RPN" has to run on hardware with relatively
limited resources. The RPL calculators have, if I'm not mistaken, faster
processors, and certainly more built-in memory (well, possibly excepting
the 28C), so why shouldn't RPL take advantage of the improved hardware?
Why, for example, would one want to restrict the stack to only four
levels? Or to save only one last argument? I see RPL as an improved
version of RPN.

As I mentioned in an earlier post, I wrote the example programs
off the top of my head without testing or optimization.

Ok, it's a simple enough example that it doesn't really need any
testing. Well, at least not the RPL program, which will obviously work;
I'm not about to buy myself a 41 and learn to program it just to see if
the 41 program works. But I glanced at your RPL example, and off the top
of my head, I couldn't see any reason to go to the bother of using a
local variable. Now that I've thought about it a bit, I see that using
the local variable gives your version the advantage that it's a user
defined function; that is, it can be used in an algebraic object. But
about the only time that I use algebraic objects is when I'm copying a
formula that's already been written down by someone else, and seldom
even then.

>why would you want fancy formatting when a program's on the stack?

And that points to another design flaw. Programs are meant to be
read by _people_, because they have to be understood by _people_ if they
are to be modified, improved, or what-have-you. Removing the "fancy
formatting" removes understandability and confuses the programmer. Good
coding standards _require_ use of comments and indentation whenever
possible.

I think that you're missing *my* point here. My point is that if I
wanted to peruse a program and perhaps edit it, I wouldn't be looking at
it on the stack, but in the editor, where I could scroll through it and
see the entire program, or I'd print it out, and with those methods it
does have the indenting (although the indenting is what the decompiler
applied; not necessarily what I would have used). Or better yet, if I
wanted a really good look and I wrote it on the PC, I'd be looking at
the source file, indented and commented as I saw fit (of course, that
would require that I be at home so that I could use my PC). And yes,
good programming practice requires the use of comments and indentation
in the *source* code whenever possible. But for simple programs, someone
familiar with the programming language can look at the code and see what
it does even without indenting or comments. I do use indenting, and,
when I write a program on the PC, some comments in the source code, but
do you know of any compiler that retains the indenting and comments?
Wouldn't that defeat much of the purpose of compiling?

To be sure, there are languages that save the source code and interpret
it at run time, but I have my doubts as to how feasible it would've been
to use that method on a hand-held at the time that UserRPL was designed,
or even now.

>If I really wanted to keep the program from being compiled, I could
embed it within a character string and even keep comments in it

Come, now, who's making things more difficult than they have to
be? 8^)

Well, you complained that the RPL compiler discarded the programmer's
formatting, so I demonstrated that you could make it retain the
formatting if you really wanted to. I certainly don't recommend that
anyone use that method; keeping the source code in its own file on the
PC makes a lot more sense.

>RPL is simple and straightforward.

Debatable and subjective. It's equally possible to argue that
RPL is complicated and convoluted.

Certainly you can write complicated and convoluted programs in RPL if
you choose to do so. I suppose that the same could be said of any
language. How about the 41's version of RPN? Using GTOs, I suppose that
you could make things *extremely* complicated and convoluted if you
chose to do so.

>As long as I use a variable name descriptive enough that I remember
what the program was written for in the first place

RPL variable names are, in practice, limited to 4 or 5
characters because more than that won't fit in a menu key label.
Sometimes my HP-28C can't put more than 3 characters! One cannot be
descriptive when limited to such short variable names. I should know --
I've been an RPG programmer for 20 years, and RPG II and RPG III program
variables are limited to 6 characters. Yech!

Haven't you ever noticed that in "PRG ENTRY" mode, pressing the menu key
for a variable puts the whole name in the command line? There, if it's
too long to fit in the 22 character standard display, you can scroll
left or right to see the rest of it. The name can be up to 127
characters, which I suppose should allow one to be descriptive enough.
The first few characters that you can see in a menu should be enough to
give you a clue, and on any RPL calculator except the 28C, you can
organize your variables into directories, which should give you more
clues as to what a variable is for.

>But I thought that the "RP" in both "RPN" and "RPL" stood for "Reverse
Polish". Doesn't that mean arguments first, operator last? Notice how
many of the arguments in your program come *after* the operators? Now
that's what I call backwards.

As mentioned above, programs are meant to be read by _people_. People
use human speech (with a given language) to communicate ideas. When you
say "store in register 01" you use a verb in the imperative tense
("store") and an object or "parameter" ("in register 01"). That's the
_natural_ way to speak.

Natural in English, which most often uses a "Subject Verb Object" word
order, but perhaps not for various other languages. But doesn't "1 plus
2" sound more natural than RPN's "1 2 plus" to our English accustomed
ears? Yet we (the folks on this forum, that is) prefer to use RPN.

Like Yoda of the "Star Wars" saga, you can say "In register 01
store," but taking this backwardness as far as that doesn't clarify a
program in the least.

I wonder which word order he uses in foreign language versions of those
movies.

For that reason, I feel that RPL is more backwards than RPN.
IMHO, HP took Lukasiewicz's invention just too far.

But suppose that the "objects" for "verbs" such as STO, RCL, FOR, or
flag commands are already on the stack, as a result of a previous
operation? If I have to put the "objects" after the "verb", then I
suppose that I'd have to push the "verb" onto the stack, and then
rearrange the stack to get the "objects" to the bottom of the stack, or
maybe write them down on a scratch pad and key them in again. That's the
genius of the "Reverse Polish" way of doing things; it lets you easily
use the results of previous operations.

Why do things differently for certain commands just to conform to
English language patterns? I'd rather that a programming language be
self-consistent.

Not that RPL is perfect of course. If it were up to me, then "IF" would
be discarded as it's superfluous in RPL, and for some commands that
require more than one argument, the order of the arguments seems
"unnatural" to me. The REPL command comes to mind; I experimented the
last time that I used it. Certainly I can imagine many additional
commands that I'd like to have built-in, "Garbage collection" can take
an awfully long time under certain conditions, and I could no doubt
think of other things that I'd rather were different.

But, as you yourself said, "stick with what you like."

Certainly. I have RPL calculators and a 16C. In some ways I find the 16C
inconsistent and rather limiting, but it's occasionally useful because,
being a rather specialized calculator, it has some special capabilities
that aren't built-in to the RPL models (though I suppose that I'd
program them in myself if I used them very often). But having RPL
models, I doubt that I'd ever really use other RPN models. What could I
do on them easier than I could do it on an RPL model? Something that fits
in a shirt pocket would be nice, but considering current prices, I'll
put up with a Brand X algebraic input calculator when I want to compare
prices in the grocery store. The RPN models are interesting and often
admirable in design and quality, but for me, they'd end up being museum
pieces, just left on a shelf or stored away somewhere.

>And then add the lack of IR, crippled serial I/O, flakey keys, poor
keyboard layout, lack of keyboard overlays, big ugly chunk of plastic
over the display, hard to read lettering on the faceplate, numerous
operating system bugs...

You just gave a precise description of the HP-49G! 8^)

Some steps forward, some steps back. The 49G is sometimes fun to play
with, and has some new operations that are useful, but for "real work",
I'll keep using the 48 series calculators.

Regards,
James


#11

James:

Thank you for your detailed and most interesting reply. After reading it, all I can say is, "Let's agree to disagree." It's obvious that RPN and RPL require different mindsets from their users. And perhaps I'm too old (47) to make the transition without trouble.

-Ernie


#12

Ernie,

Ok, I was a mere youngster still in my thirties when I became acquainted
with RPL.

I've had the 16C for less than a year. I'm pretty confident doing things
"manually" on it, and I've worked through the Owner's Handbook and
written a few very simple programs. Interesting, and it has some things
in common with RPL models, but I'm sure that if I felt any "real work"
need for any but the most rudimentary program, even with binary, octal,
decimal, or hexadecimal integers, then I'd write it for an RPL model,
even though the RPL calculators lack many built-in features that the 16C
has for working with these objects.

I don't think that it's so much a matter of age. I expect that you could learn to be a proficient RPL programmer, and I could learn to be a proficient RPN programmer, but what's probably lacking for both of us is motivation.

Regards,
James


#13

Hello Ernie, James, folks;

a few days ago I received an e-mail from one of our contributors (recently injured by a thief) mentioning he noticed I deal with RPN and RPL as well, as he does the same.

I read the posts from both of you and I must tell you I sometimes choose RPN or RPL style programming after trying them both in the same problem. And I consider programming and using in a different way. Let me put it in a different perspective.

When I want to deal with numbers only (most of the time) I take any RPN calculator in hand, but I prefer a Voyager. They have "almost" everything you need already printed in the keyboard. I used the word "almost" mostly because of the HP15C, that requires some background to use Numerical Integration and SOLVE. How to use them is the only information not printed on its back label.

If there is no Voyager at hands, or if I need any sort of ALPHA manipulation, like labeled messages or interactive input, I go for a 41 or a 42. In their case, function names and menus will probably slow operation a bit down, but there is no problem.

The major problem is related to large database manipulation (large for a handheld calculator). If I want to observe statistical data to determine a tendency and define parameters and curve fitting I'll use the HP42S mostly because it allows using lists (matrices) as input data, and editing a matrix in an HP42S is relatively easy. In other cases, using X-Functions (HP41) may also be of help, and dealing with ASCII files in an HP41CX (ED) is, at least, fun.

I consider using an HP48 for simple daily computations as fast as using an HP42S IF you keep your eyes in stack contents. In fact, I see as a major concern the stack contents clearing from time to time if you allow previous results to remain there and selective, cautious use of the conceptually correct LAST ARG instead of the also conceptually correct LAST X. I am not sure about the other guys, but I care much about T-contents replication when programming. If I am using a four-level deep, stack-based calculator (RPN), manipulation of stack contents is sometimes as easy as pressing [Rv] (roll-down) four times to review its contents, and I do not remember storing ALPHA data in any stack register other than in program execution. But I must admit manipulating data by keystroke sequences available at the RPL-based calculators is harder. Simply rotating stack-"level" contents demand the number of levels to be rotated to be firstly input prior to execute "ROLL" or "ROLLD". A third "ROT" function allows a faster three-level rotation. Picking a copy of any available "level" contents is a matter of specifying it and executing "PICK". A lot more names to remember, I know, but that's a price I was willing to pay at the time I learnt RPL concepts.

I consider writing programs a very different issue. Using voyagers, HP41 or HP42 is a matter of internal resources and programmers' needs. But using RPL-based calculators go beyond this. I "think I need" RPL-based calculators to develop bold, audacious programs that allow you to access external devices easily and delve into mass-storage extensive data to find patterns... O.K., O.K., I know you can do it with a palm and use another functional- or imperative-paradigm language at your request, but how much will it all cost? Four, five, eight times what you expend with an HP48G+, SW and RPL-compiler included. And I feel RPL-based calculators programming as a fast procedure. I know other contributors do not feel like this, but for me RPL brought many features I used to dream of: no specific "environment" for specific data like programs, registers and APLHA; ability of entering program instructions/functions in an existing program; easily generation (or ability to easily generate) user functions (not programs) as internal existing features; easy, standard way to communicate with external devices (not available with the HP28, only in the HP48/49); math/algebraic tools and extended data manipulation (matrices, complex numbers, etc.). What surprised me was the ability of handling symbolic expressions with differential (derivative) and integration (with polynomial equivalent) as well. And as mentioned in some press advertisement, the HP28S was "the first portable equipment to offer symbolic algebraic manipulation based on resident system features (ROM)", i.e., symbolic manipulations features were recorded in ROM and did not need to be loaded as part of RAM-based software.

All of this amused me.

I like RPL and RPN as well, no matter what. No preferences, just a matter of demanding needs and available resources. I think easiness of using this or that system/resources also depends on operator acquaintance with the resource itself. Some users learn particular aspects faster than others: some prefer graphics, others prefer numbers, others symbolic manipulation. But all of them must prefer a pocket-size portable device to accomplish this all.

My thoughts, though.


#14

(Regarding RPL) In fact, I see as a major concern the stack
contents clearing from time to time if you allow previous results to
remain there...

At a first reading, I thought you meant that the stack contents were
cleared without the user doing anything. They aren't, of course; objects
are taken off the stack as operations use them as arguments. Of course,
it's not a good idea to just leave objects on the stack indefinitely. If
you want to save an object indefinitely, the stack isn't a good place to
do so; it would be too easily lost. Store such objects in a global
variable or in a port. Having more objects on the stack reduces the
amount of memory available to work in and slows down garbage collection,
and in the case of the 49G, seems to slow down everything. First, of
course, don't put extra copies on the stack without any reason for doing
so, and do some stack cleanup to get rid of things that you no longer
want on the stack. I think that most users clear the stack either when
finished with what they're doing, or before starting the next project.
If you want to keep some objects on the stack, the "Interactive Stack"
(VIEW up or down on a 28, CursorUp on a 48 or 49G, also HIST on a 49G)
is perhaps the easiest way to "manually" clean up or rearrange the
stack, especially when you're not sure about just what level objects are
on.

For someone who started with RPL, the RPN stack is a bit strange in that
it can't really be "cleared" in the same sense that the RPL stack is; on
my 16C, it seems that the closest I can come is having all four levels
filled with zeros. So far as I've noticed, if I really wanted to set all
levels to zeros, it's not a single operation (short of clearing *all*
memory).

LAST or LASTARG is perhaps most useful for error recovery, but can also
(usually) be used for reusing the arguments in another operation.

I am not sure about the other guys, but I care much about
T-contents replication when programming.

It is useful, but for an RPL user, it's a little disconcerting to find
extra copies of an object.

Regards,
James


#15

Thank you, James;

you are right; I'd rather write:

In fact, I see as a major concern the need of clearing stack contents from time to time if you allow previous results to remain there...

Long text, other language...

You wrote:

For someone who started with RPL, the RPN stack is a bit strange in that it can't really be "cleared" in the same sense that the RPL stack is; on my 16C, it seems that the closest I can come is having all four levels filled with zeros. So far as I've noticed, if I really wanted to set all levels to zeros, it's not a single operation (short of clearing *all* memory).

I agree with you. That's why I always call stack registers clearing in an RPN-based calculator and stack (actualy) clearing in an RPL-based calculator. And the HP16C is the only Voyager that does not have a "stack registers clearing" command (or function). All other Voyagers have their stack registers cleared when CLEAR[Sigma] (statistic registers) is performed.

The term clearing is not well used in some RPN-related literature, mostly because I feel as register clearing and register contents clearing as different actions. I cannot understand a register clearing procedure... Is it a fact or a misunderstanding of mine? I sometimes feel myself a bit confused about some terminology and I sort of create my own set of words to define some actions in a "better" way. At least in Portuguese I'm successful.

Thank you again.

Best regards.

Luiz C. Vieira - Brazil


#16

As HP points out in the manuals, clearing a register is just storing zero in it. It is insignificant if next you are going to store, or ENTER data into it, but does matter if you are going to use STO+ or other register arithmetic.

I guess I am talking about register contents clearing. If the comparison is between RPN and RPL calculators, then clearing the RPL stack destroys the objects on the stack - essentially clearing both the registers and the contents - while clearing the RPN stack just stores zero in all the levels.

Then you have the 17BII in RPN mode, where clearing the stack destroys all but the first level of the stack, and stores zero in it.


#17

Hello, Ellis;

you are right about HP17BII/19BII RPN implementation: in this case, clearing the stack means destroying Y-, Z- and T- registers. And as you may have noticed, pressing ENTER with a zero in the X-register will bring them back... with zeroes stored on them! Fascinating...

About RPL stack: as different objects have their memory requests, I believe HP28/48/49 design team decided to call stack "registers" as stack "levels", because the term register is so much associated with a group of seven bytes (HP calculators terminology except for the HP16C) that I believe it might confuse some users.

Best regards.

Luzi C. Vieira - Brazil

#18

I like RPL and RPN as well, no matter what. No preferences, just a matter of demanding needs and available resources.

I agree. So my time is shared between a 15C and a 48GX.

And I love both!

Raúl


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP48GX newcomer Eric Lundgren 6 1,600 10-07-2003, 01:20 PM
Last Post: Wayne Brown
  Newcomer has questions Trent Moseley 26 5,134 04-04-2003, 08:16 PM
Last Post: Vieira, Luiz C. (Brazil)

Forum Jump: