Post Reply 
NewRPL: Complex Numbers in Cartesian Form r[x,y] , ...
03-16-2017, 03:47 AM (This post was last modified: 04-13-2017 02:22 PM by compsystems.)
Post: #1
NewRPL: Complex Numbers in Cartesian Form r[x,y] , ...
Hello, sorry for my bad English

The Book "Complex Variables and Applications - James Ward Brown, Ruel ..."
Shows in your introductory part operations of complex numbers in cartesian form, I am replicating this in a library (HP-50), I would like to see this notation in NEWRPL, in addition to the phasor form (Widely used in Electrical and Electronic engineering)

Thanks

PHP Code:
%%HPT(0)A(D)F(.);
Library of Complex Numbers in Cartesian Form
Authorcompsystems
Versionalpha 0.5 April 10 2017
Coded with HPUserEdit 6
BibliographyComplex Variables and Applications James Ward BrownRuel ...

@  
ƒ =  SQRT
@  [] = -> (STORE)

UPDIR 'cplx' PGDIR -27 CF -128 SF -114 CF
RAD
RECT

DIR

  cplx1 
'(x1,y1)'
  
cplx2 '(x2,y2)'
  
cplx3 '(x1,0)'
  
cplx4 '(x2,0)'
  
cplx5 '(x,0)'
  
cplx6 '(0,y)'
  
cplx6 '(0,1)'
  
cplx '(re,im)'

  
addComplex
  «
    0  CP1 CP2 ans
    «
      delVars CP1 CP2 
'ans' STO
      cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
    »
  »

  subtractComplex
  «
    0  CP1 CP2 ans
    «
      delVars CP1 CP2 
'ans' STO
      cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
    »
  »

  multiplyComplex
  «
    0  CP1 CP2 ans
    «
      delVars CP1 CP2 
'ans' STO
      cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
    »
  »

  negativeComplex
  «
    0  CP1 ans
    «
      delVars CP1 NEG 
'ans' STO
      cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
    »
  »

  invComplex
  «
    0  CP1 ans
    «
      delVars
      
IF
        
CP1 RE IP 0. SAME
        CP1 IM IP 0. SAME 
AND
      
THEN
        
"Undefined, complex number must be nonzero" DUP MSGBOX
      
ELSE
        
CP1 INV 'ans' STO
        cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
      END
    »
  »

  divComplex
  «
    0  CP1 CP2 ans
    «
      delVars
      
IF
        
CP2 RE IP 0. SAME
        CP2 IM IP 0. SAME 
AND
      
THEN
        
"Undefined, the complex number of the divisor must be nonzero" DUP MSGBOX
      
ELSE
        
CP1 CP2 'ans' STO
        cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
      END
    »
  »

  scalarMulCplx
  «
    0  CP1 scl ans
    «
      delVars
      scl 
EVAL 'scl' STO
      cplx 
're' CP1 RE scl * EVAL = SUBST 'im' CP1 IM EVAL scl * = SUBST

    »
  »

  scalarMulCplx
  «
    0  CP1 scl ans
    «
      delVars
      scl 
EVAL 'scl' STO
      cplx 
're' CP1 RE scl / EVAL = SUBST 'im' CP1 IM EVAL scl / = SUBST

    »
  »

  absComplex
  «
     CP1
    «
      delVars
      CP1 RE 
EVAL CP1 IM EVAL ^ + ƒ
    »
  »


  argComplex
  «
     CP1
    «
      delVars
      RAD CP1 ARG
      IFERR NUM 
'1_°' CONVERT QPI
      THEN
      END
    »
  »


  conjComplex
  «
    0  CP1 ans
    «
      delVars CP1 CONJ 
'ans' STO
      cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
    »
  »

  simplifyComplex
  «
     0  CP1 ans
    «
      delVars CP1 
EVAL 'ans' STO
      cplx 
're' ans RE EVAL = SUBST 'im' ans IM EVAL = SUBST
    »
  »

  delVars
  «
    
xyx1x2y1y2 PURGE
  »

  Demo0
  «

     CLEAR

    
'(x1, y1)' negativeComplex '(-x1, -y1)'

    '(x1, y1)' '(x2, y2)' 
