So I “fixed” this, but think my fix is bad.
I changed the line that reads
esc(_parse_vars(:variables, Real, xs))
in variable.jl (i.e., line 332 in the version I got from git (during the first week of June)) to
esc(_parse_vars(:variables, Complex, xs))
and all the simple stuff started to work. Looking at the code I can see other areas where is seems that changing Real to Complex will be required, but it hasn’t shown up in the testing yet.
But I dislike this fix, because I imagine that if the system assumes all variables are complex, there will be things that don’t work when the user’s intent is that the variable is real.
In '96 & (part of) '97 I worked for Waterloo Maple Inc. I did numerical stuff, but was aware of lots of other activity going on in the lab(s). At that time much of their system implicitly assumed the domain was real for the purposes of solving and simplifying. At the time they were the most popular CAS for service math classes, like undergraduate calculus. Maple could do, without much fuss, most of the problems in many undergraduate courses. At the time, there was quite a bit of excitement about developing new CAS-centric curriculum.
But there was a steady trickle of bug reports where the user intended the domain to be complex and Maple produced a symbolic answer that was incorrect because it combined intermediate results that were from different branches of the complex plane. My since was that a consensus formed (within Maple) around the strategy of assuming complex domains and reporting answers from all the branches, with the idea that the user could figure out which solution they wanted or could add assumptions that would be respected by solve and simplify. At the time this seemed eminently sensible to me, and I can remember saying this was a good strategy.
Recently my daughter tried to use Maple in several of her undergraduate physics and math courses. Unlike 25 years ago I didn’t see problems with reporting a non-answer because of branch cut problems (though I didn’t test very hard). The problem was that Maple just didn’t give answers to many of the problems in the textbook, unless the user provided assumptions. I think this was mostly because it only performed operations that were valid in the assumed domain. I could usually figure out what I needed to tell the system to get an answer, but not having taken complex analysis she could not.
None of her professors were recommending the use of CAS in any of the courses. I doubt anyone in the CAS community would have predicted that 25 years ago. They must have experimented with and abandoned the use of CAS in the undergraduate curriculum. Is this an important part of why?
In retrospect maybe she would not have had issues if she had automatically specified that all symbols were real, at least when looking at problems in elementary courses … I could have automated this, wonder if that would have fixed the problem.
Maybe we should work on a list of examples that cause problems for “the everything is complex assumption”. Low order powers and integer roots of complex numbers can be handled with a little bookkeeping, but most interesting functions have infinitely many roots. For example ln(x)=y has infinitely many complex solutions. In this case the solutions are regular and could be represented as a set using some iterator notation. But the world of special functions is large, almost all of which lead to infinitely many solutions in some uses, and most of the time the set of solutions is not regular enough to handle with some improved (but hard to sell new) notation.
I think we need to allow the domain (type) of symbolic variables to be specified when they are declared. The machinery is there to do this …
Is this a near consensus opinion or controversial? This is not my area of expertise. I know enough to know that there are new CAS methods that I don’t know about …