NewRPL: Complex Numbers in Cartesian Form r[x,y] , ...

03162017, 03:47 AM
(This post was last modified: 04132017 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 (HP50), 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: %%HP: T(0)A(D)F(.); 

03162017, 10:11 PM
(This post was last modified: 03162017 10:14 PM by Claudio L..)
Post: #2




RE: NewRPL: Complex Numbers in Cartesian Form
(03162017 03:47 AM)compsystems Wrote: Hello, sorry for my bad English 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)'. 

03172017, 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 realvalued 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 

03172017, 04:08 PM
(This post was last modified: 03172017 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 splitcomplex, 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. They make my head hurt. 

03182017, 11:38 AM
(This post was last modified: 03182017 12:03 PM by Vtile.)
Post: #5




RE: NewRPL: Complex Numbers in Cartesian Form
(03172017 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.)Does the splitcomplex 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. What I have understood the quarternions are heavily used in 3D analyse and programming (or how you should describe it)? 

03182017, 07:15 PM
Post: #6




RE: NewRPL: Complex Numbers in Cartesian Form
(03172017 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. 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). 

03182017, 07:24 PM
Post: #7




RE: NewRPL: Complex Numbers in Cartesian Form
(03172017 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.) Actually, quaternions only have one challenge: make sure the CAS supports noncommutative 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 noncommutative 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 noncommutative 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... 

03212017, 02:06 PM
Post: #8




RE: NewRPL: Complex Numbers in Cartesian Form
(03182017 07:24 PM)Claudio L. Wrote: Actually, quaternions only have one challenge: make sure the CAS supports noncommutative multiplication. I was pondering this myself. The simplebutugly 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 lefthanded 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. 

03272017, 04:28 AM
(This post was last modified: 03272017 04:29 AM by The Shadow.)
Post: #9




RE: NewRPL: Complex Numbers in Cartesian Form
(03182017 11:38 AM)Vtile Wrote: Does the splitcomplex 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, splitcomplex numbers encode Lagrangestyle "boosts"  essentially accelerations in special relativity. There's even two null lines in the splitArgand 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. 

03272017, 06:50 AM
(This post was last modified: 03272017 06:50 AM by Han.)
Post: #10




RE: NewRPL: Complex Numbers in Cartesian Form
(03182017 07:15 PM)Claudio L. Wrote:(03172017 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. 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 

03272017, 01:31 PM
(This post was last modified: 03272017 01:35 PM by Claudio L..)
Post: #11




RE: NewRPL: Complex Numbers in Cartesian Form
(03272017 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+1b/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 printlike" 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 preprocessing 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. 

04102017, 12:40 AM
(This post was last modified: 04172017 12:28 AM by compsystems.)
Post: #12




RE: NewRPL: Complex Numbers in Cartesian Form  
04132017, 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 

« Next Oldest  Next Newest »

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