"True" RPN Updated Features?
#1

What if development of high-end HP Calculators had followed the direction set by the HP-42S?

In the debate between devotees of RPN and RPL calculators, the RPL camp has a distinct advantage in that development of those machines has continued over time, albeit at a slow pace after HP drew in its horns in the calculator market. "True" RPN calculator development seems to have stopped with the HP-32SII and HP-17BII. But the pinnacle of RPN calculator development (neglecting important considerations like I/O) was probably the HP-42S.

So, what if Prof. Wickes hadn't decided to go with the radical and revolutionary architecture first exposed to users in the HP-28C? How would a more evolutionary approach to the revolutionary increases in processor power and memory size have changed high-end HP calculator models? How could some (or all!) of the advantages of the RPL calculators be realized using a more traditional RPN model?

These questions are inspired by this post by James M. Prange, in which he offers up a sharp critique of the Voyager models as programmables from the standpoint of a user/programmer who is used to RPL. Some of his points are due to the differences between RPN and RPL, but many are there because the Voyagers are old, mid-range machines. What if there were an updated RPN machine with a modern processor and memory size and an updated RPN OS to take advantage of them?

#2

Good post, just as good as James' which inspired yours.

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.

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 programmable).

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.

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 significant improvement.

Finally, I think it would be wonderful to add variables (again, with relatively big RAM) to register storage, just for the flexibility of it.

(Am I dreaming... ?)

Edited: 14 Nov 2005, 2:21 p.m.

#3

I'm a big fan of RPN keystroke programming and not such a big fan of RPL. It seems most natual to me when using a calculator. If I can work the problem out manually, recording my keystrokes to automate that process seems a perfect fit. If I can't work the problem out manually, I'll use a different tool.

RPL always felt like too much of a real programming language... but as a software engineer fluent in a wide variety of mid-to-high level languages (most notably C/C++) and a dozen flavors of assembly language, it seems to come up short - constrained by the interface more than anything else. In the end, if I want to program a complex algorithm I'll do so in a language that I find more flexible and more powerful and run it on a common PC or equiv. When I want to crunch numbers (and I love to crunch numbers with a calculator), I'll do it with manual entry or keystroke programming.

I liken a good calculator to a good hammer. It's a tool. A workhorse. Something that can drive nails and occasionally pull them. I don't want it to drive screws. I don't want it to cut boards. RPL feels like it tries to do too much - which was probably useful back when PCs were expensive and not on every desktop. I want a calculator to calculate - plain and simple automation with keystroke programming sits right at the boundary of simplicity and functionality. It's probably the same reason I'm not fond of graphing calculators, though I'm fine with people that like both RPL and graphing calculators. To each, their own.


In designing Excalibur, I had the opportunity to do design my own custom language (or borrow heavily from existing syntax or lexical parsers) but I stuck with keystroke programming. Simple, clean, effective. If users need more, they can work it out with Excel, Mathcad or Matlab.

#4

I second you, Howard.

What never war really discussed here, is also the difference the most evolved RPN calculator has (42S) versus the most evolved RPL has (49G+) regarding the user interface.

Many of the (complicated?) RPL commands in the big command list of a 49 (and even 48) are display related. With the step from a line interface to a graphically oriented UI you have to deliver a big bounch of output and graphic manipulation functions to the user. And having this new GUI now you have also to deal with different font types. This is a terrific PLUS in commands and dependencies to remember and that's probably one of the reasons I still feal unconfortable programming ad hoc my RPL calculators.

Returning to your toughts: IF - after the 41 series, the 42S and the last 32SII - hp invested further in functionality of RPN based systems: What UI would they have?

The 42S started with some graphical capabilities. Would this have been the way to go? Towards a fully graphical RPN calculator? I suppose, the simplicity we are looking for, would have wanished; also still having the RPN paradigma.

Since the 41 series have faded out I also dream - from time to time - of a successor. But when I think of a modern follup, I have to compete with today's state of the art calculators like a TI-89 (or hp49G+). And then I'm really not shure where the journey of a new high end calc should go...

(not yet satisfied, not yet decided...)
Valentino

#5

The HP42S showed the way, IMHO. First, you must stick to the 4-level stack because (as someone stated previously) unlimited stack allows or even naturally leads to complicated states which you must remember.
Then, every stack level / register / variable should be able to hold any type of data, this includes lists of any depth, matrices, variable names, strings / texts (the latter having style maybe). Indirect addressing would be extended to multiple levels or depths : if R00 contains {1 2} and R01 contains { {'A' 33} 47}, RCL IND 00 would return 33.
A big plus of keystroke programming and the fact that you have a program persistant pointer is that you can stop the program, modify it, then resume. I wonder why this is not possible in RPL ??? It is such a strong point for RPN.
I would like also parameter passing and local variables ; however how could this be done ? The 42S has a way to declare variables at the beginning of a program, this should be extended.
Also PLEASE keep GTO and LBL, the possibility to route the processing flow anywhere is just so powerful.
Last idea, operators can be combined in a logical way so there is not a gazillion keywords to remember. For example + can add numbers, integers, matrices, lists, strings, but you can have more : I recall when I used APL, a very powerful "math" oriented language, where you have for example the following rule :

The matrix product is calculated like Sum ( Product of an element of line... by an element of col...), you would write it like : A<-B+.xC which is "store into A the matrix of the sum (+) of products (x) of terms ... from matrices B and C".
Then you could also write something like : A<-BL.+C which would mean "store into A the matrix of the minimum (L) of sums (+) of terms ... from matrices B and C.
This kind of meta-syntax lets you combine locically building blocks.
I'm not sure this is clear !

