Post Reply 
[proposal] for RPN modifications
06-18-2014, 05:43 AM (This post was last modified: 06-18-2014 05:44 AM by Angus.)
Post: #1
[proposal] for RPN modifications
I've had a lot of numerical calculations to do the last two days and would now like to sum up what might be changes resulting in a better rpn mode. Maybe others like to join the discussion to help improving that part. Maybe HP is happy about customer inspiration maybe they are blind about such things or consider these things as minor. I think especially the (pretended) minor details can make the difference from a half hearted product.



-I found myself trying to swap x<->y or cmdline<->x numerous times with K_Right. I don't know if others share this kind of ergonomics but during home/rpn that is what I expected that key to do.

-You could, of course, try to do a user K_Right. Ignored if not in home/rpn which does swapping. However that would require a method for passing user key returned strings to the parser and having commands for stack manipulation at all! In addition K_Right seems to ignore any user key assignment.

-Thinking about user keys: Initiating a parsing of the key answer is essential for an rpn feel. That is argument, key, calculation done.

-If hp also sees the benefits of user configurable softkeys: you could, of course, implement swap there. That what not solve the above things, however.
If softkeys might come (please not only build in functions), having different sets for cas, home/rpn and home/non_rpn would save us many lines of codes and checking for the calculator mode.
Allowing modifiers like SHIFT with a softkey would give us a beautiful(!) tool to implement something like a 1-keypress register (2 for sto i.e. shift+registersoftkey). However I would expect that such a register does NOT require to have return pressed to confirm. ;-)


There are, of course, other things I would like to mention, but I think that is enough.

Thank you for reading, maybe HP did, too.
Find all posts by this user
Quote this message in a reply
06-18-2014, 08:23 AM (This post was last modified: 06-18-2014 08:24 AM by Mark Hardman.)
Post: #2
RE: [proposal] for RPN modifications
(06-18-2014 05:43 AM)Angus Wrote:  -I found myself trying to swap x<->y or cmdline<->x numerous times with K_Right. I don't know if others share this kind of ergonomics but during home/rpn that is what I expected that key to do.

It wasn't clear from your post if you were aware of this. But, swap is assigned to the unshifted Comma key in RPN mode. It swaps level 1 and 2 of the stack provided nothing is pending in the command line.

Ceci n'est pas une signature.
Find all posts by this user
Quote this message in a reply
06-18-2014, 08:34 AM
Post: #3
RE: [proposal] for RPN modifications
NO, I was not aware of that yesterday, thank you! Althogh now that you mentioned it I remember I did know it after reading the manual last year - shame on me. Well x<->y would have striked my eye more than the arrows on the key :-)
What would be better thogh, if I could swap from the command line. I guess hp have serious problems with the implementation which makes it impossible to change that afterwords.
Find all posts by this user
Quote this message in a reply
06-18-2014, 08:50 AM
Post: #4
RE: [proposal] for RPN modifications
(06-18-2014 08:23 AM)Mark Hardman Wrote:  It wasn't clear from your post if you were aware of this. But, swap is assigned to the unshifted Comma key in RPN mode. It swaps level 1 and 2 of the stack provided nothing is pending in the command line.

I knew this from previous discussions on this forum and I am sure it is documented in the User Guide or online help. But in looking at life size pictures of the Prime, I doubt I could read the legend for this operation on the key itself, at least not with my eyes.
Visit this user's website Find all posts by this user
Quote this message in a reply
06-18-2014, 09:41 AM
Post: #5
RE: [proposal] for RPN modifications
(06-18-2014 08:34 AM)Angus Wrote:  Well x<->y would have striked my eye more than the arrows on the key :-)

(06-18-2014 08:50 AM)Steve Simpkin Wrote:  But in looking at life size pictures of the Prime, I doubt I could read the legend for this operation on the key itself, at least not with my eyes.

In fairness, there is no label at all on the right arrow key of the 49g/50g to indicate it also functions as the swap key.

Ceci n'est pas une signature.
Find all posts by this user
Quote this message in a reply
06-18-2014, 10:41 AM (This post was last modified: 06-18-2014 10:44 AM by Angus.)
Post: #6
RE: [proposal] for RPN modifications
I don't complain. Should have known that. (usability is limited though because of the entry line....)
I think it is because key_up is so involved with the stack that key_right for swap was my idea.

What do you think about the other ideas posted? Independant of what hp would like or could change at this module. Maybe you can reach Tim, but any hp statement is unlikely.
Find all posts by this user
Quote this message in a reply
06-18-2014, 02:07 PM (This post was last modified: 06-18-2014 02:09 PM by Tim Wessman.)
Post: #7
RE: [proposal] for RPN modifications
How would making swap work in the edit line be useful? No other previous RPL machines did this unless I am missing something.

48 series: SWAP with an editline just does ENTER then SWAP. No swapping in editline essentially.
49/50 series: A non-labeled SWAP key doesn't work in the editline.
Prime: A labeled SWAP key doesn't work in the editline.

What am I missing here? People keep saying to make it like it was before and that is *exactly* how swap works right now. If the issue is printed legends...that is a totally different thing.

x and y have absolutely zero meaning in non-4 level machines so x<=>y is totally unclear as well.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
06-18-2014, 02:54 PM
Post: #8
RE: [proposal] for RPN modifications
is there any chance to make all Math functions working in RPN? The way it works now, is really annoying. For example the Math "Probability" functions like normal and inverse normal distribution etc. or the "Special" functions, like Gamma function (and others) do not work in RPN, or did I miss something?? I always need these functions and I would really like to use the Prime as RPN machine but RPN is too limited at the moment, when comparing with the 50g.
Find all posts by this user
Quote this message in a reply
06-18-2014, 03:41 PM (This post was last modified: 06-18-2014 03:47 PM by Didier Lachieze.)
Post: #9
RE: [proposal] for RPN modifications
(06-18-2014 02:54 PM)Maro Wrote:  is there any chance to make all Math functions working in RPN? The way it works now, is really annoying. For example the Math "Probability" functions like normal and inverse normal distribution etc. or the "Special" functions, like Gamma function (and others) do not work in RPN, or did I miss something??
Did you try to specify the number of arguments?
For example, in RPN mode: 6 Gamma(1) returns 120

Not ideal, but it works. While 6 Gamma() returns -1!
Find all posts by this user
Quote this message in a reply
06-18-2014, 04:43 PM
Post: #10
RE: [proposal] for RPN modifications
(06-18-2014 03:41 PM)Didier Lachieze Wrote:  Did you try to specify the number of arguments?
For example, in RPN mode: 6 Gamma(1) returns 120

Not ideal, but it works. While 6 Gamma() returns -1!

Thanks a lot, Didier! Yes, with argument it works, but this is somewhat strange for RPN. I would rather like to see: 1) enter function argument (e.g.: 1.5) 2) press function (e.g.: Gamma) 3) the result immediately appears (0.8862)

Things like "x Gamma() returns -1" whatever the value of x is, is more than strange. Or if you have a number on stack level 1 (e.g.: 1) then "1.5 Gamma(2)" gives 0.2231. What should be the meaning of a second argument in the Gamma function? The Gamma function has only one argument. So I see some very strange points especially in RPN mode.
Find all posts by this user
Quote this message in a reply
06-18-2014, 04:49 PM
Post: #11
RE: [proposal] for RPN modifications
This specific case is because Gamma is a CAS function which can take any number of arguments, including 0! All are vaid in this case.

TW

Although I work for HP, the views and opinions I post here are my own.
Find all posts by this user
Quote this message in a reply
06-18-2014, 04:53 PM (This post was last modified: 06-18-2014 04:56 PM by Angus.)
Post: #12
RE: [proposal] for RPN modifications
Tim, I would say we would like to have the cmd line behave as x-reg. Maybe that is unclear. If you enter some value You can directly swap it with the last stack item.
I don't understand why the stack depth is of importance. The last input is defined x, the second last y. No matter how many levels reside above that. So x IS the cmd line if you want. All most people want from rpn is to save keystrokes. So any unwanted enter would be gladly avoided.
I hope my explanation is well.
Find all posts by this user
Quote this message in a reply
06-18-2014, 05:53 PM
Post: #13
RE: [proposal] for RPN modifications
(06-18-2014 04:49 PM)Tim Wessman Wrote:  This specific case is because Gamma is a CAS function which can take any number of arguments, including 0! All are vaid in this case.

OK, with two (or three) arguments of the Gamma function you have implemented the "incomplete Gamma function" too, that's a nice feature. But what's about more than three arguments e.g. Gamma(a,b,c,d,e,f,g), or a Gamma function without any argument, if "any number of arguments is valid"? Any mathematical explanation for that?
Find all posts by this user
Quote this message in a reply
06-20-2014, 01:35 AM
Post: #14
RE: [proposal] for RPN modifications
(06-18-2014 04:53 PM)Angus Wrote:  Tim, I would say we would like to have the cmd line behave as x-reg. Maybe that is unclear. If you enter some value You can directly swap it with the last stack item.
I don't understand why the stack depth is of importance. The last input is defined x, the second last y. No matter how many levels reside above that. So x IS the cmd line if you want. All most people want from rpn is to save keystrokes. So any unwanted enter would be gladly avoided.
I hope my explanation is well.

I don't get this either. It isn't complicated unless you've never used a calculator like the HP48 or older?

The x and y register concept is soooooo simple and makes a couple of important keyboard functions pretty much self-explanatory as long as the buttons are tied to the concept, when using RPN. Tim W. repeatedly has made it clear that this doesn't figure into his thinking.

The HP-48 series is an excellent example of a greater than 4-level stack oriented machine that perfectly implements this concept.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 4 Guest(s)