Problem using unit "mn"

[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