Improved change of integer base
02-24-2014, 12:12 PM
Post: #1
 Angus Member Posts: 212 Joined: Feb 2014
Improved change of integer base
hi everyone.

In an other thread it was stated that smartphones are to be thought of being the replacement for scientific calculators. (which leads to hp fucussiong on education and neglect the former core customers) I do disagree to that with a passion, but there is ideed one thing I started to do on my phone.

I frequently need to change tha database. A procedure I always did not like on my hp calculators. I do that with the RealCalc app on my Android phone.

Do you guys think it would be possible to extend the base functionality so that the last argument can be implicitly thought of being a #constant and be converted to a new base? If it cannot be thought of as an integer constant I would be fine with an error.

I hope my suggestion got clear.
02-24-2014, 02:38 PM (This post was last modified: 02-24-2014 02:40 PM by Tugdual.)
Post: #2
 Tugdual Senior Member Posts: 749 Joined: Dec 2013
RE: Improved change of integer base
I support your suggestion and wouldn't mind if we need to keep the twitter format as long as it is simpler to convert.

Also I would expect the same kind of simplification for common units of measurement. Common units are m/inch (I think there is nothing like meters in IP), cm/inch, km/miles, °F/°C, kg/pounds.
Note: if we are to use buttons on screen (and not real calculator buttons) it would make sense to have contextual units of measurement. For exemple if there is a value in cm on stack, we shall see a 'inch' button. Then when you press that 'inch' button, the value is converted into inches but you see the former button replaced by a new 'cm' one. See the idea?

Finally why not having support for currencies?
02-24-2014, 03:20 PM (This post was last modified: 02-24-2014 07:00 PM by Stefan.)
Post: #3
 Stefan Member Posts: 87 Joined: Dec 2013
RE: Improved change of integer base
For the common units converter: Here is my (still non functional) attempt for a user key for that. I stopped because I didn't know how to evaluate which menu item was selected.

Edit: The first version I posted was not tested because I had no possibility to transfer the program to the computer, so I just typed it of the Prime's screen. Now I tested and improved it a little. Conversion is working in principle. However User interaction via on screen buttons is still missing.
Edit2: removed code. See my post below for the improved version.
Code:
 removed code. See my post below for the improved version.
02-24-2014, 06:59 PM
Post: #4
 Stefan Member Posts: 87 Joined: Dec 2013
RE: Improved change of integer base
Now the user input works, I created a small code snippet which can be used as more useful drop in replacement for the "drawmenu()" function (see also my other thread).
The on screen buttons now show the units in which the "Ans" value can be converted. If the user taps one unit, the converted value appears on the input line.
2 Problems remain:
1. I have to poll the mouse() value, which is not nice to the CPU.
2. If the user presses the a softbutton, the underlying softbutton of the system (e.g. "STO->" for the first softbutton in HOME view) is also pressed.
If you have answers to the question please post them in the thread regarding the code snippet. I think that's more useful there.

Code:
 EXPORT DrawMenuSelect(buttonlabellist) // Parameters: menustringlist is a list which should contain at most 6 strings for the button labels // Returns: The ID (1 to 6) of the button that was pressed BEGIN  LOCAL selection, mouselist;  DRAWMENU(buttonlabellist);  FREEZE();  WHILE MOUSE(1)<#DD:-16h DO END;//Wait until the screen is touched somewhere in the  verticle region of the soft keys  mouselist:=MOUSE();  selection:=CEILING((MOUSE(0)+1)*6/320); // Screen is 320px wide. There are six buttons. hence divide mouse value by 320/6. To avoid getting a value of zero when the user presses exactly at the left border a 1 is added to the mouse value  RETURN selection; END;  EXPORT KEY K_Templ() BEGIN  LOCAL val, unit, conv, selection;  val:=STRING(Ans);  unit:=MID(val,INSTRING(val,"_"));  CASE   IF ((unit=="_(°C)") OR (unit=="_(°F)") OR (unit=="_(K)")) THEN conv :={"°C", "°F", "K"}; END;   IF ((unit=="_(m)") OR (unit=="_(mm)") OR (unit=="_(cm)") OR (unit=="_(km)")) THEN conv :={"yd", "ft", "in", "mile"}; END;   // IF THEN END; // insert cases for other common combinations here   DEFAULT RETURN "Error: No conversion implemented for that.";  END;  selection:=DrawMenuSelect(conv);  // save the selected destination unit in "unit" variable  unit:=EXPR("1_(" + conv(selection) + ")");   RETURN STRING(CONVERT(EXPR(val),unit)); END;

@Angus: I think this could easily adapted to achieve the base conversion you mentioned.
03-01-2014, 10:22 AM (This post was last modified: 03-01-2014 10:23 AM by Angus.)
Post: #5
 Angus Member Posts: 212 Joined: Feb 2014
RE: Improved change of integer base
hello,

last night I had some time and started playing again with my prime. First I headed towards some program fragments, but soon I realized that I need to get more familiar with the calculator and its commands first.

I tried the SETBASE command.
In home view there is a syntax error no matter if I type SETBASE(88), SETBASE(#88), SETBASE (#88,3), SETBASE(88,3) or whatever. Any ideas?

In the cas view the command also fails. It converts SETBASE(#88,3) to SETBASE(#(88),3) with 88 as result no matter what base is chosen. Same with SETBASE(88,3).

Any help is appreciated since these basics should work prior to going for a custom converter tool, right? ;-)

btw. using units in cas view is a bit troublesome, too.
03-01-2014, 11:50 AM
Post: #6
 Terje Vallestad Member Posts: 145 Joined: Dec 2013
RE: Improved change of integer base
(03-01-2014 10:22 AM)Angus Wrote:  I tried the SETBASE command.
In home view there is a syntax error no matter if I type SETBASE(88), SETBASE(#88), SETBASE (#88,3), SETBASE(88,3) or whatever. Any ideas?

I think you may be in RPN. To use RPN you would have to enter

#88d // d may be omitted if you use system base
4 // To convert to Hex (0: system, 1: bin, 2: oct, 3: dec, 4: hex)
SETBASE(2) // To absorb two arguments from the stack

Sorry about the formatting, but don't know how to do a nice table and multiple spaces are ignored, however // denotes a comment

I don't understand how this supposed to work in CAS but some help may probably be found on the XCAS website.

Cheers, Terje
03-01-2014, 06:30 PM (This post was last modified: 03-01-2014 06:31 PM by massimo.)
Post: #7
 massimo Junior Member Posts: 21 Joined: Feb 2014
RE: Improved change of integer base
(03-01-2014 10:22 AM)Angus Wrote:  In home view there is a syntax error no matter if I type SETBASE(88), SETBASE(#88), SETBASE (#88,3), SETBASE(88,3) or whatever. Any ideas?

On my calc I haven't any problem. Have you verified that the default integer base is not binary (in Home Settings)? I learned that is better to use explicit base in integer number (#88h not #88).

Massimo
from 34c to prime
03-01-2014, 07:17 PM (This post was last modified: 03-01-2014 07:18 PM by Angus.)
Post: #8
 Angus Member Posts: 212 Joined: Feb 2014
RE: Improved change of integer base
Terje you're right. I totally forgot I had home set to rpn.... Since I try to force myself to stay in cas, home was not touched for some time.... thanks!

But the whole story proves to me how important or just wonderful it would be to have the home/cas discrepancies wiped away, would'nt it?
Home/cas/app consistency, Variable usage between them has a top priority on my wishlist.
HP should really rework the prime having these aspects in mind, but I doubt that they will go for it. It would require to admit failing at the design stage.

I'm still confused but I keep working on my skills.

edit: should the command work in cas view?
03-01-2014, 07:30 PM (This post was last modified: 03-01-2014 07:40 PM by Tim Wessman.)
Post: #9
 Tim Wessman Senior Member Posts: 2,225 Joined: Dec 2013
RE: Improved change of integer base
>It would require to admit failing at the design stage

I don't think that is the case. I suspect you have linked two completely separate concepts/issues in your mind, when in reality they are quite different. Having two separate locations for calculations to be performed is completely different then having two separate parsers with incompatibilities between them in the underlying interfaces.

TW

Although I work for the HP calculator group, the views and opinions I post here are my own.
03-01-2014, 09:47 PM (This post was last modified: 03-01-2014 09:48 PM by Angus.)
Post: #10
 Angus Member Posts: 212 Joined: Feb 2014
RE: Improved change of integer base
Tim, most propably you are right in that I might mix up my anticipations with what is there... Do you think there will be written facts on how to deal with the concepts in practice? Combined with as many examples as possible that could be really beneficial.

However, I still don't know how to use e.g. the SETBASE command in cas. Should that work in the cas? Writing programs for universal use in both cas and Home mode is not an easy task if some functionality like supported commands or their spelling differs.
03-02-2014, 04:27 PM (This post was last modified: 03-02-2014 04:28 PM by Angus.)
Post: #11
 Angus Member Posts: 212 Joined: Feb 2014
RE: Improved change of integer base
hello,

I apologize for double posting, but some questions came up while I work with the hp prime.

Code:
 EXPORT SoftMenu(buttons) BEGIN   DRAWMENU(buttons);   LOCAL inp:=WAIT(-1);                       IF TYPE(inp)≠6 THEN RETURN inp; END;       //IF inp(1)≠#0d THEN RETURN""; END;     IF inp(1)≠#0d AND      inp(1)≠#3d AND      inp(1)≠#7d THEN RETURN ""; END;         IF inp(3)<#220d THEN RETURN ""; END;      LOCAL btn:=1+IP(inp(2)*6/320);               RETURN btn; END; KEY KS_Minus() BEGIN   LOCAL menu, ret;    menu:={"#dec","#hex","#bin","R->B","B->R","#"};   ret:=SoftMenu(menu);   IF Entry==2 THEN    //_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   //RPN   //_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   //DUPN; //how would you use Stack commands in a program?     //IF TYPE(1)==0 THEN //needs integer conversion   //????????IF there is an integer constabt #1234 on the stack / command line the user key seems to be ignored? //DROP //???????would the comparison drop it?     CASE       IF ret==1 THEN RETURN " 32 3 R→B(3)"; END;       IF ret==2 THEN RETURN " 32 4 R→B(3)"; END;       IF ret==3 THEN RETURN " 32 1 R→B(3)"; END;       IF ret==4 THEN RETURN "R→B()"; END;       IF ret==5 THEN RETURN "B→R()"; END;       IF ret==6 THEN RETURN "#"; END;       DEFAULT RETURN ""; //??????'autoexecute' of the command? doing an auto <enter>     END;     //END;   ELSE    //_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   //TEXTBOOK   //_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ //???????can you use the command line as argument aswell?      CASE       IF ret==1 THEN RETURN "R→B("+Ans+",32,3)"; END;       IF ret==2 THEN RETURN "R→B("+Ans+",32,4)"; END;       IF ret==3 THEN RETURN "R→B("+Ans+",32,1)"; END;       IF ret==4 THEN RETURN "R→B("+Ans+")"; END;       IF ret==5 THEN RETURN "B→R("+Ans+")"; END;       IF ret==6 THEN RETURN "#"; END;       DEFAULT RETURN "";     END;   END; END;

Converting to integer-type works so far. My intention is to switch between bases if there is already an integer constant available as argument (that is SETBASE). But it seems that Shift+Minus starts the base window and the user key is ignored then.
Is there a way to prevent that? using F6 to launch the window in my example would be my choice. Can you confirm, that base can't be used as user-key for integer type values?

Using rpn entry: I tried to do a if TYPE()==0 to check for real number. That would require a DUPN of the original argument. How can I invoke stack commands?
And is there a way to execute the command line that is returned?

Using textbook entry: is it really impossible to use input from the command line directly?

If someone likes to comment on the code fragment please feel free to post. Feedback is important for learning.
 « Next Oldest | Next Newest »

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