One of the facts which I’ve pointed out in earlier postings was, that if I give the free Computer Algebra System (‘CAS’) named ‘Maxima’, a cubic equation to solve, as in, to find the exact analytical solutions to, it will fail to produce intelligible output, if the usage was naive.
More specifically, cubic equations exist that have 3 distinct, real, irrational roots, and which a ‘CAS’ should be able to solve, just because their general solution is publicly known. That solution boils down, to deriving a second cubic, which is called a ‘depressed cubic equation’, and then performing a trigonometric substitution. (:1)
A fact which I’ve also known for some time is that, especially if a person is using a free or open-source CAS, then in some cases its behaviour has not been made particularly user-friendly, in that work needs to be done by the user, to set up his or her problem for the ‘CAS’ to solve. This latter observation casts a shadow of doubt, over the question of whether a ‘CAS’ will ultimately lead experienced Mathematicians to new discoveries in Algebra, or whether this can only reduce the workload in certain situations.
In this posting I’m going to show, how ‘Maxima’ can be coerced into giving correct answers, by users who know how. What I tend to use is a Graphical Front-End to ‘Maxima’, that is itself named ‘wxMaxima’, but which has equal capabilities, except for the abilities to typeset its solutions, as well as to export its Worksheets to PDF as well as HTML format, using LaTeX.
The following embedded worksheet will only display properly in the reader’s browser, if
What’s observable here is the fact that the package ‘odes’ can be loaded, which is mainly used to solve Ordinary Differential Equations, and that afterwards, the function ‘solvet()’ can be used, even to solve certain polynomials – better than what Maxima can solve on its own, with the built-in ‘solve()’ function. (:3)
(Updated 6/14/2020, 0h30… )
(As of 6/10/2020: )
A “Depressed Cubic Equation” is one, the coefficient of the square within which is zero. Having to derive this from the original cubic equation is homologous to the operation with quadratics, of “Completing the Square“. When completing the square, a derived equation results, the first-order term of which is zero, and which leads to the general solution.
How clean the solution to a cubic is supposed to look, that is already a depressed cubic, all the roots of which are real, can be seen here:
cos(5 π / 9) == cos(13 π / 9) == cos( (1 ± (4/9)) π ) ~= -0.17364817767... cos(θ) == cos(-θ)
What some readers may have noticed could be, that similar embedded worksheets on my blog did not display correctly, when the blog was being viewed from a (secure) httpS:// URL. The reason this will happen is the fact that, like several other elements within my blog, those URLs were plain, non-secure URLs that had the domain-name of my blog within them, as well as the http:// prefix.
This is the first posting, in which I circumvented the issue, by no longer giving the full URL, but rather, giving a form of the URL that assumes an unchanged domain-name. Since I’m not trying to embed anybody else’s Web-page within my own, this gives no issues.
(Update 6/11/2020, 9h35: )
The question can arise, of whether the solutions that ‘solve()’ gave are even true, given that ‘solvet()’ gives entirely different ones. And the answer which I would give is, that the equations which ‘solve()’ output above, may in fact be true, but are also useless. And the reasons why the user should not use these types of ~solutions~ to a Math problem are twofold:
- They cannot be converted into a numeric answer, through a straightforward, linear series of computations. According to that, even to find
the real 9th rootof a real number constitutes a computation which people who have Scientific calculators can perform. The equation that ‘solvet()’ outputs actually states (9) times the square root of (5003). If that was a 9th root, wxMaxima would typeset it as an exponentiation to (1/9). And,
- The user cannot recognize whether each of the solutions which ‘solve()’ output, are in fact real, or whether they are ultimately complex.
Either of these two situations would be enough reason by itself, to reject the solutions which ‘solve()’ output in the above example. The solutions contain the symbol ‘%i’, which is the notation that Maxima uses for the imaginary constant. But, it could be that, because in each solution, that constant appears in two places or more, the eventual computation, aside from round-off errors, cancels the imaginary component. Or, it might not be, and the equations themselves could be false. The user has no way to know.
And, while multiplication and division with complex numbers are defined, they are also more complicated to carry out, even when using a Scientific calculator, than it is to compute the real,
9th root of a number that’s recognizably real, or, to compute the arctangent of a (visibly real) number, which leads to an angle in radians…
(Update 6/11/2020, 21h15: )
There’s another observation to make, about purported solutions to Math problems, that are ‘just useless’ in this way. I had posted about this elsewhere on my blog, but think this is a good place to bring it up again.
When complex solutions are allowed, the 3rd root of a number exists as a set of 3, that are actually positioned 120° apart in the complex plane. The 9 corresponding,
9th roots, are positioned 40° apart in the complex plane.
It’s a simplifying assumption often made that, either because the argument was real, or for other reasons, only the real solution is being asked for. In the case of any odd root of a real number, there should be exactly one.
However, as soon as the argument is already a complex number, this assumption can no longer be made.
What this means is that the ‘solve()’ function above, gave 3 solutions according to a template, but, each of which involves a complex root, of one complex term.
So, what ‘Maxima’ has done with this solver, is to output 3 solutions explicitly, as opposed to implicitly…
What I see is that, in one part of each solution where the cube root, or the power of (1/3) appears, the Maxima programmer multiplied by a term that takes the following form:
In so doing, he or she rotated the complex number possible within (H) by ±120° in the complex plane. But, when (H) appeared in a denominator, which can also be called a divisor, this rotation took place instead in the numerator, which can also be called the dividend. Therefore, the following question has been answered explicitly:
- Are they supposed to be switched in the same direction of (i) as the rotated version of (H)?
- Are they supposed to be switched in the opposite direction of (i)…
- Or, are they really
supposed to remain stationary?
When the reciprocal of a complex number is computed, and that complex number’s imaginary component becomes more positive, then the imaginary component of the reciprocal becomes more negative, and vice-versa. Hence, for this dividend to receive the opposite rotation, to that which the cube root received when not a reciprocal:
- Follows from the cube root itself being rotated the same way both times, and
- Increases the likelihood that the imaginary components could cancel, not once, but 3 times.
Because the solutions seem to give an explicit answer to this question, this actually lends plausibility to the idea, that even the solution given by ‘solve()’ might be true.
Further, this observation would also answer the question of, when a person is trying to compute numerical values, which out of 3 possible roots he should compute, every time that exponentiation to (1/3) took place. The answer would be: ‘It does not matter, as long as the choice is the same each time.’
(Update 6/13/2020, 18h45: )
This examination, of the answers which Maxima’s ‘solve()’ gave, to the first, more-difficult cubic equation, can be taken one step further. Again, on the assumption that all 3 roots must be real, and given the fact that ‘solvet()’ gave them, in the form of a constant, times two, times a cosine, Yes, the idea could be true, that this cosine is the real component of a complex number, taken twice, and that the imaginary component taken once, is the negative of the imaginary component taken the second time.
But, in order for that to be possible, what needs to be true as well is, that the absolute of the two complex roots, must be equal to whatever that constant was, as well as the need, for the absolute of the reciprocal which has been computed, to be equal to the same constant.
The following worksheet displays the result of this additional examination:
What the worksheet above, the third in this posting, concludes, is that the solution which ‘solve()’ originally gave, has survived yet-another test, and that It could still be true, and still be consistent with what ‘solvet()’ gave. And this conclusion is based on the additional observation, that when one divides a (real) constant by its own square root, one obtains the square root for a second time, that square root being, what was output by ‘solvet()’.
(Update 6/14/2020, 0h30: )
But then, that worksheet above also restates as another conclusion, what this posting started out to state.
In case the reader is wondering, what numerical approaches might exist, to compute the exponentiation of a complex base to some fractional power, the following might be seen as a guideline. However, ‘Maxima’ does not offer this as a built-in capability: