Post Reply 
evaluate expression (rpn) - return(30)
02-06-2015, 07:17 AM
Post: #1
evaluate expression (rpn) - return(30)
hello,

I would like to start this thread to have my programming and the understanding of the prime improved. Han inspired me to re-think the whole topic. I came up with the question in http://www.hpmuseum.org/forum/thread-2913-page-2.html but don't want to go too off-topic there.

The thing is I am still unhappy with is how the prime deals with integer base conversion (same problem with the 48 or 49+ btw). I do prefer a 42 like workflow, which is why most of the time I am using my android phone running real calc....
In a way I am surprised that I seem to be the only one who feels uncomfortable with the situation (tried a poll on the wish-list), but given that there is not much resonance I think it might really be an individual thing ;-) I tried user keys. Results are not 100% satisfying.


This is how I use the user keys. "view" prior of a key lauchnes a corresponding softmenu. i.e. "view"+"-" would launch SymbBaseMenu().

SymbBaseMenu()
BEGIN
LOCAL btn:=SoftMenu({"hex","dec","bin","","2Real","#"});

CASE
IF btn=1 THEN RETURN " 32 4 R→B(3)"; END;
IF btn=2 THEN RETURN " 32 3 R→B(3)"; END;
IF btn=3 THEN RETURN " 32 1 R→B(3)"; END;
IF btn=4 THEN ""; END;
IF btn=5 THEN RETURN "B→R()"; END;
IF btn=6 THEN "#"; END;
DEFAULT "";
END;

Han suggested to return the keycode for enter. I did never succeed with that, but chances are high that I am simply too blind to see the problem. A naive approach with

IF btn=1 THEN " 32 4 R->B(3)"; RETURN(30);

fails. Without return(30) the String is composed on the entry, but adding return(30) does NOT evaluate that expression i.e. it is not passed to the parser as i like to explain the problem.



Btw. having a true user sostmenu that would remain active after the command would, of course, be nicer. The desired functionality is clear. I Type a number, say 4711, start the softmenu with view/base and hit F1 to convert 4711 to a hex integer. I do not want to have to hit enter before. Conversion should be doable when the number is still on the entry line!
I am in rpn. What I would need is to have the resulting expression evaluated w/o hitting an additional enter: 4711 32 4 R->B(3) which is now on the command line.

Any ideas?
And are the no integer constants in cas? Adding the # to a number truncates the # and leaves the number on the stack.
Find all posts by this user
Quote this message in a reply
02-06-2015, 03:40 PM
Post: #2
RE: evaluate expression (rpn) - return(30)
(02-06-2015 07:17 AM)Angus Wrote:  hello,

I would like to start this thread to have my programming and the understanding of the prime improved. Han inspired me to re-think the whole topic. I came up with the question in http://www.hpmuseum.org/forum/thread-2913-page-2.html but don't want to go too off-topic there.

The thing is I am still unhappy with is how the prime deals with integer base conversion (same problem with the 48 or 49+ btw). I do prefer a 42 like workflow, which is why most of the time I am using my android phone running real calc....
In a way I am surprised that I seem to be the only one who feels uncomfortable with the situation (tried a poll on the wish-list), but given that there is not much resonance I think it might really be an individual thing ;-) I tried user keys. Results are not 100% satisfying.


This is how I use the user keys. "view" prior of a key lauchnes a corresponding softmenu. i.e. "view"+"-" would launch SymbBaseMenu().

SymbBaseMenu()
BEGIN
LOCAL btn:=SoftMenu({"hex","dec","bin","","2Real","#"});

CASE
IF btn=1 THEN RETURN " 32 4 R→B(3)"; END;
IF btn=2 THEN RETURN " 32 3 R→B(3)"; END;
IF btn=3 THEN RETURN " 32 1 R→B(3)"; END;
IF btn=4 THEN ""; END;
IF btn=5 THEN RETURN "B→R()"; END;
IF btn=6 THEN "#"; END;
DEFAULT "";
END;

Han suggested to return the keycode for enter. I did never succeed with that, but chances are high that I am simply too blind to see the problem. A naive approach with

IF btn=1 THEN " 32 4 R->B(3)"; RETURN(30);

fails. Without return(30) the String is composed on the entry, but adding return(30) does NOT evaluate that expression i.e. it is not passed to the parser as i like to explain the problem.



Btw. having a true user sostmenu that would remain active after the command would, of course, be nicer. The desired functionality is clear. I Type a number, say 4711, start the softmenu with view/base and hit F1 to convert 4711 to a hex integer. I do not want to have to hit enter before. Conversion should be doable when the number is still on the entry line!
I am in rpn. What I would need is to have the resulting expression evaluated w/o hitting an additional enter: 4711 32 4 R->B(3) which is now on the command line.

Any ideas?
And are the no integer constants in cas? Adding the # to a number truncates the # and leaves the number on the stack.

This is an old problem in Prime, going back about a year (you can search for old threads). I agree, being able to 'push' an Enter key would solve many problems related to making it act like a normal RPN machine.

When I played with this (several versions of ROM ago), I found that it will process the Enter command about 1 time in 20, but could never find a pattern or consistent behavior. I don't know if it's supposed to do this, and the bug is that it doesn't work, or if it's not supposed to and the bug is that does under some circumstances. There was never any clear reply about this support.

I agree with you - if other readers agree this should be supported, please reply here and hopefully with enough voices we can raise the priority to make this work in a future firmware update.

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
02-12-2015, 05:40 AM
Post: #3
RE: evaluate expression (rpn) - return(30)
I would like to push this topic. It seems that it is unsolved for quite some time. Maybe someone understands it or a hp-insider will read this thread and can help.
I remember Han suggesting the method so it seems to me many got under the impression that this should be doable. The more confused I got when rprosperi named that an old problem. I wonder if hp is even aware of the thing not working or if they are ignoring that.

Is there any sollution or explanation mentioned in the old threads (I did not find too much) or are there new insights?
Find all posts by this user
Quote this message in a reply
Post Reply 




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