concatenation of prefixes with units and some problems

[compsystems]

Hello,

A: Problem #1: I think prefixes should also be simplified/ evaluated or concatenated

_m*_k → _m*k → _mk → 1E−3*1E3 → 0.001*1000 → 1

DEG MODE
(4∡23°) * (5+7*i); [enter] 7.46962547135+33.5887584665*i // ok

(4∡23°)*1_A * (5+7*i)*_Ohm; [enter] → 7.46962547135+33.5887584665*i_(A*Ohm) // ok

(4∡23°)_m*_A * (5+7*i)*_k*_Ohm; [enter] →
7.46962547135+33.5887584665*i _(A*Ohm*k*m) // ok

but

USIMPLIFY( (4∡23°)_m*_A * (5+7*i)*_k*_Ohm ); [enter] → "Bad Argument Type" (current firmware =( ). Why?

USIMPLIFY( (4∡23°)_m*_A * (5+7*i)*_k*_Ohm ); [enter] → 7.4696254713+33.5887584665*i _V ( In the firmware near future =) )

v:=(I_m_A)*(R_k_Ω) -> v:=(I_mA*R_kΩ)

Screen capture


Source of example, (exercises of electronic engineering)
www.numerari.com/complex-numbers



B: problem #2

(4∡23°)*_A * (5+7*i)*_Ohm; -> 7.46962547135+33.5887584665*i_(A*Ohm) OK
[up][up] copy [ENTER]; 4 (∡i(115.+161.*i_(A*Ohm)) ?

The entries of the history to the entry line must be able to recover without alteration, in many cases places redundant parentheses, in this case suppresses them and the problem is generated, because the angle argument expands to the right.

4: Please improve the pretty printing of the polar form of a complex number and other situations I have reported in this forum

∡(4,23) This notation is confusing, I have not seen it in any math book

Thanks

[compsystems]

Hello another problem #3

The following statements, after closing and reopening the simulator, appears UNDEF

(4∡23°) * (5+7*i); [enter] 7.46962547135+33.5887584665*i // ok

(4∡23°)_A * (5+7*i)_Ohm; [enter] → 7.46962547135+33.5887584665*i _(A*Ohm) // ok

(4∡23°)_m*_A * (5+7*i)_k*_Ohm; [enter] →
7.46962547135+33.5887584665*i _(A*Ohm*k*m) // ok

[Carlos295pz]

The prefixes are not used independently, it is always attached to the unit. Test the calculations in Home, the symbolic flow of the CAS can cause confusion.

[compsystems]

I do not want to place them independently, are the templates that do this, the interpretation must be improved,

Following the steps (Home Mode) to enter the expression from template

(4∡23°) + [Shift][templates(Units)][units] 1:prefix + [m] + E:Electricity [A]

(4∡23°)_(m)_(A) [enter] "syntax error" // -> the parser must concatenate prefix with unit (4∡23°)_(mA) Otherwise, (4∡23°)_(m)*_(A) when the calculator is turned on again, show UNDEF problem #3

Now on CAS mode There is still a problem #4

(4∡23)_mA*(5+7*i)_kOhm; [enter] returns
7.46962547135+33.5887584665*i _(kOhm*mA)

USIMPLIFY( [up][copy]

USIMPLIFY(7.46962547135+33.5887584665*i_(kOhm*mA)); [enter] returns
"Error: Bad argument type" because kOhm*mA Belongs to i (imaginary unit) and not to all expression as it should be

A solution that planted in previous post, COPY must paste between parentheses, because sometimes objects need to operate between (), You all agree?
So the previously referenced problems are solved

(4∡23)_(mA)*(5+7*i)_(kOhm); [enter] returns
7.46962547135+33.5887584665*i_(kOhm*mA) // ok

USIMPLIFY( [up][copy]

USIMPLIFY( ( 7.46962547135+33.5887584665*i )_(kOhm*mA)); [enter] returns
7.46962547135+33.5887584665*i_(V) ok

problem #5
DEG MODE
Specifying in which mode is the angle

(4∡23_deg)_mA*(5+7*i)_kOhm;
returns
(4∡23_deg)*(5+7*i)_kOhm*_mA; // ok

USIMPLIFY(Ans); -> "Error: Unmatch control word" I think the CAS can not interpret (_deg)


now HOME MODE

(4∡23_deg)_mA*(5+7*i)_kOhm;
or
(4∡0.401425727959_rad)_mA*(5+7*i)_kOhm
or
(4∡0.401425727959_rad)_mA*(8.60232526704∡54.462322208_deg)_kOhm
returns
(34.4093010682∡77.4623222081)_(mA*kOhm) // ok

USIMPLIFY(Ans); ->
(34.4093010682∡77.4623222081)_(V) // ok

PHP Code:

EXPORT testAnglesOnPolarForm()
BEGIN
 print;
 print((4∡23)_mA*(5+7*i)_kOhm); // ok 
 print((4∡23)_mA*(8.60232526704∡54.462322208)_kOhm); // ok
 print((4∡23_deg)_mA*(8.60232526704∡54.462322208_deg)_kOhm); // can not interpret _deg
 print((4∡0.401425727959_rad)_mA*(8.60232526704∡54.462322208_deg)_kOhm); // can not interpret _rad
END;