Problem using unit "mn"

[ChrisSchw]

I am playing a little bit with units and find a inconsistency.

If you are in CAS view and use "USIMPLIFY" or "MKSA" from Units menu (Shift + C) with Time-Unit in "mn" for minutes there, i get an error. I think "USIMPLIFY" expect "min" (like in HOME view), but "min" is reserved in CAS view.
If you use "usimplify" instead of "USIMPLIFY", then it is working.

Example:
USIMPLIFY(5_mn+10_s) --> Error
usimplify(5_mn+10_s) --> 310._s

What is the difference between "USIMPLIFY" and "usimplify"? Same with "MKSA" and "mksa".

Thanks,
Christian

[DA74254]

Isn't it so that CAS uses lower case while Home uses capitals?
May that be the answer?

[ChrisSchw]

Thanks for the answer.

Yes - but when you use the Units-Menu in CAS-view, the command is written with capitals.
The units in menu are changing between Home view and CAS-view (f.e. Time "min" and "mn"), but the function is always with capitals.
--> for better consistency it will help, when functions in unit menu are in lower case (if you are in CAS-view).

Christian

[parisse]

min is a CAS command (minimum).

[CyberAngel]

(09-05-2018 06:39 PM)parisse Wrote:  min is a CAS command (minimum).

[HOME]
USIMPLIFY(1_(h)) [ENTER]
3600_s

USIMPLIFY(1_(min)) [ENTER]
60_s

[CAS]
USIMPLIFY(1_(h)) [ENTER]

3600_s
USIMPLIFY(1_(min)) [ENTER]

=> USIMPLIFY(1_'min')
* or in the command line: USIMPLIFY(1_()'min')
giving
"Error:Bad argument type"

which means that in the Command line parsing (or #cas program)
the *UNITS* has to be checked first - even before CAS commands
when you find the _ structure or rather _()

This is the root of the problem that the user described
Proper handling of the UNITS system ensures
that there will never be a glitch like this between the CAS and the UNITS

NOTE: Also the [Shift] [Units] soft menu "tab" [Units]
5 Time > 8 mn

should be
5 Time > 8 min
- - -
VPN

[CyberAngel]

(09-06-2018 01:31 AM)CyberAngel Wrote:  

(09-05-2018 06:39 PM)parisse Wrote:  min is a CAS command (minimum).

[HOME]
USIMPLIFY(1_(h)) [ENTER]
3600_s

USIMPLIFY(1_(min)) [ENTER]
60_s

[CAS]
USIMPLIFY(1_(h)) [ENTER]

3600_s
USIMPLIFY(1_(min)) [ENTER]

=> USIMPLIFY(1_'min')
* or in the command line: USIMPLIFY(1_()'min')
giving
"Error:Bad argument type"

which means that in the Command line parsing (or #cas program)
the *UNITS* has to be checked first - even before CAS commands
when you find the _ structure or rather _()

This is the root of the problem that the user described
Proper handling of the UNITS system ensures
that there will never be a glitch like this between the CAS and the UNITS

NOTE: Also the [Shift] [Units] soft menu "tab" [Units]
5 Time > 8 mn

should be
5 Time > 8 min
- - -
VPN

If my educated guess above is correct
then the following might help to pinpoint the underlying parsing problem
[Home]
#1048576:64d [Enter]
#1048576:64d

This means that after ":" the 64 is word size and "d" is decimal
(h=hex, o=oct, b=bin)
# starts a binary number, not exact integer or approximate decimal

Now say I have a variable 'd' of a value exactly 9
[CAS]
[Menu] 1 Get from Home
select the #1048576:64d [Enter]
#(1048576),64*d) :(1048576:576)

Here the parsing of a binary integer get all mixed up in CAS
Both the word size ":" and the binary "#" should be handled first priority
before variables and similarly to [Home]

The parsing problem here is that if there's a ":" word size symbol
then the "d" after the ":64" is interpreted as a variable 'd'

Anyway the CAS doesn't retain binary integers,
but changes them to exact integers
I think it should keep them like the [Home] mode does
- - -
VPN

[Tim Wessman]

CAS does not support the concept of fixed width integers. The author has no interest in adding them as it does not fit with CAS type operations.

Similarly, we've done our best to make units work properly, but we have no control over the CAS handling of units.

[CyberAngel]

(09-06-2018 03:32 AM)Tim Wessman Wrote:  CAS does not support the concept of fixed width integers. The author has no interest in adding them as it does not fit with CAS type operations.

Similarly, we've done our best to make units work properly, but we have no control over the CAS handling of units.

Well, small price to pay considering how extensive it is
compared to the old HP 49/50 series CAS (or the original HP 40 CAS).
This is the first time ever I'm not going to teach myself all the commands 100%.

I found the HP Prime CAS Command set PDF available in English:

https://www-fourier.ujf-grenoble.fr/~par...me_cas.pdf

It seems that the integrated version 1.49 does not contain absolutely every command.
The document is most likely not properly adapted for the HP Prime.
I didn't list every capitalized name/NAME version difference - only: rref 138 & xor, 197
The page numbers are off thus I couldn't check the functions quickly.

!=, 196, 507; %e, 196; %i, 196; %pi, 196; &&, 197; &*, 324; &ˆ, 324; /laplace, 95; ||, 197; ‘’, 61
angleat, 423; angleatraw, 423; areaat, 424; areaatraw, 424
bounded_function, 67
Celsius2Fahrenheit, 374; colSwap, 317; comment, 491; common_perpendicular, 377
distanceat, 425; distanceatraw, 426
euler_gamma, 196
fadeev, 328; Fahrenheit2Celsius, 374; false, FALSE, 196; frac, 204
InputStr, 491; integrate, 76; is_coplanar, 443
mRowAdd, 323
norm, 290
ofnom, 57
pcoef, 157, 163; perimeterat, 427; perimeteratraw, 428; plotdensity, 190; POLYFORM, 306
ramn, 332; rand, 229; randmatrix, 332; rootof, 155; rref, 138, 329
slopeat, 428; slopeatraw, 429; snedecor, 239; snedecor_cdf, 242; snedecor_icdf, 246; sq, 199; srand, 236; sturm, 171
table, 271; time, 41; true, TRUE, 196
UTPC, 236; UTPF, 236; UTPN, 237; UTPT, 237
xor, 197
ΔLIST, 285; ΠLIST, 286; ΣLIST, 286
_______________________________________
Note that the catalog on the calculator (PC Emulator) might be outdated.
Also there are MORE commands that are listed in the document index.
Finally, there's a general (PC?) version PDF-document here:

https://www-fourier.ujf-grenoble.fr/~par...cmd_en.pdf

[StephenG1CMZ]

(09-05-2018 01:43 PM)DA74254 Wrote:  Isn't it so that CAS uses lower case while Home uses capitals?
May that be the answer?

Be careful of possible confusion, in that if mn were capitalised into MN, MN is a potentially valid SI unit : MegaNewtons- although it is not likely to be confused for a unit of time
http://www.hpmuseum.org/forum/thread-492...meganewton

[parisse]

I've committed a trick to parse _min as _mn.

[CyberAngel]

(09-06-2018 03:33 PM)parisse Wrote:  I've committed a trick to parse _min as _mn.

Well, that was fast! - Maybe even too fast?!

When using USIMPLIFY on Android & PC
both 1_min and 1_mn give the answer
"Error: Bad Argument Value"
While
USIMPLIFY(1_h)
gives the correct answer 3600_s

The same problem happens with
CONVERT(1_mn,1_s)
and MKSA
and UFACTOR

They don't understand the unit "mn"
Try them out to see yourself.

[parisse]

I speak for CAS, USIMPLIFY is not a CAS command.
usimplify(1_mn) returns 60_s.
usimplify(1_min) will return 60_s.
You can make most of the time the distinction between CAS and Home with lowercase vs uppercase commands. In doubt, try to type the commandname alone : usimplify alone or USIMPLIFY alone. A CAS command is an object, a Home command is not, it will error.

[CyberAngel]

(09-06-2018 06:54 PM)parisse Wrote:  I speak for CAS, USIMPLIFY is not a CAS command.
usimplify(1_mn) returns 60_s.
usimplify(1_min) will return 60_s.
You can make most of the time the distinction between CAS and Home with lowercase vs uppercase commands. In doubt, try to type the commandname alone : usimplify alone or USIMPLIFY alone. A CAS command is an object, a Home command is not, it will error.

Thank you for your quick responses
and for the best CAS currently on the planet.

I keep on banging this separation into my head.
The HP 49/50 was consistent.
VPN
________________________________________________
Tim Wessman
For a new user of the HP Prime this is confusing.
I hope that the Home mode adapts more to the CAS.
At least there should be a separation in the catalog of commands. Perhaps tabs [All] [Home] [CAS]
Maybe CAS-only underlined, Home-only in bold?
VPN