#6

Quote:
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'd love to hear a diversity of opinion about this subject. I figure I'll get my wish around here. 8)

Quote:
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 programmable).

OK, I hear this:

  • Preserve the simplicity of keystroke programming.
  • A multiline display wih the ability to view some context around the line you are editing.
  • This probably means >2 lines.
Quote:

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.


Can you give an example of what you mean by this?

Quote:
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 significant improvement.

OK, so why not combine the environments in some way? I like this idea. You could have a keystroke RPN mode, or a full RPL programming mode. The calculator would be capable of executing either type of program in any context. They would both share the same stack, variables, registers, and so forth. One type of program could freely call the other type.

Quote:
Finally, I think it would be wonderful to add variables (again, with relatively big RAM) to register storage, just for the flexibility of it.

Named variables should be able to act as registers in the keystroke/RPN mode. Registers would, in fact, be just predefined (but not preallocated) variables.

Quote:

(Am I dreaming... ?)


Well, yes you are. But that's what I asked for!

Thanks!

Howard

#7

It sounds like the "replacement value" of FORTRAN to me!

But you're right about the ability to stop program and resume or resume differently because of the program step pointer in RPN. But I think primarily that was designed in as an editing feature, like the ability to step through a program in a test run showing you the results of each step in RPL.

#8

Quote:
...
Quote:

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.


... Can you give an example of what you mean by this? ...

... Thanks!

Howard


Oh, by that I simply meant that while writing or viewing the program itself, what is visible is the keystroke that is recorded as a program line. I should add, as it is now done in the HP 33S, unlike the way it was in my old HP 34C, which displayed only the "coordinates" of the key(s) pressed for a given line of program. This to me is very easy or "natural"... I suppose because RPN keystroke recording was my first intro to programming any calculator.

Edited: 15 Nov 2005, 11:41 a.m.

#9

Quote:
The HP42S showed the way, IMHO. First, you must stick to the 4-level stack because (as someone stated previously) unlimited stack allows or even naturally leads to complicated states which you must remember. ..

I think you need to be able to set the stack as you see fit. One man's complexity is another's playground. I find an unlimited stack confusing, but the RPL guys revel in it. Allowing the user to set the stack size as a preference gives us the best of both alternatives.

Of course, if I'm modifying a program someone else has written that uses a deep stack, I'm going to have as much trouble as ever keeping track. But in my view, it's not worth taking choice away from the user in order to make that sort of thing easier.

Quote:
Then, every stack level / register / variable should be able to hold any type of data, this includes lists of any depth, matrices, variable names, strings / texts (the latter having style maybe). ..

Good idea! This is a feature of RPL machines that I would also like to see retained in an updated RPN calculator.

Quote:
Indirect addressing would be extended to multiple levels or depths : if R00 contains {1 2} and R01 contains { {'A' 33} 47}, RCL IND 00 would return 33. ..

Intersting This could be done in lots of different ways. For example, a list in R0 used as an indirect address could return a list of all the elements pointed to in the first list, assuming they all resolved either to a register number, a named variable or some other reference. Talk about complexity! Is there anything like this in current RPL machines?

Quote:
A big plus of keystroke programming and the fact that you have a program persistant pointer is that you can stop the program, modify it, then resume. I wonder why this is not possible in RPL ??? It is such a strong point for RPN. ..

I believe this is possible on the HP48G. But you have to be in debug mode. You can single step through a program and do anything you like in between steps. Maybe the RPL guys can comment on whether you can also change the program pointer to any point and continue execution or not?

Quote:
I would like also parameter passing and local variables ; however how could this be done ? The 42S has a way to declare variables at the beginning of a program, this should be extended.

RPL has the "-> var list << .. >>" syntax for creating local variables on the fly. Perhaps that could be adapted into the keystroke programming model?

Quote:
Also PLEASE keep GTO and LBL, the possibility to route the processing flow anywhere is just so powerful.

I agree with this, on the basis that system designers shouldn't make arbitrary limitations on what users can do if they can help it. RPL lacks a loop "break" statement, which probably reflects the distaste for GOTO that prevailed in the 1980s. "Structured" programming was supposed to make GOTO obsolete. And the construct was (rightfully) blamed for a lot of unmaintainable "spaghetti" code. If there's a danger of exciting a flame war over whether GOTO is needed or not, I'd like to avoid it if possible. So suffice it to say that some users consider GOTO to be useful, so an updated RPN programming model should retain it.

Quote:
Last idea, operators can be combined in a logical way so there is not a gazillion keywords to remember. For example + can add numbers, integers, matrices, lists, strings, but you can have more : I recall when I used APL, a very powerful "math" oriented language, where you have for example the following rule :

The matrix product is calculated like Sum ( Product of an element of line... by an element of col...), you would write it like : A<-B+.xC which is "store into A the matrix of the sum (+) of products (x) of terms ... from matrices B and C".
Then you could also write something like : A<-BL.+C which would mean "store into A the matrix of the minimum (L) of sums (+) of terms ... from matrices B and C.
This kind of meta-syntax lets you combine locically building blocks.
I'm not sure this is clear !

How does RPL handle this stuff? Are there useful constructs there that we could borrow?

Regards,
Howard

#10

Quote:

.. And having this new GUI now you have also to deal with different font types. This is a terrific PLUS in commands and dependencies to remember and that's probably one of the reasons I still feal unconfortable programming ad hoc my RPL calculators. ..

The 42S started with some graphical capabilities. Would this have been the way to go? Towards a fully graphical RPN calculator? I suppose, the simplicity we are looking for, would have wanished; also still having the RPN paradigma. ..


Yes, GUIs can be complicated. Yes, RPL GUIs are complicated! But you can provide the complicated GUI, and also document a path through the complexity for the keystroke programmer. That is, abstract out of the multi-volume user manual a thinner one that shows you how to program in RPN. This simpler mode might include simpler graphics commands, probably built up from the more powerful graphics primitives provided by RPL.

In the desktop and server computer worlds, there are a multitude of such toolkits that seek to simplify access to complicated graphics subsystems. Of course, most of them end up being complicated in themselves. I think that's because they try to be as general as possible, and also because toolkit designers tend to get carried away. 8)

But a GUI toolkit for an RPN calculator wouldn't have to be fully general. The keystroke progamming approach is aimed at relatively short programs that automate a particular mathematical task. For that, the most complicated GUI object you would need would be an equation editor. There's a pretty nice one of those in the HP-49G+. It's not awfully hard to use, either. The 33S has a less capable, but still usable and useful one.

So I say keep the fully general graphic capability, perhaps working to simplify it for its own sake, but provide high level graphic operations that a keystroke program can call to do the hard GUI work. If the user wants a GUI feature that's not in the list, well, there's still RPL and the full generality it provides.

Regards.
Howard

#11

Quote:
The HP42S showed the way, IMHO. First, you must stick to the 4-level stack because (as someone stated previously) unlimited stack allows or even naturally leads to complicated states which you must remember.
I'm not an RPL user, but I can tell you from plenty of experience in Forth that an unlimited stack does not require any more brain-twisting than a very small one. In fact, an effect of the improved data flow is that you don't need as many variables, and in most cases the need for local variables disappears altogether. Each "word" in Forth concerns itself only with its own small portion of the stack, seldom more than three items. If you have a hundred stack cells under that, it doesn't matter. For each little subroutine, you focus only the stack cells used by that one. It in turn may call others, which may call others, and so on, (even recursively!) but the modularity is part of good programming, and keeps a very complex program manageable. The depth of the stack becomes a non-issue.

Quote:
A big plus of keystroke programming and the fact that you have a program persistant pointer is that you can stop the program, modify it, then resume. I wonder why this is not possible in RPL ??? It is such a strong point for RPN.
It could be done, but (again, a comment coming again from a Forth programmer and not an experienced RPL man), you may have problems if branch locations stored in program structures get changed by your tinkering after they had already figured out where to go. All the ways I can think of to get around the problem make a big cut in performance.

Quote:
I would like also parameter-passing and local variables ; however how could this be done ?
Again, the stack can be used or this. Parameter-passing becomes implicit, natural, very efficient, and in the case of Forth, virtually eliminates syntax requirements. Local variables, if still needed, can be set up on the return stack since they are no longer needed when you exit the subroutine, subprogram, or similar.

Quote:
Also PLEASE keep GTO and LBL, the possibility to route the processing flow anywhere is just so powerful.
Those are nice and simple for keystroke programming. I don't miss them in Forth, although Forth does allow you to invent your own program control structures if it would help your application. A good set of them makes it much more clear what you're doing, without limiting the possibilities. The words "branch" and "0branch" in Forth are internals, meaning you normally only deal with them if you're writing a program structure. Examples of a few standard ones where the need for internal branching is obvious include DO...LOOP, IF...ELSE...THEN, BEGIN...WHILE...REPEAT, etc.. The same branching words could be used outside structures like these, but such use would usually mean that you're about to lose control of your project! I would not disagree however that GTO and LBL have their place in keystroke programming of small applications.
#12

Hi, Garth,

Sort of in the same spirit of not wanting to ignite a flame war over GOTO, I'd like to steer away from the debate whether a deep stack or a short one is preferable. I think it's obvious that different programmers have different opinions on this. Your point about avoiding complexity by limiting stack usage is a good one, though.

But since calculator programmers do differ on this point, what I'm most interested in is how to define a programming environment that woud allow for multiple ptogramming models to live side-by-side. It would be a simple enough matter to specify a maximum stack size, or no maximum, either globally, or locally to a particular sequence. You'd think that would get interesting when you wanted to call one model from another. But in most cases I can think of, there would be no problem. The 4-stack level routine wouldn't ever expect more than that many input parameters on the stack. The only difficulty might be when a 6 stack routine, say, wanted to call a routine that returned 7 parameters on the stack. I think that would be rare, though.

Regards.
Howard

#13

Quote:
In the debate between devotees of RPN and RPL calculators, the RPL
camp has a distinct advantage in that development of those
machines has continued over time, albeit at a slow pace after HP
drew in its horns in the calculator market.

Huh? More nearly continuous than with RPN models, but far from
continuous. I mean UserRPL models, not including models that used
SysRPL for development but didn't offer UserRPL.

