|Re: "True" RPN Updated Features?|
Message #5 Posted by James M. Prange (Michigan) on 21 Nov 2005, 10:02 p.m.,
in response to message #2 by Ed Look
This is a tough question to answer past a certain point, as the
needs or preferences of different users would color their
perception of the answer. Of course, I suspect the two largest
camps are the surveyors and the engineers.
I suppose that surveyors would want I/O, preferably wireless and
not line of sight. Maybe Bluetooth? Other than that they'd
probably want to be able to store lots of data on the calculator;
maybe a low cost memory card like the 49g+, which also makes it
very easy to transfer data?
But basic connectivity, such as RS-232 compatible I/O, is
But probably the largest market is students. What would appeal to
them? Yes, apparently HP thinks glitzy colours and weird
keyboards, but I mean other than that.
I expect that new users are put off by RPN itself, after being
indoctrinated in the use of algebraic input models. Maybe release
a low-cost very basic "4-banger" model to "catch them young", when
they're first getting acquainted with a calculator. It wouldn't
have to be immediately very profitable; think of it as an
investment in developing a future market, or as an advertising
For that matter, I'd appreciate a shirt-pocket-sized RPN model for
myself, even if it didn't include the "scientific" functions or
But from a scientific point of view, and not at all
comprehensively, and from an idiot's first line of thought, I'd
say somehow, merge the power of RPL with the simplicity of
keystroke RPN programming (apologies to James Prange, sincerely!)
along with a multiline display, for example, the ability to view
at least blocks of the program if not in its entirety (tough to do
with the usual one or two line display of the usual scientific
No apologies needed; I can see that keystroke programming ought to
be very simple.
A multi-line display is useful, but at first thought, as long as
the stack is restricted to four registers, it wouldn't seem to
make much sense to have more than four lines. But maybe extra
status information could be displayed in the run mode and extra
code lines in the program mode? Maybe a larger display without the
special annunciators would be cheaper? Maybe different font sizes?
And then, as a personal preference, not necessarily a professional
one, I think it'd be best to preserve the keystroke aspect, even
to its display in the programming space, for the key itself, be it
shifted or not, tells you what it does.
But if I understand correctly, the 33S, for example. doesn't
always show you which key was pressed, but instead sometimes what
you chose from a menu. Surely seeing a command name in the display
should tell you what it does?
Of course, RPL has the powerful advantage of being able to express
a set of instructions (particularly equations) in a more concise
way than RPN keystrokes. Perhaps a blend of two, but I don't see
how that can be practicably done, given that a RPN machine has
only a four level stack. In fact, if a RPN machine can be given
the effectively infinite stack of a RPL calculator (plus the
attendant RAM increase), I think this in itself would be a
Of course I prefer a variable stack without the t register
replicating downward. But perhaps the user could optionally
restrict the stack that he can use to a particular depth, and
optionally with the top level replicating downward on stack drops.
Regarding equations, how far would you care to go with various
object types? In the RPL models, an algebraic object is internally
identical to a SysRPL secondary (program), with the differences
being a different prologue, and the algebraic being restricted to
RPL sequences that are logically equivalent to a valid algebraic
expression. For example, if I key in 'X^2+Y^2=R^2' in the command
line, then the compiler changes the order of the elements to:
'X' 2 ^ 'Y' 2 ^ + 'R' 2 ^ =
for internal use. Converting an algebraic expression to an RPN
sequence and back to an algebraic expression is completely
deterministic and seems well suited to a machine. But not just
anything keyed in as an algebraic is valid; syntax checking is
required. And not just any RPN sequence can be converted to a
valid algebraic, for that matter. Without going to full-fledged
RPL-style "objects", you'd still need a way to keep track of the
length of the sequence, perhaps by storing delimiters.
Finally, I think it would be wonderful to add variables (again,
with relatively big RAM) to register storage, just for the
flexibility of it.
Certainly being able to call an object by an associated name is a
big advantage. And so is specifying the scope (global or local to
a procedure). In the RPL models, local environments can be
"nested", and if a local name in an "inner" procedure happens to
match a name in an "outer" procedure (or global, library, or
command name in the search path) then only the most recently
created local variable with that name can be accessed. Directories
in the RPL models (except the 28C) also serve to specify the
search path. Unless the path is specified along with the global
name, only names in the current and parent, grandparent, etc.
directories can be found, and after searching each directory, any
associated library is searched for the name.
(Am I dreaming... ?)
Maybe, but it seems to me that the development of the 33S has been
mostly getting the 32sII capabilities working on new hardware and
trying to get the bugs out. Maybe they'll come out with a 33sII,
33S+, or whatever, that takes more advantage of the capabilities
of the hardware.
Edited: 21 Nov 2005, 10:11 p.m.