newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Claudio L.]

(06-03-2016 08:16 AM)JoJo1973 Wrote:  

(06-03-2016 02:21 AM)Claudio L. Wrote:  It could work, though I haven't thought about it in depth. So a complex infinity would be shown on the stack as (∞,∞)? Or perhaps it should be (∞, NaN), in other words: infinite magnitude, but unknown direction. Or perhaps it should be a polar complex? (∞, ∡0.5r).
In your example -∞ 4 XROOT the result is still infinity, but the result should actually be (∞, ∡45°).
Treating real -∞ as (-1,0)*∞ is a neat trick, but I'm not sure it has any real use. You could do the same by using a variable instead of infinity, operate to get the result you need, then take limit when it tends to infinity.

EDIT: Rephrasing and clarification

Well, (-1,0)*∞ was not intended by me as trick to manipulate infinite quantities, but just a way to represent them internally. On the stack the only thing the user should see is "+∞", "-∞" or "∞". For directed infinities, the polar notation (∞, ∡45°) is very expressive and compact; for rectangular notation one could display "(...)∞" (i.e. "(3-4i)∞").

I don't want to seem to push my own ramblings on your project (if I had the technical expertise I could at least contribute with code and not with words!) but, just for the sake of discussion, have you considered to give to infinities and NaN's the "angle treatment" i.e. promote them to full fledged objects?

After all:

1. They appear in multiple variants (real, complex, unsigned, directed)
2. They are argument of functions and can be returned as result of functions, sometimes unexpectedly (at least for me... complex analysis has never been my forte . Think for example at ACOS(-∞): Undefined in real domain, -i*∞ in the complex domain.
3. They combine with numeric types and operators in their peculiar ways: this page explains better than I could do the tricky relationships between infinities and NaN's.
4. Handling them in a library of their own, with overloaded operator supports should allow for concise coding and greater flexibility (e.g. NaN's could represent different indeterminate forms)
5. Being a separate class of objects could be advantageous for the CAS: substitution rules dealing with them could be easily written and managed
   

So much food for thought that I'm going to choke! Let's see...
If infinity is an object, what would the math library return when trying to divide 1 by 0 (which are reals)? Right now it simply marks the result with an infinity flag, because the only thing the decimal library can return is a real number. Object infinity would have to be handled 100% by higher level code (RPL library) as opposed to the decimal math library, including all special cases that could cause an infinity result, like TAN(∡90°). Right now in this example, the TAN function returns a real infinity, but the TAN code itself doesn't know anything about objects yet, it only deals with real numbers.
So having a separate object might not help the developer of newRPL libraries that much, as every new command would need to handle the various new special objects.

I think a simple way to represent it would be:
∞ (with or without the sign) = real infinity.
(∞, ∡0.3r) = Complex infinity (directed)

Since polar numbers stay polar in newRPL, Infinities don't need to be represented in cartesian form. However, this leaves one question: How to represent complex infinity in symbolic form?
The complex form (x,y) is not allowed in a symbolic expression (though right now due to bad handling of complex numbers, adding a complex to a symbolic actually displays it in (x,y) form, but that shouldn't be allowed). I think '(x+i*y)*∞' is the only way to properly represent it (a complex number times real infinite magnitude), so we could say that directed infinity is doable.
What about undirected infinity? I think there's no other way but to create a special symbol. Doesn't have to be a special object, though.
An undirected infinity can come out as a result of a divide by zero, so technically the decimal library should output an undirected complex infinity rather than a real infinity.
Thinking out loud, there's 2 flags on a real number: NAN and INF. What if we designate complex undirected infinity to a number that has BOTH flags up? It makes sense that it's infinity, but also undefined since it's direction in the complex plane is unknown.
It could be displayed with a special symbol, like ∞̅ which for some reason doesn't look good on this forum (Unicode Infinity with combining overline).
Yes, you could argue that doesn't make sense for complex infinity to be a real number... but it makes sense for a decimal library to be able to output complex infinity as a result of a real operation.
So in the end:
∞ (with or without the sign) = real infinity.
(∞, ∡0.3r) = Complex infinity (directed)
∞̅ = Undirected complex infinity (a real number w/some special flags).

This should be able to accomplish most of what you discussed without fundamentally changing existing code.
Undirected infinity should not be allowed inside a complex number though: (∞̅,0), (0,∞̅), (∞̅,∞̅) should be invalid.