Development of RPL models temporarily effectively ceased with the
release of the 48G series Version R, apparently in production by
April, '94. After that, development started up again with a whole
new team at ACO, and the 48G+ was announced 1998-03-30. but the
48G+ took hardly any development; still version R, effectively a
48G with a 128KB RAM instead of a 32KB RAM, and a new label. The
next RPL model was the 49G, announced 1999-05-21. The 49G did make
significant advances, but is far from being as good as one might
expect. But then ACO was disbanded 2001-11-09. I'm not sure when
the new team was formed, but it did exist by September 2002, with,
as far as I know, one member from the ACO team, and some plans for
the future. The first 49g+es started arriving in October, 2003 and
I think the 48gII not too long after that. The 49G+ and 48gII are
mostly a matter of adapting to new hardware and taking advantage
of some of the new hardware's built-in capabilities; notably, they
don't add any UserRPL commands not already in the 49G, although
there have been some bug fixes and the 49g+ has limited formatting
capability for the card. The 49g+ still leaves a lot to be
desired.

I can't help wondering what the RPL models would be like today if
development of them really had been continuous, with new team
members being trained as old team members left. I'd bet that
they'd be a whole lot more advanced and usable than the 49g+.

Regards,
James

#14

Quote:


Huh? More nearly continuous than with RPN models, but far from
continuous. ..


Well, that's right. Apologies for making it seem like the RPL machines don't suffer from some of the same neglect as the RPN models.

But the fact remains that the RPL machines are more advanced than any RPN machine ever made. I think that at least part of that gap is due to the shift to RPL from RPN by HP, and the consequent neglect of the latter. Well, to be honest, I think all of the gap is due to that.

What I'm interested in is whether it is possible to come up with a high-level architecture that allows RPN and RPL to coeexist, and hopefully play off each other's strengths, in an updated machine sporting modern hardware. (Or purely in software, in the alternative.)

Quote:

I can't help wondering what the RPL models would be like today if
development of them really had been continuous, with new team
members being trained as old team members left. I'd bet that
they'd be a whole lot more advanced and usable than the 49g+.


That's really the same question I'm pursuing, but one or two generations down the pike. So, what do you think they would have come up with in the way of new or improved features? I see no reason to cut of the discussion of desirable features just because they don't involve RPN. (Although I will undoubtedly try to relate anything you suggest to RPN myself. 8)


Quote:
Regards,
James

Likewise,
Howard

#15

The intent of Howard's post seems to be how the features of the advanced RPL-based calculators might be adapted to an advanced RPN-based model.

Well, quite frankly, my opinion is that the time for a super-duper handheld calculator may have already passed. Sure, I know that the TI-89, TI-86, and TI-83 are used extensively today in secondary education. However, this is not necessarily a positive development in the instruction of mathematics, what with the emphasis on teaching keystrokes and techniques for specific devices, instead of mathematical fundamentals.

That having been said, the best opportunity for development of a "super RPN" model would have been to design the original 48-series models around RPN, and to simplify the functionality, with emphasis on utility and expandability instead of whiz-bang mathematical functions and computer-like file and data management.

Consider a slightly-downsized 48S/SX based on Classic RPN with the following:

  • A user-settable fixed stack
  • Easy-to-use I/O
  • Time functions and clock
  • Easy-to-use 2-dimensional graphing
  • High-resolution dot-matrix black LCD screen
  • Unsurpassed complex-number functionality
  • Matrix functionality improved from that of the 42S

    Optional features:

  • Plug-in cards for program applications and storage
  • HP-71B BASIC with alpha labels instead of line numbers

That's what I think the 48S/SX should have been. It would offer the easy expandability and utility that surveyors and field engineers prize -- just plug in or download advanced programs. Informative and useful graphs appropraite for the machine's capabilities would be and easy to obtain -- no studying the manual to do basic things, and no crude monochrome 3-D rendering.

Comprehensible BASIC, instead of arcane RPL, would provide the programming capability for advanced applications that would be awkward or cumbersome on RPN.

But, it's probably too late for that now. In fact, I think even the 42S would be too advanced a calculator to develop today, now that PDA technology is available.


There is one conceptual non-graphing RPN calculator that I think is worth developing -- one that combines the user paradigm of the 32SII with the (improved) complex-number and matrix functions of the 15C, in a no-nonsense package about the same size as either.

  • The display should be one-line, with large characters for legibility.
  • The display should be longer, to accommodate equations more fully and to display complex numbers.
  • The equation editor should allow insert/delete editing, support implicit multiplication, display sub- and super-scripting, and use more symbols instead of names like "SQRT" and "SQ".
  • The stack should be of constant user-settable depth in RPN fashion, with only Rdown, Rup, and x<>y.

-- KS

#16

Quote:
But the fact remains that the RPL machines are more advanced than any RPN machine ever made. I think that at least part of that gap is due to the shift to RPL from RPN by HP, and the consequent neglect of the latter. Well, to be honest, I think all of the gap is due to that.

I don't think it's neglect so much as plateau. It's hard to improve on brilliant simplicity. HP wanted more - and rather than try to tweak RPN, they took some of the best features of RPN, extended it and and came up with the LISP-like RPL. What they got, IMO, is something both more powerful... and less so.

In any event, RPN was plenty powerful enough 35 years ago and remains so now. I believe it also remains (by a wide margin) the most elegant way to crunch numbers on a calculator.

#17

Hi, Karl:

Two brief commentaries to your post:

  • In your post you mention, "Unsurpassed complex-number functionality", you say:

    "A few of HP's calculator models have introduced useful capabilities for calculating with complex numbers. These include the 15C, the 28C, the 42S, the 48S/SX, and their direct descendants.
    [...]
    Each calculator in the former group has pioneered a good idea:

    15C: Provided complete functionality in the mathematical domain of complex numbers

    28C: Provided straightforward single-line entry and a comprehensive menu of relevant functions

    42S: Provided rectangular or polar modes for entry and calculation, with easy-to-read full display

    48S/SX: Allowed entry of complex numbers in either form while set in either rectangular or polar mode"

    Perhaps due to lack of familiarity with it, you fail to mention HP-71B's Math ROM complex number handling, which as far as I know, pioneered the 'ordered pair' mathematical concept for complex number handling, that is:

        2 + 3i   is represented as  (2, 3)
    This format is highly favored in serious mathematics, as it has
    a number of advantages and, certainly, does away forever with the 'imaginary' stigma that complex numbers have historically been saddled with (still present in "i", short for "imaginary unit").
    With this convenient format, you have:
          (1, 0)  is the real unit
    (0, 1) is the "imaginary" unit
    and symmetry is evident, both real and imaginary parts are treated the same, no typographical distinction between them (such as attaching an "i" to the number representing the imaginary part, while nothing at all is attached at the real part). Also, representing complex numbers that way, the 71B's Math ROM allows such expressions as:
             ( 2+5*PI/3, 5-4*PI/3 )
    which seems more natural and less contrived than:
             (2+5*PI/3) + (5-4*PI/3)*i
    and you also have:
             (1, 2) * (3, 4) = (-5, 10)
    which is as simple and neat as it can be. Of course, this also works like this with parameters passed to functions and subprograms, results returned, matrices, and evaluating expression from the command line or in CALC mode.

    For instance, in DATA statement, you can define complex data like this:

      10 OPTION BASE 1 @ COMPLEX A(5)
    20 READ A
    ...
    90 DATA (1,2), (-3,4), (5,7), (0,13), (23, -27)
    which reads all complex data in complex vector A at once and, again, is much more neat and elegant than what you would achieve with other constructions.

    Finally, the Math ROM also implements ("pioneers") built-in, special IMAGE formats for complex numbers, where you can define each part's format, as well as have it printed with the "i" if you feel like it, etc. I think all of this fully qualifies as 'significant achievement' in complex number handling by HP handhelds.

  • Also in your post, you mention:

    "HP-71B BASIC with alpha labels instead of line numbers"

    HP-71B's BASIC *does* support alpha labels, no problem. Of course, it also has line numbers because of ANSI standards compatibility, but you aren't forced to use them if you don't want to. For instance:

        10 GOSUB "FINDROOT"
    20 IF X=7 THEN "FOUND"

    ...
    90 "FINDROOT": X=27 @ y= 28 @ ...
    ...
    120 "FOUND": PRINT X; SQR(X) ...

    which is more, you can have labels in mid-line, which means you can branch at the statement level ! For instance:

        10 ON X GOTO "HERE", "THERE", "HOME"
    ...
    90 "HERE": (do something) @ "THERE": (do something) @ "HOME": (do something)
Best regards from V.

Edited: 16 Nov 2005, 10:05 a.m.

#18

Hello, Valentin --

Thank you for the thoughtful reply.

I don't fully share your view on several points, though:

Quote:
Perhaps due to lack of familiarity with it, you fail to mention HP-71B's Math ROM complex number handling, which as far as I know, pioneered the 'ordered pair' mathematical concept for complex number handling, that is:

2 + 3i is represented as (2, 3)

This format is highly favored in serious mathematics, as it has a number of advantages and, certainly, does away forever with the 'imaginary' stigma that complex numbers have historically been saddled with (still present in "i", short for "imaginary unit").


You are right about my "lack of familiarity": at the time of my original posting, I did not have a Math ROM or manual. Now I have both, but haven't thoroughly delved into it. I'm sure that the HP-71B Math ROM did pioneer some advanced complex-number capabilities that should be recognized.

Perhaps the "parenthesized" representation of complex numbers is favored in high-level math, but I'm not very enamored of it. For one, it could be confused with an ordered pair of coordinates or measured data at a point in time. True, complex numbers are graphically represented on a plane, but not every point on a two-dimensional plane is a complex number.

Also, I was more concerned with numerical values of complex numbers, not expressions of them. (A typical calculator display line could not hold an entire expression anyway.)

IMO, the HP-42S representation of, e.g.,

-3.141593 -i2.718282

is cleaner than the RPL-model representation of

(-3.141593,-2.718282)
This is especially true for complex-valued matrices, which on an RPN-based calc would be littered with parentheses, commas, and brackets.

As for the "stigma" of 'imaginariness', well -- I wouldn't know how to pay someone US$ sqrt(-1)...

In summary, my focus here is still expedient usage for calculators. I still think that my concept of an [+i*] or [i] key, handled like [EEX] or [E] would be ideal:

[4][.][1][6][5][CHS][i][1][3][.][6][CHS] would yield -4.165 -i13.600

The [i] key could be [g]-shifted to yield an angle symbol for polar-coordinate entry; it could be [f]-shifted to bring up a menu of complex-number functions.

Best regards,

-- KS

Edited: 17 Nov 2005, 10:27 p.m.

#19

Here's another area where people differ according to their tastes. My approach to that would be to allow many different representations of complex numbers, but only one (rectangular form) at a time. As long as none were ambiguous, my preference would be to allow your preference. 8)

That's nice for the calculator as a personal machine. It gets less nice when you want to work on someone else's program. On the other hand, if I can select a particular form for complex numbers on my machine, then your program will look just fine to me when I load it there.

#20

Howard --

Quote:
My approach to that would be to allow many different representations of complex numbers, but only one (rectangular form) at a time.

This is what the 42S and RPL models already do. However, I disagree with the approach.

