The new 39GII and RPN?: Please read and comment.



#2

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.


#3

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 RPL, although very powerful for sure, is too complicated to read and understand (at least for me). RPN, OTOH, is easy enough (at least for me again).

#4

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.

#5

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

#6

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?


#7

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.


#8

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.


#9

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.


#10

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

#11

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.

#12

Hi Reth

The 49G is far quicker than the older ones.
An the 50G far more quicker the 49


#13

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

#14

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.


#15

Quote:
There's no need to totally abandon RPL.

Especially because of the large software base.

#16

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.

#17

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.

#18

I think that ANY HP-Calculator WITHOUT RPN is like a pizza WITHOUT CHEESE ...


#19

That would be Turkish Notation.

#20

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.


#21

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!


#22

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.


#23

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 :-)

#24

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

#25

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.


#26

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.


#27

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 ?


#28

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


#29

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.

#30

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.


#31

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.


#32

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.

#33

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.


#34

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.


#35

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.

#36

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


Possibly Related Threads…
Thread Author Replies Views Last Post
  Integration question and "RPN" mode comment Craig Thomas 16 5,925 12-05-2013, 02:32 AM
Last Post: Nick_S
  Gathering USB dumps for Connectivity Kit <-> 39gII communication... debrouxl 2 1,697 12-01-2013, 12:59 PM
Last Post: Marcus von Cube, Germany
  New firmware for HP 39gII Mic 6 2,877 11-26-2013, 06:23 PM
Last Post: DeboT
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 2,506 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  HP PRIME: command to read the SERIAL ? Joseph Ec 9 5,867 11-01-2013, 12:43 AM
Last Post: Joe Horn
  HP Prime vs. 39gII Connectivity Kit Marcus von Cube, Germany 3 1,768 10-09-2013, 05:44 PM
Last Post: Marcus von Cube, Germany
  [HP 39Gii] - Bug report Jean-Michel 1 1,654 08-28-2013, 10:53 AM
Last Post: Tim Wessman
  hp 39gii lcd clear question giancarlo 7 2,745 08-18-2013, 07:30 AM
Last Post: Mic
  integration on 39gII emulator Wes Loewer 29 7,305 06-07-2013, 05:58 PM
Last Post: Chris Smith
  HP 39gII considered annoying, part 1 Pete Wilson 6 2,301 05-22-2013, 05:08 AM
Last Post: Gilles Carpentier

Forum Jump: