06-03-2016, 08:16 AM (This post was last modified: 06-03-2016 01:01 PM by JoJo1973.)
Post: #283
 JoJo1973 Member Posts: 111 Joined: Apr 2016
(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
 « Next Oldest | Next Newest »