Hello, @rogergun! This will be a little anticlimactic answer, but here we go. This problem that you point out is some of the annoyances of using SageMath. Like many other computer algebra systems (CAS) out there, Sage is not as "intelligent" (yes, I chose the word correctly) as a problem like this would require, so it needs the help of a human brain, which is intelligent enough. For example, in a Calculus book that my thesis advisor wrote, I could find a whole plethora of trigonometric limits that cannot be solved by SageMath, Mathematica and other CAS that I tried (unfortunately, I don't have access to Mathcad 6.) However, these limits can be solved by a human brain in no more than three steps applying some very simple trigonometric identities.
The problem you point out in your question is very annoying because it is so simple to solve for a human brain. Perhaps a future version of SageMath will be able to deal with such problems. However, always have in mind that even the most clever computer needs the human brain for one or another type of problem.
That being said, Sage is a very beautiful and useful system, and most of us, the users, tend to ignore such annoyances, given the insanely large list of benefits we find every day. I can suggest you a few ways to deal with this problem:
- Write your own solver for this type of equations. (This could require some advance knowledge of SageMath.)
- Open a ticket in Sage Trac requesting the addition of a feature like this.
- Use SymPy Gamma, a beautiful and very very, useful alternative to Wolfram Alpha. It is open source and free/libre/gratis, as SageMath is. For example, here is your problem solved in SymPy Gamma. You will notice that it gives you the real root and some of the complex roots (the solution set is infinite, as pointed out in @Emmanuel Charpentier's comment below.)
Since SymPy is excellent in solving symbolic equations, you can use it from SageMath itself. (This is the advantage of Sage being written in Python!) There are many ways to do this; I will give you one of them here:
from sympy import solve as sysolve
x = var('x')
sols = sysolve(8^(3*x)-16^(x+1), x)
The beauty of this is that you can leave to SageMath do the appropriate conversions for SymPy. For example, notice that 8^(3*x)-16^(x+1) is not in Python notation (in particular, ** should be used for exponentiation); also, strictly speaking, x is a Sage variable, not a SymPy symbol (which otherwise should be declared with sympy.symbols()). However, Sage's preparser takes care of these details for you. Alternatively, you can also replace the third line with
sols = sysolve(8**(3*x)-16**(x+1), x._sympy_())
where _sympy_() is a Sage method that converts an object to the adequate SymPy type.
This will return the same list of results as SymPy Gamma, including complex ones, which we don't want right now, so you can add this to your code:
for sol in sols:
if sol._sage_() in RR:
print(sol)
I have used the _sage_() method, which is an "opposite" of _sympy_(), in the sense that it converts a SymPy object to the adequate SageMath type. (Note that this method also converts types from other software to Sage's representation; for example from Mathematica, Maxima, Fricas, etc.) In Sage, RR is the notation for the real field.
Here is the complete code in SageCell.
Note: Sage has the syntax
sols = solve(8^(3*x)-16^(x+1), x, algorithm='sympy')
which should automatically call SymPy's solve method. Unfortunately, the result returned by SymPy is ConditionSet(x, Eq(2**(5*x) - 16, 0), Complexes), which Sage does not know how to convert back to its data types. (Perhaps this will also be fixed in a future version, since I seem to remember there are ongoing efforts to improve Sage-SymPy translations.)
I hope this helps!