Voltage (V) and current (I) on an AC network are sinusoidal phasors that are invariably represented as complex numbers in polar coordinates.

Impedance (Z = R + jX) and admittance (Y = 1/Z = G + jB) are complex-valued non-phasors that are represented in rectangular form.

Complex power (S = P + jQ) is composed of real (active) and reactive power in rectangular coordinates.


Since I = (delta V) / Z, complex I (in polar coordinates) is the quotient of a difference of two complex numbers in polar coordinates, divided by a complex number in rectangular coordinates.

Since S = V * conj(I), complex S (in reactangular coordinates) is the product of two complex numbers in polar coordinates.

This is why, if I enter a complex number in one form, I do not like the calculator to change its representation when a different entry mode is selected. Remember, they are the same value in either form, just shown differently.

-- KS

#21

I could be completely confused, (complex numbers do that to me sometimes,) but do you want to represent two complex numbers in two different rectangular styles in the same calculation? I don't know how the calculators do it, but if it were me, I'd allow polar and rectangular forms together, but not more than one style of the latter. I guess multiple rectangular styles would be OK, assuming an unambiguous syntax were preserved. But I'd think "A + Bi" in one place, and "C,D" in another would get pretty confusing.

#22

Karl,

Quote:
True, complex numbers are graphically represented on a plane, but not every point on a two-dimensional plane is a complex number.

Are you sure? The set of real numbers R is a subset of the set of complex numbers C (with the imaginary part being zero.) So the hole plane is a represenation of the complex number set: Just take the x coordinate for the real part and the y coordinate for the imaginary part.

A two dimensional plane is just one way to represent C: It can likewise be treated as a vector space with each value represented by a length and an angle. This is what polar coordinates are all about.

Marcus.

#23

Hi, Karl:

Karl posted:


"For one, it could be confused with an ordered pair of coordinates"

That's the idea, precisely. Remember that this kind of representation is called "an ordered pair", not "a parenthesized representation". How you do typographically represent an ordered pair is up to you, but "(a, b)" is pretty usual. It could be "{a, b}" or "a|b", or whatever.


"complex numbers are graphically represented on a plane, but not every point on a two-dimensional plane is a complex number."

I disagree. There's a one-to-one correspondence between points in a 2-dimensional plane and complex numbers. Any point in a 2D plane is defined by its coordinates (x,y) which are an ordered pair, thus the representation of some complex number.


"(A typical calculator display line could not hold an entire
expression anyway.)"

In the case of the HP-71B, its 22-char display allows the representation of "(a, b)" at once in most practical cases.


"IMO, the HP-42S representation of, e.g.,
-3.141593 -i2.718282
is cleaner than the RPL-model representation of
(-3.141593,-2.718282)"

Again, I disagree, but then I'm strongly mathematically oriented, thus I'm myself quite comfortable dealing with this kind of notation. Also, it's mostly a matter of personal taste.

"As for the "stigma" of 'imaginariness', well -- I wouldn't know how to pay someone US$ sqrt(-1)..."

You also don't know how to father 355/113 childs or -3.1415 childs, I presume, and that doesn't make rational or negative real numbers "imaginary".

"Imaginary" is a stupid label attached to complex numbers for historical reasons, they aren't any less "real" than real numbers, and when you think about them as an ordered pair, the distinction all but vanishes, as (3,0) seems then as "real" as (0,3), don't you agree ?

Thanks for your interesting comments, it's always a pleasure to read your posts.

Best regards from V.

#24

I may add to Valentín's comments that there are some physics concepts (physics are real enough for me) in fields like electric power, radio, audio, airfoil design, etc. that are very difficult to understand or explain without resorting to complex numbers. If you are talking to a complex-aware audience, such concepts are most easy to present and discuss.

Given the very particular economical situations we have lived thru in Argentina some years ago (certainly not a matter of national pride, quite the opposite), I have already posted here a possible approach to explain such facts using a complex currency. For instance, a complex money amount deposited at a complex interest rate may give a negative balance if you are not fortunate enough with your deposit-withdrawal timing. You deposit $ 1000, wait for a certain amount of time and... you have $ -100 (!!). But, if you wait for a couple of extra years, you may have $ 500 again, and you will view such outcome as a winning proposal.

Our brazilian neigbors currency sign is the "REAL", or R$; so if argentinian currency someday becomes the "IMAGINARY", denoted as i$, our newborn common market, the Mercosur, may have a common currency which will be truly "complex" indeed.

#25

Howard --

I see that I may have misunderstood. I agree that complex numbers should be representable in only two ways -- one style in rectangular form, or one style in polar form. I would prefer the HP-42S style:

-3.00 -i4.00
5.00 <-126.87 (< = angle symbol)

over the HP-48 style:

(-3.00,-4.00)
(5.00,<-126.87) (< = angle symbol)

but Valentin might not. ;-) (See other posts in this thread.)

My complaint with the 42S and the 48/49 models is that, when the user changes the entry mode between rectangular and polar, all complex-valued stack elements and register elements are displayed in the selected mode. I would prefer that all complex numbers be displayed in the format in which they were entered. My example showed "mixed-mode" calculations with complex numbers, wherein to change the display format would render values unmeaningful.

I suspect that the designers of the math capabilities did not have backgrounds in electrical power systems.

-- KS

#26

Quote:

.. I would prefer the HP-42S style:

-3.00 -i4.00
5.00 <-126.87 (< = angle symbol)

over the HP-48 style:

(-3.00,-4.00)
(5.00,<-126.87) (< = angle symbol)


Got it. That's why I'd let you select your preferred rectangular display style, and Valentin could have his. In a modern machine, the memory and processor power to acheive that flexibility would be available.

Quote:

My complaint with the 42S and the 48/49 models is that, when the user changes the entry mode between rectangular and polar, all complex-valued stack elements and register elements are displayed in the selected mode. I would prefer that all complex numbers be displayed in the format in which they were entered. My example showed "mixed-mode" calculations with complex numbers, wherein to change the display format would render values unmeaningful.

I suspect that the designers of the math capabilities did not have backgrounds in electrical power systems.


Or perhaps the memory and/or CPU power weren't there to acheive multiple simultaneous representations. The conversion between rectangular and polar coordinates shouldn't have been a limitation in the HP-48, but the display resources might have been. You'd also have to make room in each complex object's storage for "preferred display mode" in order to implement mixed mode representation that tracked a user or (via default) a system preference. All that is doable, of course, but would have involved more overhead.

Regards,
Howard

#27

Marcus von Cube and Valentin Albillo took issue with my admittedly imprecise statement,

Quote:
True, complex numbers are graphically represented on a plane, but not every point on a two-dimensional plane is a complex number.

What I meant by that was, not every ordered pair -- which is typically graphed on an two-dimensional x-y or R-theta plane -- should be interpreted as a complex number.

  • For example, calculated or observed points on a time-domain function could be represented as the ordered pair
    (t, f(t)).

  • Or, two separate characteristics (e.g., height and weight) of each person in a set could be organized as ordered pairs and plotted on an x-y graph to investigate correlation.

However, neither of these examples of ordered-pair data should reasonably be read and treated as a "complex number".

This is why I disfavor the parenthesized ordered-pair representation on the RPL-based calculators. A bona fide complex number could easily be confused with an ordered pair of (x,y) data intended for regression analysis, Fourier analysis, or other kind of curve fitting. But, in RPL, everything's gotta be an "object"; hence, the parenthesized ordered-pair.

Valentin also disagreed with several of my other statements, which I'd like to address:

Quote:
K: "(A typical calculator display line could not hold an entire expression anyway.)"

V: In the case of the HP-71B, its 22-char display allows the representation of "(a, b)" at once in most practical cases.


Yes, but again, I'm focused on compact calculators. The small-character, two-line, free-format LCD of the HP-42S allows display of the following:

  • up to 7 digits (including "E") of each component
  • the "." for both
  • "i" or "<" (angle symbol)
  • one or two "-" if necessary
  • a blank space between components

Example:

-30.0E102 -i40.0E102

That's 20 positions, plus the stack-level annunciator "x:" or "y:".

I favor the large, one-line display from the late HP-32SII. However, it has only 12 characters and a leading negative sign. With its interstitial decimals, such a display (or the 7-segment display from the HP-20S) would require five more positions for displaying an entire complex number with adequate precision in all cases. (And how would "SHOW" work? Hmm...)

Quote:
K:"As for the "stigma" of 'imaginariness', well -- I wouldn't know how to pay someone US$ sqrt(-1)..."

V:You also don't know how to father 355/113 childs or -3.1415 childs, I presume, and that doesn't make rational or negative real numbers "imaginary".

"Imaginary" is a stupid label attached to complex numbers for historical reasons, they aren't any less "real" than real numbers, and when you think about them as an ordered pair, the distinction all but vanishes, as (3,0) seems then as "real" as (0,3), don't you agree ?


Not the ideal analogy, I'd say. We live in the world of "real" numbers on the continuous and easily-comprehensible number line. In certain cases (e.g., count of persons), only discrete integers are meaningful. Negative numbers generally represent the polarity or orientation of a value or difference, but they still reside on that infinite line. The domain of negative numbers is like a mirror-image extension of the domain of positive numbers.

(However, it is known that the concepts of zero and negative numbers did cause considerable difficulty to certain ancient societies and mathematicians!)

In the domain of the complex-number plane, both components are equally important. Of course, a so-called "imaginary" number is merely a "real" number multiplied by the imaginary value sqrt(-1) to place it in a new, second dimension. Complex-number mathmatics offer us a powerful mathematical tool for analyzing quantities with two independent components -- especially those with sinusoidal characteristics.

"Imaginary numbers" should more-properly be termed "imaginary-valued numbers", if one doesn't believe that "imaginary" is pejorative.

Best regards,

-- KS

Edited: 19 Nov 2005, 3:26 p.m.

#28

Quote:
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
important too.

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
expense.

For that matter, I'd appreciate a shirt-pocket-sized RPN model for
myself, even if it didn't include the "scientific" functions or
programmability.

Quote:
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
programmable).

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?

Quote:
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?

Quote:
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
significant improvement.

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.

Quote:
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.

