Posts: 468
Threads: 17
Joined: May 2011
The 24 of July, Tim Wessman was kind enough to ask us, HP calcs users, what could be RPN on something like a HP39gII , how would we like it done? What would be "absolutely critical"? What would be nice but not critical?
Here is (in my bad english) an attempt to summarize our discussion. Sorry for mistakes, errors or forgetting things...
« RPN HP39gII » : An attempt to summarize our discusion
--------------------------------------------------------
1/ We want RPN !
Not surprisingly, all contributors think that RPN on a device like the HP39gII would be wonderfull. However for Patrice, it is first critical to fix operator prority on the present HP39gII ( modulo command).
2/ About the stack
Most persons who spoke on the subject prefer an infinite stack. Christian would prefer something like a 50G stack (infinite stack, and SPC or ENTER as separators, and no DUP on ENTER ). However Bill Wiese think the perfect programmable calculating device has bone-stock HP RPN with big ENTER key, XYZT+L registers, Z copy down etc.
No general idea emerges about what could be the stack manipulation commands (Nota : but it is an important topic, an infinite stack could not be manage as a finite stack – we must disuss this.
Gilles wrote that the "forth legacy" is fine for him, but perhaps more mnemotechnics commands could be interesting
(Nota : nobody wrote about the necessity of an interactive stack manipulation. But of course it is needed (cf HP50G Upper arrow)
3/ RPN vs RPL
As usual, 'classic RPN' vs 'RPL RPN' was in debate. Some find RPL too complex (Pal G ...), others find it simple to use and very powerfull (Oliver ...) Others (Wes Loewer...) find 'classic RPN' very hard to follow compared with RPL more easy to read. But Even those who like RPL wrote that there are some problems :
The lack of BREAK / CONTINUE
The use of LOCAL variables too heavy and unintiutive
For Eddy RPL and RPN are basically the same structure. Instead of commands like x>y?, LBL, GTO, R/S, and ISG in RPN, we have commands FOR-NEXT, WHILE-END, PROMPT, WAIT, and PAUSE in RPL. Both use objects in the stack and manipulate them to obtain desired results. Both are more challenging to read than say, a program written in BASIC.
4/ Programming vs interactive usage
RPN yes ! At least for interactive usage. But what about programming ?
Some people (Jim Horn, Christian …) wrote interactive use and programming aspect are quite different situations. So we could have RPN for interactive usage, and 'classic' 39gII language (no RPN entry) for programming. Gilles thinks it's not a good idea at all to have such a difference between the 2 modes (the power of a 50G/RPL is here !).
5/ About programming
X34 and other people think there is no need to have RPL, since what X34 called « Modula-39 » ;) is much more structured, orthogonal, simpler and more powerfull one. Gilles and Oliver wrote that you can do many things in RPL in a more easy way than in the 39gII embedded language.
All noted that the 39gII language is very readable and clear...Some wrote it must be improved (for example the lack of MAP command, retrieve the TYPE of a variable, List processing …)
Several people wrote that it's not a problem to have several languages on such a calc (like on the 50g)
Four ideas emerged about programming :
a/ RPN OK, but for interactive use only and keep the 39gII langage as it is. No need of RPN/RPL language
b/ RPL legacy. RPL is a powerfull and perfect language for a calc. Keep it ! Improve it !
c/ Classic RPN legacy. RPN 'classic' is a perfect tool for a Calc. We want it !
d/ HP39gII language is interesting and could be adapted to a Reverse polish notation with small efforts
Hummm... Do with this Tim ;)
6/ An alternative way : RPN and algebraic, Both for the same price !
Bill Wiese wrote that functions could run in postfix calc mode or prefix-with-arguments mode in BASIC.
Oliver (who create RPL+) show us we can mix in a smart way RPN/RPL and algebraics. Gilles also think so. The idea is to have a calc wich works _in the same time_ both in RPN and algebraic
IF sum>(n^2/log(10)) THEN … (no space => algebraic object)
or
IF sum n SQ 10 LOG / > THEN
The space (or no space) separator could be a key to differentiate RPN and Agebraic expression
So we could do :
45 SIN A *
SIN(45) A *
SIN(45)*A
'SIN(X)' 'LOG(3*X)' * give 'SIN(X)*LOG(3*X)'
P1 P2 P3 Myfunction
MyFunction(P1,P2,P3)
A:=n^2/log(10) store in 'A'
n^2*log(10) just put the result value on the stack
=> A (or => 'A', or 'A' STO if we want RPL legacy) store in 'A'
n SQ 10 LOG * put each value on the stack applie functions and calulate
n² LOG(10) * will work also
Another way would be to use ' or ` to diffenciate RPN and algebraic part. (immediate and delayed evaluation).
Edited: 26 July 2012, 6:21 a.m. after one or more responses were posted
Posts: 83
Threads: 14
Joined: Sep 2011
Hello,
FYI:
This goal could be accomplished quite easy.
Simply go back to the 48GX O.S. and port it to another processor architecture.
This O.S. has been proven to be very stable and reliable.
Most of the O.S. are written in SYS-RPL (>75% if memory serves me well).
For advanced stuff that a new processor would offer simply add some “hooks” so
that you can control it from the outside.
The 48GX O.S. relies on three 5 nibble registers, two data pointers and a program
counter. Additionally a HW return stack is used, that is also 5 nibbles wide and from
two internal registers also 5 nibble are used.
The data that is hold there is also used in the reserved system RAM for operating the
machine.
So at a total minimum these code areas would need adjustment for a larger base,
resulting in a new compiler.
It would not be too hard to do this, I believe with some skilled people this could be
done in less than a year and there you have a modernized, proven O.S. that could
also work/communicate with the “outer” world.
Then add the more advanced stuff from the MetaKernel you want and add the CAS
(the CAS is written entirely in SYS-RPL, btw). OTH, if you do want the “old” CAS use
another one as for a “modern” processor usually a C compiler exists.
The beauty and advantages of such a scenario would be
- reuse of proven code
- backward compatibility at source level for existing code
(same way as it was done with 48 to 49 code)
- protecting customer investment into the machine (time and money)
- reuse of existing documentation
- USP compared to other calculator manufacturers
- much more
Alternatively simply update the 50g with some more memory and a larger screen to
bridge over the time until such a machine is ready.
Updating the 50g would *not* be so hard (and would not take that long, as is said
already in the past), although this is denied/contested again and again, but that does
not make it truer.
And I know what I am talking about, as I have written much more software for the 50g
(and by that I mean real low level stuff) than what HP has released for it...
Regards,
Andreas
http://www.software49g.gmxhome.de
Edited: 26 July 2012, 6:16 a.m.
Posts: 468
Threads: 17
Joined: May 2011
Hi Andreas,
Quote:
Alternatively simply update the 50g with some more memory and a larger screen to bridge over the time until such a machine is ready.
Give me this, easier local variables definition in RPL and some BREAK and CONTINUE command and I will be an happy man ;D
RPL is also a perfect system for CAS use ... And the 50G CAS is very interesting even if there is no more evolution since years.
On the details of your message, I can say nothing because if I use a lot RPL I know quite nothing (nor I want to know) about "how it works", neither about SYS-RPL. But as far as I know, your message seems makes sense.
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
c/ Classic RPN legacy. RPN 'classic' is a perfect tool for a Calc. We want it !
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NOThat's just keystroke programming, nothing more than a BASIC macro language. Good for programmable basic scientific clacs (10C series, 32 series etc.), but NOT for an advanced graphing calculator. Statement c/ shows again how this forum is just dominated by old-timers that are stuck in their ways. I am a lover of RPL. When I started with RPL I felt it was the next step to a higher level programming on claculators - time to leave the old keystoke & BASIC models behind. But even I know that after 25 years it is time to move on. Just as I have reluctantly left my Scout unit to let a younger leader take the reigns, it is time for something new & "younger" to take shape in the calculator world. Mr Tim Wessman, please go speak to young professionals and also students currently in university or college. Find out what they want to see in a calculator - they are your future customers. Footnote:Does this mean the end of RPN or an RPN like calculating structure? With the modern "textbook" type entry systems it's all a bit of a moot point anyway. Why struggle with intermediate results on a stack (RPN) or counting parentheses (ALG), when you can see the whole formula and easily review it for correctness?
Posts: 468
Threads: 17
Joined: May 2011
Quote:
Footnote:
Does this mean the end of RPN or an RPN like calculating structure? With the modern "textbook" type entry systems it's all a bit of a moot point anyway. Why struggle with intermediate results on a stack (RPN) or counting parentheses (ALG), when you can see the whole formula and easily review it for correctness?
Hi
When I work with RPL, I use a lot algebraic formula. I use the marvelous equation writer to create or edit them. Then they are on the stack or in variable. But I need an easy way to work with them. And RPN (I mean reverse polish notation) is the simplier way I know
Suppose you have on the stack something like
'3*Y+SIN(X)/e^X'
and another part (calculating elsewhere) with
'1/Y'
You want the 2 parts to be equal. Just push the = key and you get :
3*Y+SIN(X)/e^X=1/Y'
Now you want to solve for 'Y' function of X
'Y' SOLVE
give (in more beautiful presentionthan here) :
{
'Y=-((SIN(X)+sqrt(12*EXP(X)^2+SIN(X)^2))/(6*EXP(X)))' 'Y=(-SIN(X)+sqrt(12*EXP(X)^2+SIN(X)^2))/(6*EXP(X))'
}
You want only the second
2 GET (or EVAL NIP, or EVAL SWAP DROP with 3 key pressed)
'Y=(-SIN(X)+sqrt(12*EXP(X)^2+SIN(X)^2))/(6*EXP(X))'
etc.
There is a future for RPN : It is to eat algebraic and manipulate it.
Edited: 26 July 2012, 8:48 a.m.
Posts: 260
Threads: 21
Joined: Nov 2006
Bart, I agree with one of your footnote points, but disagree with the other.
1) Equation writer is very slick when typing a large equation. I agree too many parenthesis can lead to typos and errors, and can obfuscate an otherwise easy to read equation. Unfortunately, I don't think the 39GII has an equation writer.
2) Dealing with intermediate results on a stack is not a struggle, it is desired. I want intermediate results. It is the primary reason I learned RPN. ALG mode insists you enter the entire equation, then reveals the answer or complains with an error message if your parentheses are wrong.
Edited: 26 July 2012, 5:17 p.m.
Posts: 2,309
Threads: 116
Joined: Jun 2005
Quote:
easier local variables definition in RPL
How is local variable definition hard? How would you make it easier?
Quote:
and some BREAK and CONTINUE command
At first I thought you were asking for what RPL provides as HALT, but maybe you mean the equivalent of break and continue in C?
Posts: 468
Threads: 17
Joined: May 2011
- How is local variable definition hard? How would you make it easier?
Suppose you need a 3 local variables in RPL, but you don't kwow in the beginning of a 'bloc' what are their values
You can do something like :
<< 0 0 0 -> a b c @ initialise with a garbage value
<<
My prog
>>
>>
or
<<
First part
Here i know the first value of a
-> a
<<
Second part
Here I can itialize b
-> b
<<
etc.
>>
>>
>>
and if you 10 local variables,
0 0 0 0 0 0 0 0 0 -> a b c e f g h i j
is not very beautiful
Is it not more logic and easier with ythis alternative :
<<
{ 'a' 'b' 'c' } LOCAL
My prog
>>
BREAK is to exit a loop structure (FOR / REPEAT / DO ...)
1 100 FOR n
...
IF test THEN BREAK END
NEXT
CONTINUE to jump to the start of the next iteration
You can do without, but in some case it is very usefull
Edited: 26 July 2012, 1:43 p.m.
Posts: 2,309
Threads: 116
Joined: Jun 2005
Without making really big changes to the implementation of RPL, I think you'll still need a set of guillemets around the scope of the local variables, since it needs to be a block:
<<
{ 'a' 'b' 'c' } LOCAL
<<
My prog
>>
>>
I have only rarely found the need to have local variables without a needed initial value, and when I have needed them, I've rarely needed more than two, so I don't think I'd personally find this feature to be of much use. And I think I can type
0 0 0 -> a b c
faster than I can type
{ 'a' 'b' 'c' } LOCAL
anyhow.
On the other hand, I agree that CONTINUE and BREAK would be very useful.
Posts: 468
Threads: 17
Joined: May 2011
In fact here is already a LOCAL command in the 50G : see AUR page 3-137
LOCAL
Type: Command
Description: Creates one or more local variables. This command is intended mainly for use in Algebraic mode;
it can not be single stepped when a program containing it is being debugged in Algebraic mode.
Access: Catalog, …μ
Input: Level 1/Argument 1: A list of one or more local variable names (names beginning with the local
variable identifier ←), each one followed by an equals sign and the value to be stored in it. Any
variable not followed by an equal sign and a value is set equal to zero.
Output: Level 1/Item 1: The input list.
Flags: Exact mode must be set (flag –105 clear).
Example: Create local variables ←A and ←B and store the values 0 in the first and 2 in the second.
Command: LOCAL({<-A,<-B=2})
Result: {<-A,<-B=2}
I tried to use it in RPL (seems not forbidden), but without success.
PS : But I realise i don't tried with the <-
Edited: 26 July 2012, 5:59 p.m.
Posts: 239
Threads: 9
Joined: Dec 2010
Quote:
How is local variable definition hard? How would you make it easier?
To define, assign, and re-assign a local in RPL, you have to do: << -> n <<
...
6 'n' STO
>>
>>
One possible solution is what RPL+ does: << =n
...
6 =n
>>
Note: - using "=" to do assignment assignment and re-assignment; like most any language
- no block ("defining procedure") is being created
- same syntax for assignment and re-assignment
- the "=" is fused to the variable name to disambiguate from the normal use of the "=" operator
Keeping in mind immediate algebraics which work by having no spaces in an expression, finally, another way emerges: << =n
...
n=6
>>
And now, this looks like in most languages and everyone will get it. The "=n" may look strange but a quick explanation that this assigns whatever's on the stack will be understandable to people. And, it's a very strong feature, as "=n" is much more concise than having to declare an input.
There should be no need to declare a local. Just assign whenever you need it. If you use a never assigned local name it becomes a "name" in RPL, as always.
<< =x
IF x<10 THEN y=7 END
y
>>
returns 7 for inputs smaller than 10 and 'y', otherwise.
Another thing that locals should do, is have "block scope", where code fragments (declared with << >> or { }) are our blocks. That is, they should be usable from within such code fragments. This is another expectation from most languages and also permits things like recursive anonymous functions.
The proposed changes are pretty easy and I can report from using local vars like this in RPL+, that I've never looked back. (Though RPL+, being strictly a superset of RPL, allows you to work the old way, too, and even mix and match old and new.)
EDIT:
Once you have the syntax above, the next step is to replace STO+, STO/, etc. with
x+=5
x/=5
RPL+ does allow
5 =+x
5 =/x
Also, it permits array access, read and write, like so
x[3]
7 =x[3]
Combine that with immediate algebraics, and you have
x[5+y*2]=log(f)*5
Even though this looks like "every other" language now, it's still RPL! Everything you know about RPL still works. It's just an option to also write things, and not alienate new users. (Not that I'm suggesting "RPN" users would embrace this style, of course...)
Edited: 27 July 2012, 4:27 a.m.
Posts: 468
Threads: 17
Joined: May 2011
I like very very much the general idea...
In fact, RPL+ seemed mysterious to me before because I did not understand the importance of space character
To mix in such an easy way RPN (i mean reverse polish notation) and algebraic is very powerfull. You can have the best of the 2 worlds in the same time !
Just be carefull about distinguish the "=" for affectation and the mathematical equal "=" .
I dont like very much "=" for affectation, because A=A+1 is a non sense. I prefer the := of the 39gII for example, or => and <= . But its a detail.
Edited: 27 July 2012, 6:13 a.m.
Posts: 306
Threads: 3
Joined: Sep 2009
I like RPL, but I think it can stand to be improved. There probably needs to be a source and executable file,so you can have formatting, comments, etc. If it had that, I don't think RPL would necessarily be that hard to read. Some other suggestions in this thread for an evolved RPL could be good.
Posts: 83
Threads: 14
Joined: Sep 2011
> There probably needs to be a source and executable file,
> so you can have formatting, comments, etc.
That does already exist, even for USER-RPL.
@Eric
@Gilles
You can "break" out of everything using the error trapping mechanism
of USER-RPL.
Regards,
Andreas
http://www.software49g.gmxhome.de
Posts: 57
Threads: 0
Joined: Sep 2010
Quote:
Suppose you need a 3 local variables in RPL, but you don't kwow in the beginning of a 'bloc' what are their values
You can do something like :
<< 0 0 0 -> a b c @ initialise with a garbage value
<<
My prog
>>
>>
or
<<
First part
Here i know the first value of a
-> a
<<
Second part
Here I can itialize b
-> b
<<
etc.
>>
>>
>>
IMHO it's more readable and sensible (corrigible) if you declare the all variables at the beginning of the program file like the Pascal. With 0 for example. And later if you know the value of the variable, simple go back to the top and rewrite it. In this case you know: Your all variables are declared in a common block, and you need not search them in the whole program file.
Edit:
Declare and inicialise at the beginnig, add a value anywhere, naturally.
Edited: 27 July 2012, 3:45 p.m.
Posts: 239
Threads: 9
Joined: Dec 2010
Hi Crawl,
You don't need two separate files in order to have RPL preserve user formatting.
I think it's purely a historic accident (based on the then-valid rationale that every byte is precious) that explains that RPL on HP 28-50g was compiled into pointers when entered.
Representative of how it could be done elsewhere, ND1 does no such thing and simply compiles when the need for execution arises. If a RPL code fragment is used in a processing command like DOSUBS, filter, or such, it's compiled before use and then reused in compiled form in the internal loop. But the only thing the user ever sees is the user formatting-preserving text form.
If HP produces another RPL-capable machine, I'm sure they'll fix that in the same way. And, yes, agreed, automatic formatting didn't exactly help readability of RPL.
Edited: 27 July 2012, 5:21 p.m.
Posts: 468
Threads: 17
Joined: May 2011
For "big" programs, i think the best is to write them on a PC, tests and then tranfer. So you can put comments in the PC file with @ and the formatting is preserved.
For UserPRL HPUserEdit is a prefect tools and works fine with EMU48 (just click TRANSFER)
Posts: 850
Threads: 10
Joined: Mar 2009
See the following:
Corrections in calculations on a modern "textbook" display calclator
Put yourself in a young person's shoes looking for a calculator to take them through school, college or university - what is more attractive? A stack with intermediate answers but where each calculation has to be repeated, or where the answers are flowed down? You can easily do an impromptu what-if scenario without cursing for not having first set up a set of equations. There are actually intermediate results visible too that also get updated with a change in input on earlier equations.
You and I like RPN, but it's going to look a bit old fashioned to a younger generation. I would like to see an updated 50g-like calculator along the lines of the 39gII, but I would think RPN should be an option and take a back seat. As for programming language, the style that has been termed "RPN style" is not right for this kind of calculator - and RPL? well I like RPL and I like Pascal too, but both seem to have little support these days.
Posts: 306
Threads: 3
Joined: Sep 2009
That may be well and good, but there's no reason a future iteration of RPL shouldn't have that built-in.
Yes, I know about using error trapping to break loops, but, come on, I think we have to admit that is an unintuitive solution to the problem.
|