Problem using unit "mn"

09052018, 10:46 AM
Post: #1




Problem using unit "mn"
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 TimeUnit 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 

09052018, 01:43 PM
Post: #2




RE: Problem using unit "mn"
Isn't it so that CAS uses lower case while Home uses capitals?
May that be the answer? Esben 28s, 35s, 49G+, 50G, Prime G2 HW D, SwissMicros DM42, DM32, WP43 Pilot Elektronika MK52 & MK61 

09052018, 02:10 PM
Post: #3




RE: Problem using unit "mn"
Thanks for the answer.
Yes  but when you use the UnitsMenu in CASview, the command is written with capitals. The units in menu are changing between Home view and CASview (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 CASview). Christian 

09052018, 06:39 PM
Post: #4




RE: Problem using unit "mn"
min is a CAS command (minimum).


09062018, 01:31 AM
Post: #5




RE: Problem using unit "mn"
(09052018 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 

09062018, 03:04 AM
Post: #6




RE: Problem using unit "mn"
(09062018 01:31 AM)CyberAngel Wrote:(09052018 06:39 PM)parisse Wrote: min is a CAS command (minimum).[HOME] 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 

09062018, 03:32 AM
Post: #7




RE: Problem using unit "mn"
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. TW Although I work for HP, the views and opinions I post here are my own. 

09062018, 01:27 PM
Post: #8




RE: Problem using unit "mn"
(09062018 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. 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://wwwfourier.ujfgrenoble.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 PDFdocument here: https://wwwfourier.ujfgrenoble.fr/~par...cmd_en.pdf 

09062018, 01:52 PM
(This post was last modified: 09062018 01:55 PM by StephenG1CMZ.)
Post: #9




RE: Problem using unit "mn"
(09052018 01:43 PM)DA74254 Wrote: Isn't it so that CAS uses lower case while Home uses capitals? 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/thread492...meganewton Stephen Lewkowicz (G1CMZ) https://my.numworks.com/python/steveg1cmz 

09062018, 03:33 PM
Post: #10




RE: Problem using unit "mn"
I've committed a trick to parse _min as _mn.


09062018, 04:08 PM
Post: #11




RE: Problem using unit "mn"
(09062018 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. 

09062018, 06:54 PM
Post: #12




RE: Problem using unit "mn"
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. 

09062018, 07:16 PM
Post: #13




RE: Problem using unit "mn"
(09062018 06:54 PM)parisse Wrote: I speak for CAS, USIMPLIFY is not a CAS command. 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 CASonly underlined, Homeonly in bold? VPN 

« Next Oldest  Next Newest »

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