This is an old issue for me, but SHIFT+∠ does not format a result in a+bi form to polar form in CAS mode. It seems to only work in home.
Any ideas on how to fix that? If not possible, could you guys please include this functionality in the next firmware rev?
Thanks!
The problem boils down to the CAS does not have a complex object... while numerical world does. Thus it become a simple display flag toggle in HOME because it is a *single object* containing 2 numbers. This works great for numerical calculations that are more limited in scope.
So if you have something like "3+4i" you think, "well of course that is just a complex number, display it in polar".
Well how about 2+3a+4+5*i. What is the complex number? How about a+b*i. Is that a complex number? What is a has been assigned a matrix and i was redefined as a function variable? So then you have to start parsing things down and evaluating stuff, and it no longer becomes anything trivial anymore. Thus there is no such thing as a "complex number" object in the CAS, so handling special cases does not really work. You have commands like "rectangular_coordinates" and "polar_coordinates" but those start to split things into two object vectors to try and keep them "paired".
Unfortunately, symbolic calculations are inherently at odds with "number crunching" in far too many cases and there is not a good solution to unify all cases.
(06-25-2023 02:51 PM)Tim Wessman Wrote: [ -> ]The problem boils down to the CAS does not have a complex object... while numerical world does. Thus it become a simple display flag toggle in HOME because it is a *single object* containing 2 numbers. This works great for numerical calculations that are more limited in scope.
So if you have something like "3+4i" you think, "well of course that is just a complex number, display it in polar".
Well how about 2+3a+4+5*i. What is the complex number? How about a+b*i. Is that a complex number? What is a has been assigned a matrix and i was redefined as a function variable? So then you have to start parsing things down and evaluating stuff, and it no longer becomes anything trivial anymore. Thus there is no such thing as a "complex number" object in the CAS, so handling special cases does not really work. You have commands like "rectangular_coordinates" and "polar_coordinates" but those start to split things into two object vectors to try and keep them "paired".
Unfortunately, symbolic calculations are inherently at odds with "number crunching" in far too many cases and there is not a good solution to unify all cases.
Makes total sense, thanks for your reply!