unnecessary confusion w/ Convert cmd

[resolved]

if I use the convert command in Home
CONVERT(2_(km),99_(ft)) I get 6561.6…..
CONVERT(2_(km),1_(ft)) I get 6561.6…..
CONVERT(2_(km),0_(ft)) I get 6561.6…..
but
CONVERT(2_(km),_(ft)) I get an ERROR
or
Help's example
CONVERT(20_m,1_ft) I get 65.6167….

if I use the convert command in CAS
CONVERT(2_(km),99_(ft)) I get an ERROR
CONVERT(2_(km),1_(ft)) I get an ERROR
CONVERT(2_(km),0_(ft)) I get an ERROR
CONVERT(2_(km),_(ft)) I get an ERROR
or
Help's example
CONVERT(20_m,1_ft) I get an ERROR

if I use STO symbol in Home
2_(km)"triangle"99_(ft) I get an ERROR
2_(km)"triangle"1_(ft) I get an ERROR
2_(km)"triangle"0_(ft) I get an ERROR
but
2_(km)"triangle"_(ft) I get 6561.6…..

the above is true for CAS (wonderful)

in Home view if I type
2_(KM)"triangle"_FT I get an ERROR
in CAS view if I type the same
2_(KM)"triangle"_FT I get _[((1000.*_M)/_FT * 2. _FT])

There were other anomalies, but my mind broke I can't remember what they were. When using the CONVERT cmmd you have to put in a number before the second unit, (that is ANY number, a billion would do), but in the "triangle" cmmd you must NOT put in a number before the second unit. The 616 page manual says nothing about this anomaly.
Instead of just ERROR messages, can't HP just inform the user "This function only works in Home mode" This simple instruction would save hours of research and frustration for the users trying to figure which comma was misplaces, etc.

[alexzkter]

(06-14-2014 03:27 AM)resolved Wrote:  if I use the convert command in Home
CONVERT(2_(km),99_(ft)) I get 6561.6…..
CONVERT(2_(km),1_(ft)) I get 6561.6…..
CONVERT(2_(km),0_(ft)) I get 6561.6…..
but
CONVERT(2_(km),_(ft)) I get an ERROR
or
Help's example
CONVERT(20_m,1_ft) I get 6561.6…..

if I use the convert command in CAS
CONVERT(2_(km),99_(ft)) I get an ERROR
CONVERT(2_(km),1_(ft)) I get an ERROR
CONVERT(2_(km),0_(ft)) I get an ERROR
CONVERT(2_(km),_(ft)) I get an ERROR
or
Help's example
CONVERT(20_m,1_ft) I get an ERROR

if I use STO symbol in Home
2_(km)"triangle"99_(ft) I get an ERROR
2_(km)"triangle"1_(ft) I get an ERROR
2_(km)"triangle"0_(ft) I get an ERROR
but
2_(km)"triangle"_(ft) I get 6561.6…..

the about is true for CAS (wonderful)

in Home view if I type
2_(KM)"triangle"_FT I get an ERROR
in CAS view if I type the same
2_(KM)"triangle"_FT I get _[((1000.*_M)/_FT * 2. _FT])

There were other anomalies, but my mind broke I can't remember what they were. When using the CONVERT cmmd you have to put in a number before the second unit, but in the "triangle" cmmd you must NOT put in a number before the second unit. The 616 page manual says nothing about this anomaly.
Instead of just ERROR messages, can't HP just inform the user "This function only works in Home mode" This simple instruction would save hours of research and frustration for the users trying to figure which comma was misplaces, etc.

I think there should be a specific app for conversion. One with a modern GUI...too many key presses right now for just converting from one unit to another, in my opinion. Or at least the whole process of going through the menus is tiring.

[Tugdual]

Conversion with the Prime is very academic and extremely inconvenient.
Something less academic and more straightforward and practical like the 34s implementation would be much much better.
I gave up with the Prime on this topic, official answer is "Prime is for education, not ingeneers". I woul personnally think that what is good for engineers is probably good for studients but... oh well...

[Michael de Estrada]

(06-14-2014 09:40 AM)Tugdual Wrote:  Conversion with the Prime is very academic and extremely inconvenient.
Something less academic and more straightforward and practical like the 34s implementation would be much much better.
I gave up with the Prime on this topic, official answer is "Prime is for education, not ingeneers". I woul personnally think that what is good for engineers is probably good for studients but... oh well...

I don't use my Prime for unit conversions either. Instead, I use my 50g, which requires half as many keystrokes, and is far simpler. If I were still a practicing engineer, I would leave the Prime at home.

[resolved]

(06-14-2014 09:40 AM)Tugdual Wrote:  Conversion with the Prime is very academic and extremely inconvenient.
Something less academic and more straightforward and practical like the 34s implementation would be much much better.
I gave up with the Prime on this topic, official answer is "Prime is for education, not ingeneers". I woul personnally think that what is good for engineers is probably good for studients but... oh well...

if the Prime is truly for education and not engineers, then they would simplify the process by being consistent to reinforce the methodology. Nothing is more confusing to students than inconsistent approaches in an area they are just learning. The confusion and frustration will cause them to quit using the Prime just like the engineers. Also 18 key strokes is just too many to get one conversion

[resolved]

yet another bug -- can't do any conversion with inches, from or to anything, though I didn't test them all, very frustrating.

[Tim Wessman]

The CAS uses _inch, not _in

[Helge Gabert]

While unit conversion with CONVERT works great in Home, I don't have any luck with that in CAS at all - - Error: unmatch control word - - is what I get.

[parisse]

convert(1_m,1_inch)
or 1_m STO> _inch
What does not work for you?

[Helge Gabert]

OK, in CAS, I picked CONVERT (upper case) from the tool box catalog.

So CONVERT(1_m,1_inch) results in Error.

But if I type in convert (lower case) it works _([39.37... _inch]).

[edit: so what probably ought happen here is that the toolbox catalog inserts automatically the correct, lower case command, if the user is in CAS - - there are a bunch of older threads about his as well, not just restricted to CONVERT, but also to other commands, like MAKEMAT, etc.]

[Angus]

It would be even better if there were not different spellings in cas and home at all. For commands, units etc.
Is there a reason why things are implemented that way? I mean the command(s) itself, in/inch....
It is indeed confusing. Plus people (students. i.e. primary targeted custumors) have to learn exceptions and can not rely on one typing for one calculator.

[Giancarlo]

Hello,
Apart the Prime destination user(engineers vs students) which in my opinion is a false problem because I am musing my calculators as i used them at school, i am more and more convinced that the only way to reduce the number of keystrokes woulde be to have specific apps (like alexzkter said) with a clean interface.

The issue now is that we do not have all the tools to create these APPS because we cannot link programs to apps icons, we cannot create icons, we do not have soft menu ready to use and the input command is to be verified (mixing input boxes, dropdown boxes and checkboxes still gives me problems).

Only with these enhancements it will be possible for us to help HP creating applications to share and with the best interface possible and grow the community (again).

In any way i use my prime on a daily basis and leave at home my hp49g+,

Giancarlo

[Tim Wessman]

(07-23-2014 05:57 AM)Giancarlo Wrote:  we cannot link programs to apps icons

Can you please elaborate what you mean by that? You have the ability to have programs that are only active when the app is running. You have the ability to redefine to run custom code on all standard views, as well as add views. In fact, it seems that to make an "application" that integrates in with the system a general user is much more capable at doing so then on the 50 where you can't really do anything similar until you get into a paramaterized outer loop.

So please explain more what you are meaning there so I can understand. Thanks!

[parisse]

in can not be used in CAS for units because in is a reserverd word for loops with an iterator in a list like (checked in Xcas)
l:=[1,2,3];
for j in l do print(j); end;

[Angus]

Thank you for your explanation, parisse.
But isn't the symbol _in? Is the loop you mentioned usable code from within programs? So you can use the loop in a cas program but NOT in a home program? I didn't know such syntax is available at all.

Can you say that in cas mode there are other reserved words than in home? In cas mode is it your original core-code that parses the entry - there is no hp parser that would realize tokens like units? And is that the reason that there are numerous typos with the commands? You use a different spelling in xcas than hp used in their hp39 code? (I prefer to call it cas mode. I understand that often things come from xcas but when I switch my calculator into cas it is still the prime I hold in my hands. If mangling the xcas into the hp system causes so much trouble I would personally not have chosen that road in the design stage)

If there is no way around such things (I don't want to criticise again or question the design again) wouldn't it be better to get rid of _in and use _inch system wide? Although I hate unnecessary keystrokes and long symbols on a calculator keyboard ;-)

[Giancarlo]

(07-23-2014 02:13 PM)Tim Wessman Wrote:  

(07-23-2014 05:57 AM)Giancarlo Wrote:  we cannot link programs to apps icons

Can you please elaborate what you mean by that? You have the ability to have programs that are only active when the app is running. You have the ability to redefine to run custom code on all standard views, as well as add views. In fact, it seems that to make an "application" that integrates in with the system a general user is much more capable at doing so then on the 50 where you can't really do anything similar until you get into a paramaterized outer loop.

So please explain more what you are meaning there so I can understand. Thanks!

Hello Tim,
And thank you so much for reading my post.
I think about Prime APPS like hp48/49/50 libraries but the Prime has the possibility for a user to add some code in order to customize the behaviour of an application. I tested it some months ago trying to implement a simple equation library and i understand your point.

What i tried to explain in my previous post is that it would be useful to run programs clicking on a customized icon in order to avoid to write the program name on the keyboard or scroll tenth of programs into the editor list. Then having an inform command (input) and custom menu (drawmenu ready to use) we would have the skeleton of all the applications.

Do i have a too simple view of things?

Then the issue could be scrolling tenth of programs in the apps screen but this is another story. In the tricider hp Prime list someone is asking to have folders in the apps screen.

I know this makes a lot of work for a (small) team but these things should be considered in your roadmap.
I can understand the daily constraints and decide if clearing a snag list, implement new functions or give new functionalities to users. This is the dilemma and we cannot suggest as users what to do. This is strictly tied to your corporate strategy even if i understand that you are trying to implement the three topics together...

Thanks for you ongoing support and endless patience,

Giancarlo

[parisse]

(07-24-2014 05:15 AM)Angus Wrote:  Thank you for your explanation, parisse.
But isn't the symbol _in? Is the loop you mentioned usable code from within programs? So you can use the loop in a cas program but NOT in a home program? I didn't know such syntax is available at all.

Yes the symbol is _in but the way it works it requires in not to be a keyword.
And I just checked the for loop in the emulator, it works.

Quote:Can you say that in cas mode there are other reserved words than in home? In cas mode is it your original core-code that parses the entry - there is no hp parser that would realize tokens like units? And is that the reason that there are numerous typos with the commands? You use a different spelling in xcas than hp used in their hp39 code? (I prefer to call it cas mode. I understand that often things come from xcas but when I switch my calculator into cas it is still the prime I hold in my hands. If mangling the xcas into the hp system causes so much trouble I would personally not have chosen that road in the design stage)

The CAS parser was adapted from the Xcas parser (some rules are not available), and the CAS lexer has less keywords than the Xcas parser: for example synonyms were removed unlike in Xcas, where you can sometimes use several keywords for the same command (one is familiar for TI users, one for maple users, etc.). The general rule in Xcas is that you can type a command all lowercase (no need to switch if you type from keyboard). The general rule in Prime Home is that you can type a command all uppercase. Some commands exist in Home uppercase and CAS lowercase that have almost the same functionnality, but not exactly the same: convert is one example, since convert in CAS can also do symbolic conversions. I think that if HP modifies the UI so that commands in the catalog appear in lowercase when called from CAS mode and both commands exist, a large part of the confusions would disappear.