addComplex '(x1+x2, y1+y2)'

    '(x1, y1)' '(x2, y2)' 
subtractComplex '(x1-x2, y1-y2)'

    '(x1, y1)' '(x2, y2)' 
multiplyComplex '(x2*x1-y2*y1, y2*x1+y1*x2)'

    '(x1, y1)' '(x2, y2)' 
divComplex '( (x2*x1+y2*y1)/(x2^2+y2^2), -((y2*x1-y1*x2)/(x2^2+y2^2)) )'

    '(x1, y1)' 
invComplex '( x1/(x1^2+y1^2), -y1/(x1^2+y1^2) )'

    '(x, y)' 
simplifyComplex '(x^2-y^2, 2*y*x)'

    '(x, y)' 
absComplex 'ƒ(x^2+y^2)'

    '(3, 4)' 
absComplex 5

    
'(3, 4)' argComplex '53.1301023542_°'

    '(3, 4)' 
conjComplex @ (3, -4)
  
»

  Demo1
  «


    
'(x1, 0)' '(x2, 0)' addComplex '(x1+x2, 0)'
    '(x1, 0)' '(x2, 0)' 
subtractComplex @  '(x1-x2, 0)'
    '(x1, 0)' '(x2, 0)' 
multiplyComplex '(x2*x1, 0)'
    '(x, 0)' '(0, y)' 
addComplex  '(x, y)'
    '(0, 1)' '(y, 0)' 
multiplyComplex '(0, y)'
    '(x, 0)' '(0, 1)' '(y, 0)' 
multiplyComplex addComplex '(x, y)'
    '(x, 0)' 
'(y, 0)' multiplyComplex addComplex  '(x, y)'
    '(x, 0)' '(x, 0)' 
multiplyComplex '(x^2, 0)'
    '(x, y)' '(x, y)' 
multiplyComplex '(x^2-y^2, 2*y*x)'

    '(x, y)' 
simplifyComplex '(x^2-y^2, 2*y*x)'
    '(x, y)' 
^  simplifyComplex '(x^3-3*y^2*x, 3*y*x^2-y^3)'
    '(0, 1)' 
simplifyComplex '(-1, 0)'
    '-(x, y)' 
simplifyComplex '(-x1, -y1)'


    '(x, y)' '(0, 0)' 
addComplex '(x, y)'
    '(x, y)' '(1, 0)' 
multiplyComplex  '(x, y)'
    '(x, y)' '-(x, y)' 
addComplex  '(0, 0)'

    '(x1, y1)' '(x2, y2)' 
negativeComplex addComplex '(x1-x2, y1-y2)'
    '(x1, y1)' '(x2, y2)' 
invComplex multiplyComplex '((x2*x1+y2*y1)/(x2^2+y2^2), -((y2*x1-y1*x2)/(x2^2+y2^2)))'

    '(x, y)' 
argComplex 'ATAN(y/x)+(1-x/ABS(x))*(‡/2)'
    '(x, y)' 
conjComplex '(x, -y)'
    'i^2' 
simplifyComplex @ (-10)

    
'(x, y)' '(x, y)' conjComplex multiplyComplex '(1, 0)'

    '(3, -2)' '(3, -2)' 
conjComplex multiplyComplex '(13, 0)'

    '(4, 5)' '(3, -2)' 
conjComplex multiplyComplex '(3, -2)' '(3, -2)' conjComplex multiplyComplex  scalarMulCplx '(2/13, 22/13)'
    '(4, 5)' '(3, -2)' 
divComplex '(2/13, 23/13)'

    '(4, 5)' 
3 scalarMulCplx '(4, 5)' '-2*i' scalarMulCplx addComplex  '(22, 7)'



  
»


  Demo2
  «

    
'(2/13, 3/13)' '(1/2, -1/2)'  multiplyComplex '(5/26, 1/26)' -> 1/(2,-3) * 1/(1,1)
    
'(x1, y1)' '(x2, y2)' addComplex 2 simplifyComplex '(x1^2+2*x2*x1+(x2^2-(y1^2+2*y2*y1+y2^2)),  (2*y1+2*y2)*x1+(2*y1+2*y2)*x2)'
    '(-3, 2)' 
absComplex (14absComplex < @ true
    
'(3, 3)' argComplex '45_°'
    '(3, 4)' 
argComplex '53.1301023542_°'
    '(3, -4)' 
argComplex '-53.1301023542_°'
    '(-3, -4)' 
argComplex '-126.86_°'
    '(-3, 4)' 
argComplex '126.86_°'
    '(3, 4)' 
conjComplex @ (3, -4)
    
'(3, 4)' conjComplex conjComplex @ (34)
    
'(x1, y1)' '(x2, y2)' addComplex conjComplex '(x1+x2, -(y1+y2))'
    '(x1, y1)' 
conjComplex '(x2, y2)' conjComplex addComplex '(x1+x2, -(y1+y2))'
    '(x1, -y1)' '(x2, -y2)' 
addComplex  '(x1+x2, -(y1+y2))'



  
»

  Demo3
  «
    
(3,4) (1,1addComplex
    
'(3.68201941381+1.56292451396*i)' '(5+7*i)' multiplyComplex
    
'(4,€23)_°' '(5+7*i)' multiplyComplex
    
'(3, 0)' invComplex '(.333333333333,0.)'
    '(0, 4)' 
invComplex '(0.,-.25)'
    '(0, 0)' 
invComplex
  »


  Demo4
  «

   
(-32absComplex (14absComplex < @ true
    
(33argComplex 45_°
    
(34argComplex 53.1301023542_°
    
(3, -4argComplex @ -53.1301023542_°
    
(-3, -4argComplex @ -126.86_°
    
(-34argComplex 126.86_°
    
(34conjComplex @ (3, -4)
    (
34conjComplex conjComplex @ (34)



  
»



END

'cplx' STO cplx Demo4 
Visit this user's website Find all posts by this user
Quote this message in a reply
03-16-2017, 10:11 PM (This post was last modified: 03-16-2017 10:14 PM by Claudio L..)
Post: #2
RE: NewRPL: Complex Numbers in Cartesian Form
(03-16-2017 03:47 AM)compsystems Wrote:  Hello, sorry for my bad English

The Book "Complex Variables and Applications - James Ward Brown, Ruel ..."
Shows in your introductory part operations of complex numbers in cartesian form, I am replicating this in a library (HP-50), I would like to see this notation in NEWRPL, in addition to the phasor form (Widely used in Electrical and Electronic engineering)

Complex numbers are already implemented, but if you mean having the complex numbers written like (a,b) within a symbolic, there's a whole lot of syntax issues that arise from the use of parenthesis to separate the ordered pairs.
I started working on the modifications to the parser to allow this, but I never finished and got stuck with parsing problems, so it's still in the todo list.
I'm not sure it's a good idea since it gets confused with a function call (there's a reason the 50g doesn't allow it), but perhaps we could have a function C(re,im) that constructs a complex number. Then the syntax would be consistent and algebraic rules can be added to operate with the arguments of these functions:
C(a,b)+C(c,d)->C(a+c,b+d)
and so on for all other operators.
If this is OK, then the parser doesn't need to be touched, only the function C needs to be added.
However, when working with algebraic expressions it's always best to use 'x+i*y' format. I'll have to think about this more in depth to see how the pieces would fit together.

EDIT: I guess a flag could determine if you want a complex number in an expression to be decompiled as 'x+i*y' or 'C(x,y)'.
Find all posts by this user
Quote this message in a reply
03-17-2017, 03:20 AM
Post: #3
RE: NewRPL: Complex Numbers in Cartesian Form
I am not particularly sold on the benefits of being able to enter a "symbolic complex expression." For the same reason that multiplication should always be explicitly required, I believe that symbolic complex expressions should be entered as a+i*b; note here that I did not state that a and b had to be real values! This form merely factors out an 'i' wherever it is known to be an explicit factor.

In both cases (implicit multiplication and symbolic (a,b) form), there are too many ambiguous cases. I will just provide one example for each case... For implicit multiplication, should x(a+1) be x*(a+1) or should it be considered the evaluation of a function named x at an input of a+1? For complex expressions, how does one interpret x*(a,b)? Is that a scalar x multiplied with the complex number a+i*b? How would we know that x isn't itself a complex variable? If (hypothetically) x=(c,d)=c+i*d, then clearly x*(a,b) = (x*a, x*b) would be wrong because x*a would not be a real-valued expression. On the other hand, if x is a real number, then (x*a,x*b) would be exactly right. Even the expression (a,b) itself would be ambiguous. What if someone later stores c+i*d into a... then (a,b) would make no sense -- prior to storing anything into a, the real part of (a,b) would be a. On the other hand, as soon as we store c+i*d into a, then the real part of (a,b) is no longer a. Then there is the question of whether (a,b) should be a complex, symbolic type, or its own type? And which "type" has priority? I.e. given that there are already complex and symbolic type, when a user types in (a,b) should it be parsed as a symbolic object, or complex object? Just this question alone is a difficult programming problem in my opinion.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
03-17-2017, 04:08 PM (This post was last modified: 03-17-2017 04:17 PM by The Shadow.)
Post: #4
RE: NewRPL: Complex Numbers in Cartesian Form
I've always been a little dubious of using parentheses for complex numbers. For one thing, ordered pairs have plenty of other uses, which don't necessarily multiply in the complex manner. (Or even multiply at all.)

For that reason and others, I'd support using C(re, im) even on the stack. Or just always using the a+b*i form.

EDIT: Oh, and while we're on the topic, how about a system variable or flag to change what i^2 evaluates to? +1 for split-complex, 0 for dual.

And as long as I'm howling for the moon, how about adding complex j and k, so we can do quaternions? These could also perhaps be modified like i above, giving a wide range of capabilities. (Heck, you could store everything about i, j, and k in a single 3x3 matrix representing the multiplication table.)

Not gonna ask for octonions, though. Smile They make my head hurt.
Find all posts by this user
Quote this message in a reply
03-18-2017, 11:38 AM (This post was last modified: 03-18-2017 12:03 PM by Vtile.)
Post: #5
RE: NewRPL: Complex Numbers in Cartesian Form
(03-17-2017 04:08 PM)The Shadow Wrote:  I've always been a little dubious of using parentheses for complex numbers. For one thing, ordered pairs have plenty of other uses, which don't necessarily multiply in the complex manner. (Or even multiply at all.)

For that reason and others, I'd support using C(re, im) even on the stack. Or just always using the a+b*i form.

EDIT: Oh, and while we're on the topic, how about a system variable or flag to change what i^2 evaluates to? +1 for split-complex, 0 for dual.

And as long as I'm howling for the moon, how about adding complex j and k, so we can do quaternions? These could also perhaps be modified like i above, giving a wide range of capabilities. (Heck, you could store everything about i, j, and k in a single 3x3 matrix representing the multiplication table.)

Not gonna ask for octonions, though. Smile They make my head hurt.
Does the split-complex have any real world application or is it purely theoretical concept to study and derive further mathematical concepts. Interesting none the less.

It still rings some bells of admittance (circuit theory) behaviour like I first picked it up. Confused

What I have understood the quarternions are heavily used in 3D analyse and programming (or how you should describe it)?
Find all posts by this user
Quote this message in a reply
03-18-2017, 07:15 PM
Post: #6
RE: NewRPL: Complex Numbers in Cartesian Form
(03-17-2017 03:20 AM)Han Wrote:  I am not particularly sold on the benefits of being able to enter a "symbolic complex expression." For the same reason that multiplication should always be explicitly required, I believe that symbolic complex expressions should be entered as a+i*b; note here that I did not state that a and b had to be real values! This form merely factors out an 'i' wherever it is known to be an explicit factor.

In both cases (implicit multiplication and symbolic (a,b) form), there are too many ambiguous cases. I will just provide one example for each case... For implicit multiplication, should x(a+1) be x*(a+1) or should it be considered the evaluation of a function named x at an input of a+1? For complex expressions, how does one interpret x*(a,b)? Is that a scalar x multiplied with the complex number a+i*b? How would we know that x isn't itself a complex variable? If (hypothetically) x=(c,d)=c+i*d, then clearly x*(a,b) = (x*a, x*b) would be wrong because x*a would not be a real-valued expression. On the other hand, if x is a real number, then (x*a,x*b) would be exactly right. Even the expression (a,b) itself would be ambiguous. What if someone later stores c+i*d into a... then (a,b) would make no sense -- prior to storing anything into a, the real part of (a,b) would be a. On the other hand, as soon as we store c+i*d into a, then the real part of (a,b) is no longer a. Then there is the question of whether (a,b) should be a complex, symbolic type, or its own type? And which "type" has priority? I.e. given that there are already complex and symbolic type, when a user types in (a,b) should it be parsed as a symbolic object, or complex object? Just this question alone is a difficult programming problem in my opinion.

You completely got the picture. It's a mess and it's best to avoid it. However, I'm not sure yet there's a way to avoid the mess. For example a simple (innocent) expression like 'X+1' when X is the complex (a,b) replaces into the expression as '(a+i*b)+1', this means the complex number (a,b) would have to "convert" itself into a symbolic expression ('a+i*b') when EVAL is called within a symbolic. But how does EVAL know that X is being EVAL'ed within a symbolic expression or by itself in the stack?
Also, we have polar complex numbers, which would have to convert themselves to 'a*exp(i*b)', including the conversion of b from different angle systems to radians.
Perhaps we could avoid this conversion if we allow the complex object to live as a complex number inside the symbolic, perhaps simply with a "visual trick" that displays 'a+i*b' or 'a*exp(i*b*PI/180)' when decompiling the symbolic, but the object remains unchanged.
This has bad consequences when trying to simplify expressions, as the individual parts of the complex number won't be "seen" by the CAS, and also can't be separated unless the complex object number is broken in parts.

So it's a very complicated subject (I should say a *complex* subject).
Find all posts by this user
Quote this message in a reply
03-18-2017, 07:24 PM
Post: #7
RE: NewRPL: Complex Numbers in Cartesian Form
(03-17-2017 04:08 PM)The Shadow Wrote:  I've always been a little dubious of using parentheses for complex numbers. For one thing, ordered pairs have plenty of other uses, which don't necessarily multiply in the complex manner. (Or even multiply at all.)

For that reason and others, I'd support using C(re, im) even on the stack. Or just always using the a+b*i form.

EDIT: Oh, and while we're on the topic, how about a system variable or flag to change what i^2 evaluates to? +1 for split-complex, 0 for dual.

And as long as I'm howling for the moon, how about adding complex j and k, so we can do quaternions? These could also perhaps be modified like i above, giving a wide range of capabilities. (Heck, you could store everything about i, j, and k in a single 3x3 matrix representing the multiplication table.)

Not gonna ask for octonions, though. Smile They make my head hurt.

Actually, quaternions only have one challenge: make sure the CAS supports non-commutative multiplication.
You can define rules (which you can apply whenever you need to simplify the expressions), for ij=k, k^2=-1, etc., that would be covered.
But non-commutative multiplication is a challenge not only for quaternions, every time a variable in an expression contains a matrix or vector, how does the machine know that it's supposed to use non-commutative multiplication?
For example the expression 'A*B+C' can be manipulated in many ways by a CAS, but the CAS has no way of knowing that A and B are matrices, so how do we tell the CAS:
* If the variable is real (REALASSUME)
* If the variable is complex
* If the variable is a matrix
It seems this property should be embedded somehow in the expression, to help solvers and the CAS make the right decisions.

More and more to think...
Find all posts by this user
Quote this message in a reply
03-21-2017, 02:06 PM
Post: #8
RE: NewRPL: Complex Numbers in Cartesian Form
(03-18-2017 07:24 PM)Claudio L. Wrote:  Actually, quaternions only have one challenge: make sure the CAS supports non-commutative multiplication.
You can define rules (which you can apply whenever you need to simplify the expressions), for ij=k, k^2=-1, etc., that would be covered.
But non-commutative multiplication is a challenge not only for quaternions, every time a variable in an expression contains a matrix or vector, how does the machine know that it's supposed to use non-commutative multiplication?
For example the expression 'A*B+C' can be manipulated in many ways by a CAS, but the CAS has no way of knowing that A and B are matrices, so how do we tell the CAS:
* If the variable is real (REALASSUME)
* If the variable is complex
* If the variable is a matrix
It seems this property should be embedded somehow in the expression, to help solvers and the CAS make the right decisions.

More and more to think...

I was pondering this myself. The simple-but-ugly way would be to define a new operator for matrix multiplication, and another for anticommutative (ie, quaternion) multiplication. This would definitely work, but it feels unsatisfactory.

It's not without precedent in RPL, though. Witness the DOT and CROSS commands. Hmm. The cross product is also anticommutative, maybe it could be repurposed to handle quaternions too?

It's a pity that Hamilton accidentally defined the quaternions as a left-handed system! Speaking of which, find an elegant way to do Clifford algebras in newRPL, and I'll love you forever! I've been limping along with matrix representations...

Hey, now there's a thought! How about implementing Clifford's geometric product? You'd get quaternion multiplication and cross products basically for free, along with plenty more stuff! The only annoying part would be deciding how to represent bivectors, trivectors, and the like in RPL, and how to store the signature of the space you're using.

Maybe a fixed signature would be best if you chose to go this route, but what should it be? 4d Euclidean? Spacetime? Or *sob*, just 3d Euclidean? Even that would be a marked increase in power.
Find all posts by this user
Quote this message in a reply
03-27-2017, 04:28 AM (This post was last modified: 03-27-2017 04:29 AM by The Shadow.)
Post: #9
RE: NewRPL: Complex Numbers in Cartesian Form
(03-18-2017 11:38 AM)Vtile Wrote:  Does the split-complex have any real world application or is it purely theoretical concept to study and derive further mathematical concepts. Interesting none the less.


They do! Just like complex numbers encode rotations, split-complex numbers encode Lagrange-style "boosts" - essentially accelerations in special relativity. There's even two null lines in the split-Argand plane corresponding to the speed of light.

They also are to hyperbolae what complex numbers are to circles. They basically describe 1+1 Minkowski spacetime. (To get up to 3+1 like our universe requires Clifford algebra.)

My interest in them is *mostly* mathematical, though.

Quote:What I have understood the quarternions are heavily used in 3D analyse and programming (or how you should describe it)?

Quaternions encode 3d (and 4d) rotations, and do so much better than most of the alternatives in computer programming.

Though again, my own interest in them is primarily mathematical. I'm fascinated by the Hurwitz integers, the quaternion equivalent of whole numbers. I've programmed my 50g to handle them, but it's a bit cumbersome. Still haven't managed to factor them automatically.
Find all posts by this user
Quote this message in a reply
03-27-2017, 06:50 AM (This post was last modified: 03-27-2017 06:50 AM by Han.)
Post: #10
RE: NewRPL: Complex Numbers in Cartesian Form
(03-18-2017 07:15 PM)Claudio L. Wrote:  
(03-17-2017 03:20 AM)Han Wrote:  I am not particularly sold on the benefits of being able to enter a "symbolic complex expression." For the same reason that multiplication should always be explicitly required, I believe that symbolic complex expressions should be entered as a+i*b; note here that I did not state that a and b had to be real values! This form merely factors out an 'i' wherever it is known to be an explicit factor.

In both cases (implicit multiplication and symbolic (a,b) form), there are too many ambiguous cases. I will just provide one example for each case... For implicit multiplication, should x(a+1) be x*(a+1) or should it be considered the evaluation of a function named x at an input of a+1? For complex expressions, how does one interpret x*(a,b)? Is that a scalar x multiplied with the complex number a+i*b? How would we know that x isn't itself a complex variable? If (hypothetically) x=(c,d)=c+i*d, then clearly x*(a,b) = (x*a, x*b) would be wrong because x*a would not be a real-valued expression. On the other hand, if x is a real number, then (x*a,x*b) would be exactly right. Even the expression (a,b) itself would be ambiguous. What if someone later stores c+i*d into a... then (a,b) would make no sense -- prior to storing anything into a, the real part of (a,b) would be a. On the other hand, as soon as we store c+i*d into a, then the real part of (a,b) is no longer a. Then there is the question of whether (a,b) should be a complex, symbolic type, or its own type? And which "type" has priority? I.e. given that there are already complex and symbolic type, when a user types in (a,b) should it be parsed as a symbolic object, or complex object? Just this question alone is a difficult programming problem in my opinion.

You completely got the picture. It's a mess and it's best to avoid it. However, I'm not sure yet there's a way to avoid the mess. For example a simple (innocent) expression like 'X+1' when X is the complex (a,b) replaces into the expression as '(a+i*b)+1', this means the complex number (a,b) would have to "convert" itself into a symbolic expression ('a+i*b') when EVAL is called within a symbolic. But how does EVAL know that X is being EVAL'ed within a symbolic expression or by itself in the stack?
Also, we have polar complex numbers, which would have to convert themselves to 'a*exp(i*b)', including the conversion of b from different angle systems to radians.
Perhaps we could avoid this conversion if we allow the complex object to live as a complex number inside the symbolic, perhaps simply with a "visual trick" that displays 'a+i*b' or 'a*exp(i*b*PI/180)' when decompiling the symbolic, but the object remains unchanged.
This has bad consequences when trying to simplify expressions, as the individual parts of the complex number won't be "seen" by the CAS, and also can't be separated unless the complex object number is broken in parts.

So it's a very complicated subject (I should say a *complex* subject).

I imagine that creating a new object type (library) -- perhaps "symbolic complex" -- would be the "least complex" approach rather than to try to overload the current complex number object.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
03-27-2017, 01:31 PM (This post was last modified: 03-27-2017 01:35 PM by Claudio L..)
Post: #11
RE: NewRPL: Complex Numbers in Cartesian Form
(03-27-2017 06:50 AM)Han Wrote:  I imagine that creating a new object type (library) -- perhaps "symbolic complex" -- would be the "least complex" approach rather than to try to overload the current complex number object.

Do you mean an object that holds 2 symbolic expressions? Then we'd have to move terms that from one symbolic expression to the other depending on whether they have an 'i' or not?

If we were to create such object, then it should be generic: like a vector with N symbolic expressions, where the first column is always the real part, and each column has an associated complex unit vector (i,j,k...).
Operations would be defined as vectors, but at the end, the terms would have to be analyzed looking for the unit vectors i,j,k, and their products, then move terms from one expression to the others based on what we believe the result should be (???).
For example:
| 'x+1' , 'x/2' | could be such a vector.

Then if 'x' is 'a+b*i', the replacement would become:
| 'a+b*i+1' , '(a+b*i)/2' |
and the system would have to (automatically?) move the terms, knowing that i^2=-1:
| 'a+1-b/2' , 'a/2' |

However, this doesn't quite work because 'a' or 'b' could also be complex.
Questions arise:
How do we provide the "rules" for the complex unit vectors? are they fixed in the system or the user should be able to define them freely?

Perhaps instead of creating a new object, this should be an optional "pretty print-like" display for symbolic expressions.
Internally, the expression is still one single symbolic expression with a sum of terms. This way the CAS would process the expression normally, then the automatic simplification step would have to apply the algebra rules (i^2=-1, i*j=...) and finally factor the symbolic complex units out of the terms, then group them together:
(r1+r2+r3)+i*(im1+im2+im3)+j*(jm1+jm2+jm3...)

That pre-processing would remove the CAS work out of the compiler, which would simply (decompile and) display each group of terms as a separate expression in vector form:

| (r1+r2+r3) , (im1+im2+im3) , (jm1+jm2+jm3...) |

Still, this doesn't answer how a complex number would "expand itself" into the complex expression upon EVAL.
Find all posts by this user
Quote this message in a reply
04-10-2017, 12:40 AM (This post was last modified: 04-17-2017 12:28 AM by compsystems.)
Post: #12
RE: NewRPL: Complex Numbers in Cartesian Form
Edited:

Idea in new post:
http://www.hpmuseum.org/forum/thread-8160.html
Visit this user's website Find all posts by this user
Quote this message in a reply
04-13-2017, 03:55 AM
Post: #13
RE: NewRPL: Complex Numbers in Cartesian Form c[x,y] , ...
This is only tangentially related to the topic, but may I recommend that if you intend to insert pictures that they are resized so that users may click on them if they want to view a larger version? Or perhaps even better just supply the link. A large number of your posts are extremely difficult to read due to these large pictures being inserted throughout your text.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
Post Reply 




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