Re: [Maxima-discuss] Why can't Maxima solve 5^(3*x+2) = 7^(3*x+2) symbolically? PEBCAK or a limitation?

[Barton W. <wi...@un...>]

I tried the code in  all_exp_eq_solutions_v0.2.6.mac. Some comments:

When the solve variable is k, the result is an expression that has k with two meanings:

(%i7) complex(5^(3*k+2) = 7^(3*k+2),k);
(%o7) k=-((2*%i*%pi*k)/(3*log(7/5)))-2/3

When the base of the exponential isn't a constant, the result isn't wrong, but the equation isn't solved:

(%i8) complex(x^(3*x+2) = 7^(3*x+2),x);
(%o8) x=-((2*%i*%pi*k)/(3*log(7/x)))-2/3

The code assumes a very specific set of equations;  when  it isn't, the user gets a hard to understand error message:

(%i11)      complex(5^(3*x+2) + 1 = 7^(3*x+2),x);
pow_parts: expected a power a^e, got:  5^(3*x+2)+1

The function complex_report  uses simp as a local variable. But simp is a Maxima option variable—when it is false, Maxima doesn't simplify expressions, and much of Maxima will not work as expected.  Likely, you should name this local variable something else.

I hope these comments might help make your code better -- please keep us up on your efforts.

--Barton

________________________________
From: Barton Willis via Maxima-discuss <max...@li...>
Sent: Tuesday, March 3, 2026 4:54 PM
To: Karen Kharatian <kar...@gm...>; Max...@li... <max...@li...>; Matthias A. Steiner <mat...@we...>
Subject: Re: [Maxima-discuss] Why can't Maxima solve 5^(3*x+2) = 7^(3*x+2) symbolically? PEBCAK or a limitation?

Caution: Non-NU Email

Here is my solution—I'll look at your solution in a bit.  To try this for yourself,  you'll need a recent version of function_convert<https://urldefense.com/v3/__https://github.com/barton-willis/function_convert__;!!PvXuogZ4sRB2p-tU!FMbrqH-YRvzrsX9h2sfSEN4n_9x5027ib_10GK__W-SCVelqq8OEGnrkFdP3yeN-HBmfQSgppbdwlBiTA_FmWiv3UaVestz-Fw$>

(%i1) load(function_convert)$

Define a converter that standardizes the base of an exponential to %e.   The repeated "^" = standardize_base looks weird --- the second is an alias for the first:

(%i2) register_converter("^" = standardize_base, "^" = standardize_base, lambda([a,b], exp(b*log(a))));
(%o2) done

Standardize the base to %e:

(%i3) eq1: 5^(3*x+2) = 7^(3*x+2)$

(%i4) eq2 : function_convert("^" = standardize_base, eq1);
(eq2) %e^(log(5)*(3*x+2))=%e^(log(7)*(3*x+2))

And solve with to_poly_solve:

(%i5) load(to_poly_solve)$

(%i8) sol : %solve(eq2,x);
(sol) %union([x=-((2*%i*%pi*%z927+log(49/25))/log(343/125))])

Reset the pesky counter to zero:

(%i9) sol : nicedummies(sol);
(sol) %union([x=-((2*%i*%pi*%z0+log(49/25))/log(343/125))])

Let's find a real solution --- we need to use carbon-based computing (our brains) to see that we need to set %z0 to zero:

(%i10)      solX : subst(%z0=0,sol);
(solX)      %union([x=-(log(49/25)/log(343/125))])

Let's check --- always check:

(%i11)      subst(first(solX),eq1);
(%o11)      5^(2-(3*log(49/25))/log(343/125))=7^(2-(3*log(49/25))/log(343/125))

(%i12)      radcan(%);
(%o12)      1=1

There are light-weight methods to standardize the base to %e, using function_convert isn't needed.  Something like  subst("^"  =  lambda([a,b], exp(b*log(a)), xxx)) will work.

Maybe I will find a new syntax for register_converter that allows the alias to be optional.  Also, for now , the third argument to  register_converter must be a Maxima lambda form. I think I can insert a few lines of code and allow the last argument to be a Maxima function.  Maybe I'll try to do that too.

--Barton