Quote:
(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.

Regards,
James

Edited: 21 Nov 2005, 10:11 p.m.

#29

James! That was a well thought out, but longish post, so I'll respond maybe tomorrow, but I did read it...

... and guess what I saw skimming over eBay tonight up for bid (I didn't and missed the deadline, but more on that in a second)- an old HP 32E! It is a vintage machine, a Spice series basic nonprogrammable scientific; it had had not a few features and was a rugged unit.

I bring it up because of your post: this unit was a 4 level stack RPN calculator with full scientific functions and several memory registers; something I wouldn't mind sitting on the top of my desk anywhere (provided it was safe ;) )! Now, of course it wasn't programmable, but it IS 33S-like in its simplicity, minus the programming capability, BUT NO continuous memory. Now, according to this museum, it listed for $80 USD about forty years ago; (so you might see that I didn't want to top the almost $50 some guy bid on it, for a slightly above basic scientific nonprogrammable, though nostalgia almost made me do it!) which was roughly half the price of a HP 34C, a richly featured, fully programmable scientific with twenty memory registers.

Now the 34Cs were superb to use, but the 32Es were somewhat more affordable and people did happily use the 32E calculators. I'm not saying we're all asking for too much, but consider what we accepted in those days!

Anyhow, goodnight and I'll seriously respond to your thoughtful post as soon as I can, hopefully tomorrow!

#30

Quote:
The HP42S showed the way, IMHO. First, you must stick to the
4-level stack because (as someone stated previously) unlimited
stack allows or even naturally leads to complicated states which
you must remember.

Perhaps so, depending on the user, but RPN's GTO could make quite
a mess of a program too.

Quote:
Then, every stack level / register / variable should be able to
hold any type of data, this includes lists of any depth, matrices,
variable names, strings / texts (the latter having style maybe).

The way RPL accomplishes the stack being "able to hold any type of
data" is that the stack is really a stack of pointers. That you
see other objects displayed there is a bit of indirection; the
system decompiles the pointees for display.

Quote:
Indirect addressing would be extended to multiple levels or depths
: if R00 contains {1 2} and R01 contains { {'A' 33} 47}, RCL IND
00 would return 33.

I don't quite follow that, but in RPL you could certainly store
the name B in variable A, the name C in variable B, and the number
123 in variable C, so executing A returns 123.

In RPL, for stored lists, vectors, matrices, and symbolic
matrices, you can also use "indexed variables" for the elements.
For example, suppose I have the list { "A" B 1 } stored in a
variable X. 'X(1)' EVAL returns "A", 'X(2)' EVAL returns 'B', and
'X(3)' EVAL returns 1. To store something new in the list, I could
use "C" 'X(2)' STO to replace B with "C". Of course, it's hard to
see much advantaage of indexed variables over the GET and PUT
commands, and they're mostly neglected, If I recall correctly,
they won't work in the 49 series in some situations where they
worked in the 28 and 48 series,

Quote:
A big plus of keystroke programming and the fact that you have a
program persistant pointer is that you can stop the program,
modify it, then resume. I wonder why this is not possible in RPL
??? It is such a strong point for RPN.

In RPL a copy of the program is placed in the runstream, and I
can't modify the program (or what's left of it) there. When
debugging or a program is otherwise suspended, assuming that I
still have the original, I can modify that, but that won't change
anything in the suspended program.

Quote:
Also PLEASE keep GTO and LBL, the possibility to route the
processing flow anywhere is just so powerful.

Of course. Unless you want to go with "program structures" as
imolemented in RPL, It would be hard for me to imagine making do
without these.

Regards,
James

#31

James,

In addition to that rather rambling response of mine last night, I just want to add that I sort of retracted what I said there about showing the keystroke in program mode. Of course it would be much better to display the actual command or command sequence rather than a simple set of coordinates for a key sequence.

Also, I think your idea of allowing the user to specify stack depth is a very good idea; there are times though I like the "traditional" XYZT stack configuration because that downward replicating T level keeps me from having to use up an extra storage register for a value I may not want to keep longer than for the latest calculational sequence. And then, when one needs to statistically treat a long list of numbers, a four level stack is, without saying, too restrictive. I would love to be able to have a 33S/32SII/34C-ish machine that allows a variable stack, theoretically up to infinity. That would make fast work of calculating averages, medians, and other types of calculations. I once asked someone on the comp.sys.hp48 newsgroup how I could ever get the median, maximum and minimum of a certain bunch of figures. I got an ingenious reply, but it did require, if I recall correctly, a bit of stack register and memory register swapping and essentially "max-ing out" (forgive the pun) the memory register usage. In short, I think I too would love a user-definable variable stack!



Possibly Related Threads…
Thread Author Replies Views Last Post
  HP Prime finally updated! Les Koller 8 3,549 12-10-2013, 09:25 PM
Last Post: Les Koller
  HP-70 simulator updated Willy R. Kunz 3 1,607 11-26-2013, 08:20 PM
Last Post: BShoring
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 2,382 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  Updated PPC DVD Version 2.10: HP-41 Searchable Program Files and Scannable Barcode Jake Schwartz 3 1,834 09-27-2013, 09:51 PM
Last Post: Olivier (Wa)
  Graph3D v2013.09.26 for HP Prime (updated) Han 3 1,590 09-26-2013, 04:01 PM
Last Post: cyrille de brebisson
  OT: PockEmul has been updated Bill (Smithville, NJ) 0 1,025 08-07-2013, 03:16 PM
Last Post: Bill (Smithville, NJ)
  [HP Prime CAS] Request: TRUE & FALSE CompSystems 8 2,549 08-03-2013, 08:09 PM
Last Post: Raymond Del Tondo
  HP-50 on Raspberry Pi? The HP-67 come true? Matti Övermark 10 3,272 07-30-2013, 09:40 PM
Last Post: Matti Övermark
  RPN-67 Pro updated to v1.2 Willy R. Kunz 29 8,030 06-12-2013, 04:32 PM
Last Post: Willy R. Kunz
  RPN-67 Pro updated Willy R. Kunz 8 2,494 05-16-2013, 05:12 AM
Last Post: Willy R. Kunz

Forum Jump: