▼
Posts: 260
Threads: 21
Joined: Nov 2006
In a previous thread with a, perhaps to some, uninteresting subject, Tim wrote this:
Quote:
It seems to me the most common theme I hear from those here is that RPL programming is too complicated to read anyway. People seem to like being able to operate in RPN mode for calculations and type things like 1 SPC 2 + 3 / and get a result, but I think anyone who is being truly honest will say that reading RPL code is not easy to read and follow when you move beyond just the basics.
Open questions to everyone: Were we able to eventually support RPN on something like this device, how would you like it done? What would be "absolutely critical"? What would be nice but not critical?
TW
It is noted Tim says "... support RPN on something like this device... ". I hope that includes the 39GII as well.
Please chime in anyway.
(Sorry to start a new thread Tim, but the other thread may have been overlooked by folks not interested in list processing and/or the 39GII (due to lack of RPN?)) ;)
Edited: 24 July 2012, 6:27 p.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hmmh, there may be some confusion in the last sentence you quote:
Quote:
People seem to like being able to operate in RPN mode for calculations and type things like 1 SPC 2 + 3 / and get a result, but I think anyone who is being truly honest will say that reading RPL code is not easy to read and follow when you move beyond just the basics.
I concur that RP L, although very powerful for sure, is too complicated to read and understand (at least for me). RP N, OTOH, is easy enough (at least for me again).
▼
Posts: 308
Threads: 26
Joined: Jul 2007
I think RPL as a programming language is prob OK for RPL folks that grew up from the 28C on.
I've purchased two 48s and gotten rid of them because the need of the programming task vs effort expended learning wasn't worth it, esp when I have 41s with math modules etc.
I think the crux of the issue is RPN is great for "online" or 'live' calculations - as it has been since 1972. It's somewhat OK for a programming language as a morphed "keyboard capture macro language".
If I had my druthers, the perfect programmable calculating device has bone-stock HP RPN with big ENTER key, XYZT+L registers, Z copy down etc. But the programming language would be some flavor of the HP71B BASIC along with extensions. The latter is a damned good implementation that I'd've loved to have seen on desktop PCs - instead of dorky MS BASIC in ROM.
There really doesn't need to be a coupling of the 'live calculator' operation with the actual programming language.
Some modifciation to the HP71B firmware architecture could readily manage this - and still also allow an FRMEVL(stringname$) functionality for people that like to do things in "one big lump".
[Some old school Commodore 6502 BASIC folks may remember the FRMEVL call!]
BASIC has relatively few language-only keyword/tokens, and would not take up too much space on a multishifted keyboard. The rest of the (math) functions could run in postfix calc mode or prefix-with-arguments mode in BASIC (certainly the big ones like SQRT, LOG, LN, exp, trig +arc+hyp+inv, etc).
Bill Wiese
San Jose CA
Edited: 24 July 2012, 6:58 p.m.
Posts: 764
Threads: 118
Joined: Aug 2007
Quote:
In a previous thread with a, perhaps to some, uninteresting subject, Tim wrote this:
It is noted Tim says "... support RPN on something like this device... ". I hope that includes the 39GII as well.
Please chime in anyway.
(Sorry to start a new thread Tim, but the other thread may have been overlooked by folks not interested in list processing and/or the 39GII (due to lack of RPN?)) ;)
To me RPL and RPN are basically the same structure. Instead of commands like x>y?, LBL, GTO, R/S, and ISG in RPN, while 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. In my eyes, it is about learning another language.
I would like to see RPN as an operating mode on the 39g series. When it does get applied, let's have some introductory documentation that will introduce RPN to the newbies.
Eddie
Posts: 556
Threads: 9
Joined: Jul 2007
IMO an application mimicking HP48 style RPL/N direct keyboard functionality for simple calculations and not involving programming or be involved in should fix the problem for us die hard RPN veterans as a first step. I'm sure this will attract the majority here and so the future development would get a serious push.
Agreed, for programming purposes RPL should be abandoned - it's completely out of time; the programming language of 39GII looks the way to go. I haven't had a chance to get familiar with it in depth, but one of the weakest point (IMO) of the older models is their limited program Input/Output capabilities (prompts for user input & results display). Some one to shed some light how this is implemented on this new platform?
▼
Posts: 468
Threads: 17
Joined: May 2011
Quote:
the weakest point (IMO) of the older models is their limited program Input/Output capabilities (prompts for user input & results display).
Sorry Reth but you cannot say that.
I think the 50G is the most advanced calculotor in this point of view with a embedded language.. Far more beyond the 39gII at this stage.
I'm afraid that for many people here, RPL ends with the 28 or 48S.
Edited: 25 July 2012, 3:54 a.m.
▼
Posts: 372
Threads: 42
Joined: Mar 2011
Quote:
I'm afraid that for many people here, RPL ends with the 28 or 48S.
Gilles, sorry but I don't understand this last sentence... What's wrong with the RPL of the 48G, 49, and 50g? If anything it's more powerful than that of the 48S...
Edited: 25 July 2012, 4:06 a.m.
▼
Posts: 468
Threads: 17
Joined: May 2011
I just wanted to say that there are powerfull Input/Output capabilities with the 50G wich not exist on the 28/48S (CHOOSE INFORM MSGBOX etc.)
"Choose Box"
{ "RPL" "RPN" "None" }
1
CHOOSE
"Enter the values"
{ "Power" "Volt" "Ampere"}
{ } { } { }
INFORM
IF THEN {'P' 'V' 'A' } STO END
I don't see how it could be simplier ( empty list are for on line help,format, initial values etc.)
Edited: 25 July 2012, 4:31 a.m.
▼
Posts: 372
Threads: 42
Joined: Mar 2011
I agree. I remember when I had to do something with the 50g, there was always a command that did what I needed - and I mainly made programs that needed quite a lot of user interaction...
Posts: 556
Threads: 9
Joined: Jul 2007
Quote:
I just wanted to say that there are powerfull Input/Output capabilities with the 50G wich not exist on the 28/48S (CHOOSE INFORM MSGBOX etc.)
I don't see how it could be simplier ( empty list are for on line help,format, initial values etc.)
First of all I dislike 49-50 models and never used them for real work, my working horse was the 48GX. Input forms are annoyingly slow and to my view next to useless (and I'm aware of your example and everything about input/output). What I was missing got partially fixed by a SysRPL program I found somewhere called "IN" which would issue a prompt at any line of the display (very similar to the command line prompt with some shortcomings). For everything else I used INPUT command, the only usable one IMO.
▼
Posts: 468
Threads: 17
Joined: May 2011
Hi Reth
The 49G is far quicker than the older ones.
An the 50G far more quicker the 49
▼
Posts: 556
Threads: 9
Joined: Jul 2007
Yes, I know that, but I don't like them; What's more I (and other surveyors I would assume) have almost no usage for calculators anyway, still If I needed one, I'd pull out the HP-48G. The keyboard and the overall fill of this machine is second to none, it is a real professional toll and not an ugly toy as the 49(50). If only it had a faster processor...
Cheers
Posts: 125
Threads: 5
Joined: Jun 2008
TI-Nspire CX CAS officially supports both its native TI-BASIC and Lua. HP-50g has already supported several languages. I think it won't be difficult to add one more language like that of HP-39gII. There's no need to totally abandon RPL.
Edited: 25 July 2012, 12:48 a.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
There's no need to totally abandon RPL.
Especially because of the large software base.
Posts: 1,089
Threads: 32
Joined: Dec 2005
To me, reading and writing UserRPL code is no more difficult than e.g. Casio BASIC (I've used a 4500p). Can't comment on the 39GII.
I've seen just one very powerful language I could immediately code in again after not using it for quite some time: Java, including Swing. But this kind of ingenuity is hard to reach.
I don't *need* RPL, and actually prefer RPN. But I don't *want* anything like BASIC.
I have no interest in the 39GII anyway as it is targeted at the educational market and I'm neither a student nor a teacher.
Posts: 468
Threads: 17
Joined: May 2011
Hi all,
What is the subject here ?
I'm interested with concrete exemple of what could be a 39gII RPN with not at all RPL savour. Very curious.... Please give me examples...
If a RPN 39gII is just exactly the same language of the 39gII, I don't see any interest of this. So we would have to write 45 SIN outside a program an SIN(45) inside ? M1 M2 * to multiply two matrix outside a program and M1*M2 inside ? And how to you pass argument to your programs ? And how to you do with the SOLVE function for example ?
As i say in a previous post,there is no problem to have the choice to use both in the same program :
SIN(45) // take nothing from the stack and evauate immediatly
SIN // take the argument on the stack and evaluate
M1 M2 *
'M1 * M2' // two symbols need for immediate and delayed evaluation
The system could be smart enough to manage this.
For me a RPN 39gII must have :
- Infinite stack
- one stack for all type of object
- powerfull list processing
- must manage algebraic object (immediate and delayed evaluation)
- much simpler way to define local function and variables than the 50G (a problem with RPL/50)
If, when you think RPN 39gII, you have in mind :
- GOTO statement
- WP34s or HP42 stack style
-> I think it's a dead end.At least I want to see !
PS :
I also don't think it will be a good idea to manage input parameters in a list like this :
{ A B } +
Edited: 25 July 2012, 4:00 a.m.
Posts: 207
Threads: 48
Joined: Feb 2010
I think that ANY HP-Calculator WITHOUT RPN is like a pizza WITHOUT CHEESE ...
▼
Posts: 1,089
Threads: 32
Joined: Dec 2005
That would be Turkish Notation.
Posts: 239
Threads: 9
Joined: Dec 2010
No language can be simpler than keystroke recording.
RPL is keystroke recording for an RPN machine, plus some optional stuff: control structures and local variables, mainly.
I consider some stuff broken in the latest RPL by HP:
- local variable definition and re-assignment (way unintuitive)
- lack of immediate algebraic expressions
Fix those two things and RPL is as readable a language as BASIC *and* it retains the goodies that come with it being the natural language: implied transport of inputs and outputs (this is huge), concept of retained algebraic expressions, concept of functions as data, 1:1 mapping to RPN operation, etc.
I also observe that there's one thing that commonly makes RPL hard to read: the use of stack operations.
However, after you fixed local variables, you basically don't need them anymore. (Their use is not mandated by the language.)
In summary: for an RPN-operated machine, RPL can be the perfect language. Just modernize it.
Example of "fixed" RPL:
<< =n
sum=0
1 n FOR i
sum=sum+i
IF sum>(n^2/log(10)) THEN BREAK END
NEXT
sum
>>
Anything not "readable"?
Examples of somewhat advanced use of enhanced RPL:
<< 'x^2+5' sqrt sin >> yields 'sin(sqrt(x^2+5))'
<< 1..4 'x' peval >> yields 'x^3+2*x^2+3*x^1+4'
<< 1..10 { sqrt isInt } filter >> yields [ 1 4 9 ]
<< 105..108 {split ! total} {recurse} doUntil >> yields [169 169 363601 169] [12 6 8 33]
It's okay to abandon RPN and RPL. (Though it would strike me as wrong.) But I don't see the point of bringing back one without the other.
It's also okay to have a BASIC-like language. But it's not inspiring. If you break with tradition and backwards compatibility, why don't you pick up a language that is spoken by millions and which becomes a worthwhile investment for anyone deciding to learn it? It's ok to have a library, but yet another unremarkable language?
Edited: 25 July 2012, 10:52 a.m.
▼
Posts: 16
Threads: 3
Joined: Feb 2012
If I need advanced programming I'll use a Mac\PC. My everyday calc's programming is RPN, never RPL!
Back in the university days, I got several of my fellow students to program their RPN-calc's. No one ever learned the benefits on RPL!
▼
Posts: 372
Threads: 42
Joined: Mar 2011
Quote:
If I need advanced programming I'll use a Mac\PC. My everyday calc's programming is RPN, never RPL!
Back in the university days, I got several of my fellow students to program their RPN-calc's. No one ever learned the benefits on RPL!
Funny how I can literally just swap the two words RPL and RPN, and your post applies exactly to me and my situation! :D
Seriously, we'll never get past this point. Older people who worked on RPN first will never love RPL. Younger people who learned RPL first will never love RPN. I've lost hope.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Older people who worked on RPN first will never love RPL.
That's not quite true. My first HP calculator was an HP-15C, which I used and programmed for one or two years before shifting to the HP-28S and later to the HP-48GX. I never had trouble changing from RPN to RPL. I am not an expert in either, however. Nevertheless at least one RPL program I wrote (Inerc12) appears to be useful to this date :-)
http://helpcalculator.forumfree.it/?t=52848614
The first version of the program was written overnight as I would have an examination on the next day. Our old professor De Lucca, a Structural Engineering genius, told us we could use whatever program we wanted when calculation the required moments of inertia as long as we 'registered' it. By 'registering' he meant providing him a hardcopy of the program listing and usage instructions, but I understood I had to write the program myself. Because I tended to make silly manual calculations mistakes, I decided to write it. Version 1.0 was followed by version 1.2, just to make it look more elaborate than it really was. Top RPL programmer might make it shorter and faster. There are lots of room for improvement. Right now I see a NOT NOT sequence which can be obviously removed :-)
One of my classmates and coworker suggested me
this book, which I purchased. It proved to be helpful, even though I had not been an HP-41 user. That's the only book in my bookshelf that has been signed by the author :-)
Posts: 556
Threads: 9
Joined: Jul 2007
Quote:
Older people who worked on RPN first will never love RPL. Younger people who learned RPL first will never love RPN. I've lost hope.
Categorically wrong! I learned RPN (HP41) first, then overnight transferred all my programs (complicated surveying package) to RPL for the HP-28S. So I'm quite comfortable with both. WP-34S brought back some memories and is quite fun to program it BTW (solver excepted for the time being).
Posts: 468
Threads: 17
Joined: May 2011
Hi Oliver ,
Quote:
I consider some stuff broken in the latest RPL by HP:
1- local variable definition and re-assignment (way unintuitive)
2- lack of immediate algebraic expressions
Point 2 :
In fact, there is !
Just try :
`3*LN(5)` ENTER
You will get immediatly (no need of EVAL) : 4.82831373729
Pont 1 :
I agree. I never understand this point.
▼
Posts: 239
Threads: 9
Joined: Dec 2010
Hi Gilles,
'3*LN(5)' does not evaluate automatically, if I enter on my HP-49 in either exact or approx mode.
Even if it would (because it's constant), my point, of course, is that something like
sum>(n^2/log(10))
should be writable in RPL, to make stuff like this readable.
As we know, today you can write 'expr' EVAL but this is too cumbersome. (Many times, of course, you absolutely want to keep an expression unevaluated (for all symbolic manipulation in fact). There's nothing wrong with the tick-syntax. There just should be support for immediate evaluation as well. Removing the ticks seems like the obvious syntax for that.)
Cheers.
▼
Posts: 468
Threads: 17
Joined: May 2011
Just try
`3*LN(5)`
and not
'3*LN(5)'
To get the ` character : Right Shift & ' (push Right Shift and ' and release the two keys )
IF `sum>(n^2/log(10))` THEN ...
is the same as
IF 'sum>(n^2/log(10))' EVAL THEN ...
With only
IF sum>(n^2/log(10)) THEN ...
is there not a problem for the system to understand ?
▼
Posts: 239
Threads: 9
Joined: Dec 2010
Oh. Interesting. I didn't know about `. Thanks. (This is like execution in a Unix shell script.) Then readable immediate algebraic expressions are almost there. (Any kind of decoration will be deemed weird by fresh users, who are used to writing them undecorated in pretty much any other language, I'd think.)
Quote:
With only IF sum>(n^2/log(10)) THEN ... is there not a problem for the system to understand ?
There isn't, if you don't allow spaces in the expression. This is how it works in RPL+.
▼
Posts: 468
Threads: 17
Joined: May 2011
Quote:
Quote: With only IF sum>(n^2/log(10)) THEN ... is there not a problem for the system to understand ?
There isn't, if you don't allow spaces in the expression. This is how it works in RPL+.
Perhaps this could be an interesting idea for a RPN 39gII (or similar)
IF sum>(n^2/log(10)) THEN ...
or
IF sum n SQ 10 LOG / > THEN
It solve also the problems like
SIN(45) vs 45 SIN
I'm quite sure you can mix RPN and algebraic in a smart way. The 50G does a part of this. A RPN 39gII could do more...
The space (or no space) separator could be a key.
So we could do
45 SIN A *
SIN(45) A *
SIN(45)*A
P1 P2 P2 Myfonction
MyFunction(P1,P2,P3)
A:=n^2/log(10) store in 'A'
n^2/log(10) just put the result value on the stack
n SQ 10 LOG / put each value on the stack applies function and calulate
n² LOG(10) / will work also
It seems interesting
An other way is to use ' or ` to diffenciate RPN and algebraic parts
Edited: 25 July 2012, 6:39 p.m.
Posts: 57
Threads: 0
Joined: Sep 2010
Isn't this character the ALG mode separator?
I tried this:
1. Go to ALG mode and write: 5+6 ENTER.
2. Back to RPN and select the expession with the UP arrow.
3. Exit with the ON, and delete the two : characters from left.
4. Enter, and voila!
I'm sorry my poor English.
▼
Posts: 468
Threads: 17
Joined: May 2011
Yes it is, but you can use it in RPL ;) i'm not sure this is in the documentation but it works
1/
'3+5' @ Put 3+5 on the stack
EVAL @ 8
2/
`3+5` @ ` is Right Shift & '
@ 8... no need of EVAL
So you can do such things as
IF `COS(X)/4>L` THEN ...
but you can't affect a variable for example...
EDIT : Hummm !!! In fact it works also with your suggestion!
-switch to algebraic and type :
120 STO> A
- switch to RPL
0 'A' STO
A @ You see 0
Upper key and echo the 120 => A, delete the :: then ENTER
A @ You see 120
I did not know it was possible ... but In RPL do :
`88=>A` @ => is black triangle ASCII 134, you can choose it with CHARS
The value of A is change to 88
;)
«
`0=>t` @ => Black triangle
1 100 FOR n
`t+n=>t`
NEXT
t
»
5050
works but all t+n are on the stack. Not recommanded however because it does strange things... (my loop variable was i and the system ask me to toggle Complex
Edited: 27 July 2012, 7:24 p.m.
▼
Posts: 57
Threads: 0
Joined: Sep 2010
Quote:
«
`0=>t` @ => Black triangle
1 100 FOR n
`t+n=>t`
NEXT
t
»
And it works with the local variables too.
<< 0. ->L
<< L
"RPN" ->TAG
`5.=>L`
"ALG" ->TAG
>>
>>
Quote:
works but all t+n are on the stack.
It seems if the "system" find an expression between two Alg. separators (Chr(96)), evaluate the expression and put the result to the stack on both ALG and RPN modes too.
An ALG expression in RPN is a tagged object (TYPE = 12) and it's TAG part is an empty string. You can make this in RPN: Alg_expression "" ->TAG , or Left shift, decimal point (::), Right Arrow, Alg_expression.
Quote:
my loop variable was i
It seems your first computer no was a ZX Spectrum. ;)
Edited: 28 July 2012, 9:00 a.m.
Posts: 468
Threads: 17
Joined: May 2011
Hi Oliver
Quote:
n summary: for an RPN-operated machine, RPL can be the perfect language. Just modernize it.
:D
Quote:
Example of "fixed" RPL:
<< =n
sum=0
1 n FOR i
sum=sum+i
IF sum>(n^2/log(10)) THEN BREAK END
NEXT
sum
>>
Interresting exemple. It shows what is to improve in RPL/50 (BREAK, CONTINUE, new logic for local variables ...).
With a 50G could be :
« 0 -> n sum
«
1 n FOR i
i 'sum' STO+
IF `sum>(n^2/LOG(10)` THEN n 'i' STO END
NEXT
sum
»
»
But modify the counter inside the loop is not very beautiful...The lack of BREAK/CONTINUE is a problem.
Quote:
<< 'x^2+5' sqrt sin >> yields 'sin(sqrt(x^2+5))'
It works like this in RPL/50
Quote:
<< 1..10 { sqrt isInt } filter >> yields [ 1 4
GoferList library is a perfect tool for this :
« 1 « 1 + » 10 Iterate « \V/ FP 0 == » Filter »
Quote:
<< 1..4 'x' peval >> yields 'x^3+2*x^2+3*x^1+4'
[ 1 2 3 4 ] 'X' PEVAL EXPAND
If it could be an improvment, i like [1..4] to do [ 1 2 3 4 ]
Quote:
<< 105..108 {split ! total} {recurse} doUntil >> yields [169 169 363601 169] [12 6 8 33]
What does that do ?
Edited: 25 July 2012, 4:53 p.m.
▼
Posts: 239
Threads: 9
Joined: Dec 2010
Quote:
Quote:
<< 105..108 {split ! total} {recurse} doUntil >> yields [169 169 363601 169] [12 6 8 33]
What does that do ?
I should have explained.
For each of the numbers [105 106 107 108] independently, it applies the instructions { split ! total } until a recursion is detected. The final values and iteration counts are then reported in two arrays.
split splits a number into its digits, ! is the factorial, total is the sum of a vector.
The first few iterations for the first number would be
1: 105 -> [1 0 5] -> [1 1 120 ] -> 122
2: 122 -> [1 2 2] -> [1 2 2] -> 5
3: 5 -> [5] -> [1 2 0] -> 120
4: 120 -> [1 2 0] -> [1 2 1] -> 4
...
The result vectors tells you that after 12 iterations the value 169 re-occurs and a cycle is detected. Mysteriously, all numbers that go through this transform eventually hit a cycle at 169 or 363601. (Unsurprisingly, this is a PE problem.)
This code showcases a number of concepts, including the lovely ability of RPL to work with code fragments.
You can say serious stuff can be done on a computer. But do I want to do that for a little puzzle like this? It's solved in one line of code. Perfect for a calculator!
I doubt this can be coded in less than 10 lines of code in BASIC. (More if you don't have hashtables.)
In fact, I know no language where this problem could be solved as succinctly *and readable* as this. (Readable, once you're accustomed to this style, that is. RPL can scale from the simplest (keystroke recording) which requires zero (!) learning, to vaguely sophisticated little nuggets like this.)
Edited: 25 July 2012, 5:32 p.m.
▼
Posts: 260
Threads: 21
Joined: Nov 2006
This post and other posts in this thread illustrate the beauty of RPL, and I admit I like RPL alot.
But by saying I don't need RPL programming at this time, since HP has introduced a new programming model (that some people and HP are probably excited about), I am hoping HP will release a new software version for this model that includes RPN entry. I'd rather not wait for a next model.
Basically, would asking for both RPN entry *and* RPL programming now be too much to ask for. How much more work would it be to RPL programming while adding RPN entry?
Edited: 25 July 2012, 7:58 p.m.
Posts: 468
Threads: 17
Joined: May 2011
Well done,
This one is more complex with the 50G... And less readable ;)
With GoferList library :
{105 106 107 108}
« 0 {} -> List
«
DO
'List' STO+
->STR Chars STR-> ! Sum
UNTIL
DUP List OVER POS
END
NIP List SIZE 2. ->LIST
»
»
MAP
{ { 169 12. } { 169 6. } { 363601 8. } { 169 33. } }
|