Re: "Enter" in RPN vs. RPL & threads
Message #55 Posted by James M. Prange (Michigan) on 5 Nov 2006, 9:18 p.m.,
in response to message #53 by Karl Schneider
And hello again to you Karl,
First off, I think that you're reading way too much into my post.
I'm not saying that Classic RPN is poorly designed; indeed, it's
it's a very good design, particularly considering what was
available to work with at the time.
What I am saying is that for someone accustomed to RPL models,
Classic RPN has some differences that are easy to forget. After
all, they're both RPN, and do have a lot in common; much more
than, for example, an RPN model and an algebraic or BASIC model.
Quote:
Oftentimes, those objects are leftover garbage from previous
calculations that slows down processing and must be purged.
Umm, maybe with your calculators, but with my calculators, I
always discard any unneeded objects from the stack before starting
a new calculation. In most cases, that means clearing the stack if
it's not already empty.
Quote:
Well, James, of course you know that the basic purpose of "ENTER"
on an RPN calc is to terminate data entry if manual entry of
another argument is to immediately follow.
Of course. My point is that it's easy to forget that Classic RPN
has some important differences from RPL.
Quote:
Arguments are already on the stack as they are keyed
in.
Exactly my point! Classic RPN doesn't have a separate command
line.
Quote:
Replicating the entry and disabling stack push enables
expedient doubling (number ENTER +) and squaring (number ENTER *).
How about "x sin x"? (number ENTER SIN *) Expedient replication
of an entered datum is valuable.
Quite so, and no doubt that's why with RPL models, when in the
standard stack environment (no command line or other "special
environment" active), the ENTER key is a shortcut for the DUP
command.
Yes, for your examples above, an RPL model requires two presses of
the ENTER key, one to do the ENTER, immediately followed by
another for the DUP command. Is that so difficult? I already have
my finger on the ENTER key, so doing a double press instead of a
single press is very easy. What may be difficult is remembering
that RPL and Classic RPN do have such differences.
Quote:
It could be argued that RPL's "ENTER" is inconsistent.
It's certainly true that RPL's ENTER key is frequently used for
purposes other than ENTER. Then too, many "immediate entry" keys
can do an "implicit ENTER".
Quote:
When ENTER immediately follows data entry (that is, when the input
buffer is not empty), the value is simply transferred from the
input buffer to the actual stack. Else, ENTER replicates the value
as RPN's ENTER does, except that stack push is enabled.
RPL's ENTER does quite a lot, some of it optionally depending on
such matters as whether the last stack and last command line save
modes are enabled, whether vectored ENTER is in effect, whether
there's a syntax error, and so on. Bill Wickes uses about three
pages for "ENTER in Detail", which you could read in
Insights.
Yes, if the only thing in the command line is the source for a
single data class object, then (normally) it looks to the user as
if all that happened was that the command line was closed,
returning to the standard stack environment, with the object moved
from the command line to stack level 1.
But suppose that my command line contains more than one data class
object? In that case, ENTER ends up placing the last one on level
1, with each preceding one on the next level up, just as if I'd
pressed ENTER after each one.
Or suppose that my command line looks like:
1 2 + 3 - 4 * 5 /
ENTER, among other things, parses the command line and combines
the objects into a single secondary (SysRPL program), which is
executed before updating the display. So for the above, the first
thing that the user sees different is the standard stack display,
with the result, 0, in level 1.
One way of looking at it is that the command line is a program to
be executed by ENTER (assuming valid syntax); it can even include
program structures. One could edit out the opening and closing
program delimiters of any UserRPL program, in which case ENTER
ends up "executing" the command line as if it were a program
(which indeed it as before the ENTER operation is complete).
Or one could view a program as a command line "quoted" with
program delimiters for deferred execution, so that it can be
placed on the stack and optionally executed, stored in a variable,
or anything else that can be done with an object on the stack.
Other special environments, such as the matrix writer, equation
writer, various input forms, and so on, each have their own
particular definitions for what a press of the ENTER key does in a
particular circumstance. Typically, it means "Okay, go ahead and
process this", or simply "Yes" or "Acknowledged". None of these
would apply to the standard stack environment, and the developers
very wisely chose to make it a shortcut to the DUP command there.
Quote:
As for replication of the t-register in the fixed-depth 4-level
RPN stack, the only reasonable alternative was to fill a stack
level with zero after its argument gets "popped down" by an
operation. That approach could give erroneous answers just as
easily as t-register replication after "stack overflow", and would
not provide the convieniences of replication -- e.g., an endless
supply of a value for Horner's Method evaluation of polynomials,
or arithmetic with a constant.
Quite so. It's the stack overflow that causes a problem, not the
replication of the t-register, which I believe I acknowledged was
a very good design feature.
Even so, the possibility of a stack overflow is one of those
things that can be a problem for those not accustomed to it.
I suppose that maybe they could've designed it to error out in
case of a stack overflow, but that would have the disadvantage of
requiring the user to clear the stack frequently, and with a
Classic RPN model, it's not so obvious what's in the stack
registers when the user is about to begin a new calculation. Also,
how would they detect a stack overflow? A user might intentionally
have a 0 in the t-register, in which case trying to lift the stack
should trigger a stack overflow error, just as when anything else
is in the t-register. I think that they made the best decision;
make the limitations clear, and depend on the user to stay within
them.
Quote:
Quote:
I think that I'll stick with the easy to use, very intuitive RPL
models. After all, what can be done with a Classic RPN model that
can't be done at least as easily with an RPL model?
Plenty, but those discussions have been held before:
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=51650#51650
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=82392#82392
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=49973#49973
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=87969#87969
http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=81691#81691
Come on now, my memory's not that bad. I also remember that after
those discussions, I was even more firmly convinced that RPL is
easier to use and more intuitive than Classic RPN. I've yet to see
anything that would tend to change that opinion. I have no doubt
that for someone not accustomed to RPL, it might seem difficult to
use and counter-intuitive, or that some will refuse to see any
advantages of RPL, no matter how apparent.
Quote:
In addition to these threads from several years ago, there were
several in which Valentin Albillo engaged you in lengthy
discussions about these issues.
Well now, it seem to me that comparing the 71B's BASIC and RPL is
much like comparing apples and oranges; they're certainly
"different", but I wouldn't care to say that either one is
"better". Certainly for me, not being familiar with the 71B, RPL
is better, and my impression is that for Valentin, the 71B's BASIC
is better.
Regards,
James
Edited: 6 Nov 2006, 5:40 a.m.
|
Go back to the main exhibit hall