The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

HP 39gII and parallel list processing
Message #1 Posted by Gilles Carpentier on 24 July 2012, 8:01 a.m.

We exchange in a previous post about list processing.

In fact,I just realise that the 39gII already does many things in that way. For example,in degree :

SIN( {0, 45, 90} ) -> {0, .707...,1}

{ 1,2,3} * 5 -> { 5,10,15}

{ 1,2,3} + { 10,11,12} -> {11,13,15}

SQRT({4,16,256}) -> { 2,4,16}

{ 1,2,3} MOD 2 -> {1,0,1}

{ "a","b","c"} + "e" -> {"ae","ba","ce"}

{ "a","b","c"} + {"d" "e" "f"} -> {"ad" "be" "cf"}

:D

Edited: 24 July 2012, 8:04 a.m.

      
Re: HP 39gII and parallel list processing
Message #2 Posted by Cristian Arezzini on 24 July 2012, 8:22 a.m.,
in response to message #1 by Gilles Carpentier

I really like more and more what I see about the 39gii. And if this means that there will be an equivalent upgrade of the "high end" line with a successor to the 50g... (and if it still has RPL of course)... then I will be very very happy indeed!!

            
Re: HP 39gII and parallel list processing
Message #3 Posted by Damir on 24 July 2012, 11:23 a.m.,
in response to message #2 by Cristian Arezzini

I like 39 gll language more than RPL. It is a KISS language. :)

Edited: 24 July 2012, 11:47 a.m.

            
Re: HP 39gII and parallel list processing
Message #4 Posted by x34 on 24 July 2012, 11:26 a.m.,
in response to message #2 by Cristian Arezzini

I doubt HP-39GII descendant could have RPL. IMHO, HP-39GII's Modula-2-like language is far superior to RPL as a scholar one, and HP-39GII ideology is too far from RPL.

                  
Re: HP 39gII and parallel list processing
Message #5 Posted by Tim Wessman on 24 July 2012, 12:40 p.m.,
in response to message #4 by x34

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

Edited: 24 July 2012, 12:41 p.m.

                        
Re: HP 39gII and parallel list processing
Message #6 Posted by x34 on 24 July 2012, 12:59 p.m.,
in response to message #5 by Tim Wessman

May be, new supercalc would have "Modula-39" as a standard language, and RPN as an additional?

I think there is absolutely no need to have RPL here, since Modula-39 is much more structured, orthogonal, simpler and more powerfull one.

                        
Re: HP 39gII and parallel list processing
Message #7 Posted by Namir on 24 July 2012, 2:03 p.m.,
in response to message #5 by Tim Wessman

Tim,

Adding an RPN mode to the HP39gII is a very welcome step. I do like programming the machine (proof is the articles I have submitted to HP Solve newsletter). You are absolutely, right about the readability of the HP39gII listings. Of course RPN support would tap into our old reflexes.

Namir

                        
Re: HP 39gII and parallel list processing
Message #8 Posted by Pal G. on 24 July 2012, 2:54 p.m.,
in response to message #5 by Tim Wessman

Tim,

First, thanks for asking. I think this thread is about to get long. At least I hope it does. Lack of RPN has prevented me from already buying this calc. I'm not mad or upset - I just won't buy a car with an automatic transmission. No big deal.

But I'm glad you asked, 'cause now I'm thinking about a new car.

RPN is my preferred method of entry, period. Whenever I use algebraic entry I look like someone holding an HP calc who has never used RPN. Please add infinite stack, stack commands in soft menus, etc.

IMO it is NOT necessary to include RPL programming at all. I agree with your comments regarding RPL readability and comprehensibility, etc. RPL can be fun to program, but can sometimes be frustrating. The new language is preferred.

Thanks.

                        
Re: HP 39gII and parallel list processing
Message #9 Posted by Jim Horn on 24 July 2012, 4:30 p.m.,
in response to message #5 by Tim Wessman

Tim, I am so used to RPN that for interactive use of a calculator (90% of the time), it's my strongly preferred option. Thus my everyday use of a WP-34S (and Free42 assigned to the Calculator key on my Dell keyboard). If I had a coin for every time I've calculated something on a non-RPN machine then went to use the results by entering another value and realizing the first answer was now gone forever...

However, programming is a different situation. While I've enjoyed squeezing every possible byte out of HP-25, HP-67 and HP-41 programs, that's pretty silly with today's fantastic machines with terrific speed and nearly unlimited memory. Now, the greater resources allow far superior algorithms than would fit into such tiny systems.

So now, the most important thing is to get the right answer even if a program has become large and complex. Code that is readable and understandable by us mere humans is a vital part of that.

Of course, there will always be a need for ultimate performance. As such, multiple programming options would be ideal (e.g. the HP-50's RPL *and* SysRPL *and* C *and* assembly). But for an all-around programming solution, I commend the choices you've made with the HP 39gII.

And a sincere THANK YOU for a remarkable machine and the opportunity to give feedback on it!

                        
Re: HP 39gII and parallel list processing
Message #10 Posted by Gilles Carpentier on 24 July 2012, 6:43 p.m.,
in response to message #5 by Tim Wessman

Just my 2 euros :

I prefer to not respond to your RPL point of view. It is not my opinion but we all know that this is a endless debate.

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

In my opinion, just a RPN vision for such a calc is not enough. It seems you want to forget the RPL but there are some concepts of RPL you could not forget.

I'm new to the 39gII and i must say I don't really understand how this calc deals with algebraic objects. Just un example with the ITERATE command :

ITERATE (X²+5,X,2,3) (what it does is not really important).

In my point of view, it would be more logic to do :

ITERATE ('X²+5','X',2,3)

But in an algebraic language, the system knows that the first and second parameters must be algebraic (and not to be evaluated immediatly, that's the important point!) . In a RPN language,the system can't. So you have no choice. in RPN all objects on the stack must have a unambigous type. For example :

'X²+5' 'X' 2 3 ITERATE

(as you see, i think such powerfull RPN calculator must also understand algebraic syntax - I think it's not a problem)

But it's a RPN calc, so we must be able to write the function in RPN (and more than a function, a program !)

BEGIN ² 5 + END 'X' 2 3 ITERATE // In this case, 'X' unuse, but can be use in a more complex program IF 10 > THEN X ² ELSE X SQRT END
(or why not << ² 5 + >> 'X' 2 3 ITERATE ;D

The system must knows exactly what type of objects are on the stack (Real,integer,list,matrrix, algebraic,program to evaluate etc.)

For example a new MAP function (which apply a function or a program to all the items of a matrix or a list) could be something like :

L1 'f(x)=x²+3' MAP // Define a local agebraic function
(or L1 '->x x²+3' MAP )
or
L1 BEGIN ² 3 + END MAP
( or L1 << ² 3 + >> MAP )

Of course you need some stack manipulation command

For this kind of calc,the stack must be of course 'infinite' ... SWAP or X<->Y, ROT or other name ? it's not a problem! Could be interesting to have mnemotechnic commands in remplacement of the FORTH legacy X<->Y (SWAP) X->X (DUP) Z->X etc...I dont knowbut I must say the FORTH legacy is fine for me.

I think that most of the algebraic 39gII could work in RPN. But it seems more logical to have LOCAL 'a' 'b' 'c' or {'a' 'b' 'c'} LOCAL (I prefer this, and just 'a' LOCAL if only one variable)

EXPORT SQUARE // quote or not quote ? EXPORT SQUARE or 'SQUARE' EXPORT Imo depends if the language allows self creation of program.

As a RPL user I prefer a lot 'SQUARE' EXPORT

<< X->X * >> //or DUP,or ENTER

'CUBE' EXPORT
<< X->X SQUARE *>>

RETURN just leave the 'word'. What is on the stack,it is to the programmer to work well ! So on the contrary with the 39gII,a word (function) can return more than only one item (and not only a list of items which is in general a too heavy process ( note that there is a beautiful way to do with the 50G { 1 2 3 } { 'One' 'Two' 'Three'} STO

etc etc...

Edited: 24 July 2012, 7:46 p.m.

                        
Re: HP 39gII and parallel list processing
Message #11 Posted by Cristian Arezzini on 25 July 2012, 12:09 a.m.,
in response to message #5 by Tim Wessman

Tim, I'm no hard-core programmer and I'm more used to RPL programming (I am ashamed to admit I have never ever been able to understand a RPN program that I didn't write myself) but this is not the point. I concur with the others that say that programming language and input model can be separated. For input model, just give me something like the 50g - infinite stack, and SPC or ENTER as separators, and no DUP on ENTER. For programming, I'm used to RPL but I think I could very well get used to the 39Gii's language, and it's more readable too.

So: 50g entry mode, and 39Gii program mode would do it for me.

                        
Re: HP 39gII and parallel list processing
Message #12 Posted by Patrice on 25 July 2012, 7:36 a.m.,
in response to message #5 by Tim Wessman

Hi Tim,

IMO, what is critical is to fix the operators priority to match mathematic usage or usual programming languages usages.
7MOD2+3 => 2 because + have priority over MOD which is the remainder of a division. rather unexpected!

What would be nice is a RPN mode in home and a new programming keyword to allow basic RPN formulas in programs
RPN 7 2 MOD 3 + => MyVar;

and I would take an unlimited stack

Patrice

                        
Re: HP 39gII and parallel list processing
Message #13 Posted by Wes Loewer on 25 July 2012, 8:49 a.m.,
in response to message #5 by Tim Wessman

Quote:
It seems to me the most common theme I hear from those here is that RPL programming is too complicated to read anyway.


The forum here naturally leans towards the RPN side of things, so it's hardly a cross-sectional survey.

When I first moved from the 41CX to a 28-C, I was rather reluctant to use the higher level RPL features (local vars, IF-THEN-ELSE, FOR-NEXT, DO-UNTIL, ...) and felt "guilty" when I did. But eventually I realized that I could write a working program in RPL in less time --- albeit a few bytes larger and a few ms slower.

Now, when I look back at my own old 41C RPN code, I find it very hard to follow compared to RPL code. It's really a matter of what you're used to. Now, I'd pick up my RPL 50g for programming every time over my RPN 41. For me, it's not even close.

That said, I'm not suggesting that RPL is appropriate for a 39gII type calculator, just that it's not inherently more difficult to read than RPN.

-wes


[ Return to Index | Top of Index ]

Go back to the main exhibit hall