newRPL: The complexity of complex mode

08192016, 03:44 PM
Post: #1




newRPL: The complexity of complex mode
For a while I've been stuck implementing "proper" support for special numbers in complex mode. Now I'm wondering if it's worth the effort, as the number of different cases is making things complicated to handle, and other systems don't seem to need this complication.
So here's what I did, open for debate:
The complexity comes from having to implement operations between all these types of entities. Then there's arbitrary decisions to be made about when to return different types of infinities. For example, a division by zero between 2 reals when complex mode is disabled should return +/ real infinity. However, when complex mode is active, any division by zero (be it a real or a complex divided by zero) should return complex undirected infinity. Then, there's what to do with some special complex numbers as below, should they be allowed to exist? (Inf,0) = Real +Inf (Inf,0) = Real Inf but it's actually malformed, as directed infinity in complex mode has to be in polar more, should be (Inf ∡180°) (Inf,3) = Same as real Infinity? the angle tends to ∡0° if you look at it in polar mode (0,Inf) = Malformed, should be (Inf ∡90°) (0,Inf) = Malformed, should be (Inf ∡90°) (3,Inf) = (Inf ∡90°)?? (Inf,Inf) = Undirected infinity? And... there's operating on all of them, detecting them, converting to polar, etc. There's quite a few cases here: http://functions.wolfram.com/Constants/C...owAll.html Is all these necessary? Is there a simpler complex way? 

08212016, 06:46 AM
Post: #2




RE: newRPL: The complexity of complex mode
Whenever I have encountered infinities in what I've done it has always been in the context of some sort of limiting process. A CAS needs to handle such limits correctly but a "simple" calculator does not. The answer to any division by zero depends on how the limit is approached. I'd be happy with just infinity or even just an overflow for all nonCAS operations.
Can anyone think of any exceptions? Nigel (UK) 

08222016, 12:45 AM
Post: #3




RE: newRPL: The complexity of complex mode
(08212016 06:46 AM)Nigel (UK) Wrote: Whenever I have encountered infinities in what I've done it has always been in the context of some sort of limiting process. A CAS needs to handle such limits correctly but a "simple" calculator does not. The answer to any division by zero depends on how the limit is approached. I'd be happy with just infinity or even just an overflow for all nonCAS operations. In my field too, if you hit a NaN or infinity it pretty much means something went wrong, and it's the end of your calculations. I guess the question is if newRPL is a "simple" calculator. It will (or may) have a CAS in the future, but that's relatively far in the future. Ideally, this future CAS should fit like a glove in the newRPL environment, to avoid having Home and CAS as separate modes (ring a bell?). In that regards, newRPL should handle infinities consistently from the first day. But in my limited knowledge and usage pattern, I don't know of any case where it would be useful to get a directed infinity as a result, for example. I'd like for somebody to give an example or something, just to get my head around the idea. 

08222016, 03:03 PM
Post: #4




RE: newRPL: The complexity of complex mode
A directed infinity might appear as:
I suggest two types of infinity  complex infinity, and directed infinity \(\infty\). Directed infinity satisfies the following rules:
These rules, I think, agree with everything in your first post. Going through your list of examples:
Does this help? Nigel (UK) 

08232016, 07:43 PM
Post: #5




RE: newRPL: The complexity of complex mode
(08222016 03:03 PM)Nigel (UK) Wrote: Does this help? The first part of your post really helped. Later you suggested we don't need to take care of this, but then you go into details on how every operation should be handled, so I'm exactly as I was before. Lots of special cases to take care of on every operation, and I'm still not sure if it's needed or not. But once we allow directed infinities to exist (and for a future CAS this should be the case), we are forced to define a result for each operator, on each special case. Some cases like (+∞,3) or (∞,∞) could be rejected as syntax error to enforce some discipline on the user and reduce the number of cases. 

08242016, 10:32 AM
Post: #6




RE: newRPL: The complexity of complex mode
(08232016 07:43 PM)Claudio L. Wrote:(08222016 03:03 PM)Nigel (UK) Wrote: Does this help? I see what you mean about my previous post! I got a little carried away. Because operators like "+" and "x" are already overloaded, I assumed that adding a new behaviour for a new object type would not be a problem. The simplifications such as \((3,2\times\infty)\) becoming \(\infty\angle{\pi\over2}\) would be handled by whatever code is called to evaluate this new object type. However, I believe that all operations on directed infinities could be disallowed without loss. Those few operators that need them as input (e.g., limits and integrals) could look for them explicitly and provide their own means of dealing with them. Allowing only the angle notation (i.e., \(\infty\angle {\pi\over2}\) and not \((0,\infty)\)) would reduce the number of cases to consider and would not be a problem for the user. Perhaps it would be nice to allow \(\infty, \;\infty, \;i\infty, \;i\infty\) as equivalent notation for \(\infty\angle0,\;\infty\angle\pi,\;\infty\angle{\pi\over2},\;\infty\angle{}{\pi\over2}\). Nigel (UK) 

08242016, 04:06 PM
(This post was last modified: 08252016 12:37 AM by Vtile.)
Post: #7




RE: newRPL: The complexity of complex mode
(08232016 07:43 PM)Claudio L. Wrote: Some cases like (+∞,3) or (∞,∞) could be rejected as syntax error to enforce some discipline on the user and reduce the number of cases. Hold on, this complex infinities goes partially beyond my knowledge (i don't understand the directed infinity), but (+∞,3) did take my attention. PS. Now when I have spend too much time front of my computer rewriting this post, I think that the directed infinities are (lossy) polar representations. It all boils down calculating the Theta with the some rules of the complex plane (or trigonometric sections of the circle). This can be seen when we transform complex number \(Z=(\infty,3)=\infty + j3 \) to polar notation of \(\left  Z \right  \angle \theta ^{\circ}\) = \(\sqrt{a^2+b^2}\angle ATan(\frac{b}{a})^{\circ}=\sqrt{a^2+b^2}\angle ACot(\frac{a}{b})^{\circ}\), with the values we get \(\left  Z \right  = \sqrt{a^2+b^2} = \infty\) , when a (.. or b) approaches infinity \(\theta = ArcTan(\frac{b}{a}) = ArcTan(\frac{0}{\infty}) = ArcCot(\frac{\infty}{0}) = 0\) => \(\infty \angle 0^{\circ}\) and because we were dealing with positive infinity of real part the theta is indeed 0 degrees (or should it be \(\theta = 2^{\infty}\) hehe). Now suddenly we can not return back since.. \( \begin{align*} & a = Cos(\theta^{\circ})*\left  Z \right  = Cos(0^{\circ})*\left  \infty \right  = 1 *\infty =\infty\\ & b = Sin(\theta^{\circ})*\left  Z \right = Sin(0^{\circ})*\left  \infty \right  = 0 *\infty = 0 (\neq 3) \end{align*}\) Quote:(Inf,3) = Same as real Infinity? the angle tends to ∡0° if you look at it in polar modeIt can not be, the imaginary part stays as 3j even though in calculations when we took angle of it \(\theta = ArcTan(\frac{b}{a}) = ArcTan(\frac{0}{\infty}) = ArcCot(\frac{\infty}{0}) = 0), still in rectangular form it doesn't vanish anywhere it just loose its purpose in practical calculation, since we can not use it for calculating an real angle of it since we do not have enough paper and the effects compared to the real component lost it importance. So how I understand this "directed infinity" is that it is "partially continuous" and we should keep attention in which sector in im / re plane it stays. Then it can be expressed with the "nonlossy" rectangular (complex plane) form. How I have understood the polar form is that it is "just a techical simplification" of complex system to avoid the polynomial calculation when adding and multiplying (with sliderule). Partially related history snippet: The notation Z∡θ instead of Z*e^iθ did come to use somewhere at the first half of the 20th century (I have one book from 40s..50s era or so that mentions it as a new spreading notation in (atleast) electrical engineering). Quote:(0,Inf) = Malformed, should be (Inf ∡90°)Malformed why? Quote:(3,Inf) = (Inf ∡90°)??Comes from ArcTan. Quote:(Inf,Inf) = Undirected infinity?actually if a=inf and b=inf and inf=inf then it would be inf in angle of 45deg +n*90deg ??? Like said this subject is on the edge of my understanding / knowledge and partially over it. PPS. what comes to the question if NewRPL is simple calculator the answer is NO, it is not a calculator, but a mathematical environment. Sorry it is first and foremost your project at this moment so it is your decision in the end. PPPS. Interesting (new for me, I haven't studied it) and not entirely related is the spiral vector theory proposed by Sakae Yamamura (honored by IEEE atleast one time ), could be nice to understand it in the level that I could make a technically working library for it in the future for UserRPL & NewRPL. Let see starts to go too much to science for my interests. edit. change \(\theta = 1^{\infty}\) to \(\theta = 2^{\infty}\), jumping lately to number theory concepts is vaporising my calculus and magnifying my careless errors. 

08252016, 02:39 AM
Post: #8




RE: newRPL: The complexity of complex mode
(08242016 10:32 AM)Nigel (UK) Wrote: I see what you mean about my previous post! I got a little carried away. Because operators like "+" and "x" are already overloaded, I assumed that adding a new behaviour for a new object type would not be a problem. The simplifications such as \((3,2\times\infty)\) becoming \(\infty\angle{\pi\over2}\) would be handled by whatever code is called to evaluate this new object type.It's not a problem, just a lot of work. By the way, there's no new object type. The infinity symbol is a special real number object, same as NaN, not a new type. Along the same lines, undirected infinity can be generated by a division by zero between two reals when complex mode is on, so it's also a special real object. The reason is simple: The arbitrary precision library is a separate module, that handles numbers without knowing anything about objects, or any RPL concepts, and should be able to return those specials within the same data structures. Along the same line of thinking, complex directed infinity is a complex number object, so it is handled by the same library doing all complex operations. (08242016 10:32 AM)Nigel (UK) Wrote: However, I believe that all operations on directed infinities could be disallowed without loss. Those few operators that need them as input (e.g., limits and integrals) could look for them explicitly and provide their own means of dealing with them. Allowing only the angle notation (i.e., \(\infty\angle {\pi\over2}\) and not \((0,\infty)\)) would reduce the number of cases to consider and would not be a problem for the user. Perhaps it would be nice to allow \(\infty, \;\infty, \;i\infty, \;i\infty\) as equivalent notation for \(\infty\angle0,\;\infty\angle\pi,\;\infty\angle{\pi\over2},\;\infty\angle{}{\pi\over2}\). The thing is, the "classic" RPL environment always had a flag to disable the error message on infinite results. Using this flag together with complex mode means we are forced to produce a result, and I'd rather give the correct result than gibberish. Based on this I'm starting to convince myself there's no way to avoid this mess. Regarding notation, the infinity symbol means real infinity (+/). If the operations are correctly defined, when you use \( \;i\infty \) in a symbolic expression and run >NUM you'll get the proper complex result, as i = (0,1) and \(\infty\) = (\(\infty\angle0\) ). A multiplication properly defined would add the arguments 0 + \({\pi\over2}\) and return ( \(\infty\angle{\pi\over2}\) ). Then depending on the flag, this would throw an error "infinite result" or allow the program to keep running. It seems the only way to be able to return that result is to have properly defined each and every operation on all the different infinities, and between infinities and normal numbers. 

08252016, 03:09 AM
(This post was last modified: 08252016 03:11 AM by Claudio L..)
Post: #9




RE: newRPL: The complexity of complex mode
(08242016 04:06 PM)Vtile Wrote: Hold on, this complex infinities goes partially beyond my knowledge (i don't understand the directed infinity), but (+∞,3) did take my attention. You are getting the hang of it quite fast. Directed infinity is a point in the complex plane that's infinitely far from zero, going in a very specific direction. Therefore, I think the most appropriate representation is a polar complex number. A cartesian representation doesn't express the direction very well, should be something like this: \(\infty\times\)(0,3) but this is not parserfriendly, or screen friendly. (08242016 04:06 PM)Vtile Wrote: This can be seen when we transform complex number \(Z=(\infty,3)=\infty + j3 \) to polar notation of Yes, that's why I call it a "malformed" infinity. I think cartesian complex numbers involving infinity should not be allowed, or worst case allowed when typed by the user, but immediately converted to polar by the system. (08242016 04:06 PM)Vtile Wrote: So how I understand this "directed infinity" is that it is "partially continuous" and we should keep attention in which sector in im / re plane it stays. Then it can be expressed with the "nonlossy" rectangular (complex plane) form. I don't know why you call rectangular representation "nonlossy". You actually lose more information that way than in polar mode. (Inf,3) is fine, but what if it's at let's say 30 degrees? (Inf,Inf) doesn't tell you much, you'd have to have a full representation Inf*(\(\sqrt{3}\over{2}\),\(1\over2\) ), which now needs an infinity object + a complex number. The polar representation allows you to have directed infinity represented with magnitude and argument, just like any normal complex number, which makes it easier to handle. (08242016 04:06 PM)Vtile Wrote:Quote:(0,Inf) = Malformed, should be (Inf ∡90°)Malformed why? I think I covered this above: I think directed infinities should only be represented in polar form, therefore I call these forms "malformed". (08242016 04:06 PM)Vtile Wrote:Actually, inf=inf is not true. Two infinite quantities are not necessarily the same. For example, f(X)=2X as X tends to infinity is an infinity twice as large as g(X)=X when X tends to infinity (not sure if it makes sense with words), so there's Infinities that are greater than other infinities.Quote:(Inf,Inf) = Undirected infinity?actually if a=inf and b=inf and inf=inf then it would be inf in angle of 45deg +n*90deg ??? You can check by doing f(X)/g(X) when X tends to infinity: the limit is 2 proving that one infinity is bigger than the other. This all means we don't know the direction of (inf,inf), could be anything therefore it's undirected infinity. EDIT: Even though I sound like I knew this, I confess I learned this after the first post... (08242016 04:06 PM)Vtile Wrote: PPS. what comes to the question if NewRPL is simple calculator the answer is NO, it is not a calculator, but a mathematical environment. Sorry it is first and foremost your project at this moment so it is your decision in the end. Actually, this is the paragraph that makes more sense of all the posts in this thread. I think you are right, and I'm inclining to implement all these details into newRPL even if it takes a lot of work. 

08282016, 12:21 AM
(This post was last modified: 08282016 12:27 AM by Vtile.)
Post: #10




RE: newRPL: The complexity of complex mode
I think we just reached the point where we need the Hyperreal numbers and Nonstandard calculus to calculate inf/inf? Which I found from wikipedia after your last post and find them really interesting and intuitive or atleast interesting.
Ok, lets forget that for now on. This goes offtopic I think. It seems I still get definition that says that ATan(inf/inf)=Pi/4 which is not defined (ie. in wolfram alpha), yet \( \mathit{z}=\infty*e^{\frac{i\pi}{4}}\) seems to be legit. This is what I have found most formal definition for complex number. \(\mathbb{C}=\left \{ \mathit{z} \mathit{z=a+bi,\:\: a,b\in \mathbb{R}} ,\:\: i^2=1 \right \} \) also from a few sources that when Im(z)=0 then the result is real number. Also it is said that infinity is part of the real number continuum and calculation rule for complex number is given that z1*z2=(a1,b1)(a2,b2)=(a1a2b1b2 , a1b2+b1a2) then \(\mathit{z}_{\infty }=\infty(a,b)=(\infty,0)(a,b)=(\infty*a0*b \; ,\; \infty*b+0*a)=(\infty*a \; ,\; \infty*b)=(\infty \; ,\; \infty) = \left \infty \right \angle \frac{\pi }{2}=\left \infty \right e^{\frac{\pi}{2} i}\) ..Back to topic. Yes, I thought the number system through the formal definition in the "rectangular form" \(\mathbb{C}=\left \{ \mathit{z} \mathit{z=a+bi,\:\: a,b\in \mathbb{R}} ,\:\: i^2=1 \right \} \) In the end the lossy representation is always the one that is not the one which is used through analysis. I also didn't consider enough the \(\mathit{z}_{\infty }=\infty(a,b) \; and \; \infty \in \mathbb{R}\) (with the rule of )and using the Eulers Formula as \(\mathit{z}_{\infty }=\infty(Cos(\theta),Sin(\theta))\) Interesting discussion, broadens ones thinking. What comes to the mathematical environment, you said it yourself I just reworded it. 

08282016, 06:33 PM
Post: #11




RE: newRPL: The complexity of complex mode
(08282016 12:21 AM)Vtile Wrote: It seems I still get definition that says that ATan(inf/inf)=Pi/4 which is not defined (ie. in wolfram alpha), yet \( \mathit{z}=\infty*e^{\frac{i\pi}{4}}\) seems to be legit. The above is precisely why I don't think rectangular representation is "lossless". You lost a lot of information the moment you distributed that infinity into each component of the complex (that operation is invalid, infinity doesn't distribute). If instead of Infinity you had X, the result would be the complex (X*a,X*b). The limit when X tends to infinity would keep the direction of (a,b) as X goes from 0 to infinity, hence the correct result is a vector of infinite length and the same direction of (a,b). This is easy to represent in polar coordinates, hard to do in rectangular. In polar coordinates, you can do the complex multiplication without applying the distributed property that doesn't work with infinity: \(\infty==>\infty*e^{i 0}\) \(Z ==> (a,b) ==> r * e^{i \theta}\) \(\infty*Z = \infty*r * e^{i(0+\theta)} = \infty * e^{i \theta}\) This is why it's best to store a directed infinity in polar form. 

« Next Oldest  Next Newest »

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