(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)

(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. They make my head hurt.

(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.

(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. They make my head hurt.

(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...

(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.

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

(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).

(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.