This was reported on Maxima stackoverflow
(%i1) eq1:43=%pi/4*d*d*h;
2
%pi d h
(%o1) 43 = ────────
4
(%i2) eq2:d1=d0-2*h;
(%o2) d1 = d0 - 2 h
(%i3) eq3:d0=9;
(%o3) d0 = 9
(%i4) eq4:d=(d0+d1)/2;
d1 + d0
(%o4) d = ───────
2
(%i5) solve([eq1,eq2,eq3,eq4],[d,d1,h,d0]);
(%o5) []
(%i6) solve([eq1,eq2,eq3,eq4],[d,d1,h]);
(%o6) []
But solve can find solutions using the last 3 equations:
(%i7) solve([eq2,eq3,eq4],[d,d1,h,d0]);
(%o7) [[d = %r159, d1 = 2 %r159 - 9, h = 9 - %r159, d0 = 9]]
This can be substituted into eq1 to get:
(%i8) subst(%o7,eq1);
2
%pi (9 - %r159) %r159
(%o8) 43 = ──────────────────────
4
Finally, solve can produce roots for this. Of course, they're messy, and the OP wanted a numerical solution:
(%i11) allroots(float(%o8));
(%o11) [%r159 = 3.027752659221862, %r159 = - 2.209973166894623,
%r159 = 8.18222050767276]
Mapping these 3 solutions into the original set of equations we have:
(%i12) map(lambda([r],subst(r,%o7)), %o11);
(%o12) [[[d = 3.027752659221862, d1 = - 2.944494681556276,
h = 5.972247340778138, d0 = 9]], [[d = - 2.209973166894623,
d1 = - 13.419946333789246, h = 11.209973166894624, d0 = 9]],
[[d = 8.18222050767276, d1 = 7.36444101534552, h = 0.8177794923272401,
d0 = 9]]]
And the answer expected by the OP is the last solution:
(%i13) %o12[3];
(%o13) [[d = 8.18222050767276, d1 = 7.36444101534552, h = 0.8177794923272401,
d0 = 9]]
Here is a simpler example of a system of equations which
solve/algsyscannot solve:Substituting
2orfloat(%pi)for%pi,solvereturns numerical solutions withalgexact:false(the default):Substituting
3orafor%pi,solvereturns algebraic solutions:This is all ridiculous. Clearly
solvecould be returning correct results in all these cases, including the original problem -- presumably numeric results foralgexact:false(substituting the numerical values for constants) and symbolic results foralgexact:true.Last edit: Stavros Macrakis 2024-01-15
Interesting! In the original equations, if I use
ppfor%pi, I get solutions. I guess this all boils down toalgsysnot working when%piis included. I guess that's a hint that we could replace%piwith some gensym, solve the equations, and substitute back%pifor the gensym. This is pretty awful, though.Diff:
Here is a simpler example of a system of equations which
solve/algsyscannot solve:Substituting 2 or float(%pi) for %pi,
solvereturns numerical solutions withalgexact:false(the default):Substituting 3 or
afor%pi,solvereturns algebraic solutions:This is all ridiculous. Clearly
solvecould be returning correct results in all these cases, including the original problem -- presumably numeric results foralgexact:false(substituting the numerical values for constants) and symbolic results foralgexact:true.(Other symbolic constants such as
%eand%gammahave the same effect, although non-constants such aseandgammaare unproblematic.Here is a simpler example of a system of equations which
solve/algsyscannot solve:Substituting 2 or float(%pi) for %pi,
solvereturns numerical solutions withalgexact:false(the default):Substituting 3 or
afor%pi,solvereturns algebraic solutions:I have had a quick look at this. The problem is in the back-substitution phase of algsys - probably while checking that potential solutions satisfy the equations.
We can eliminate y to obtain the cubic equation x^3+x^2-x+%pi-1
A trace on ?algsys shows that the above cubic in x is obtained and a symbolic solution for x is returned (on the second call of ?algsys).
Digging further will take some work. I seem to recall that algsys only switches to a numerical solution when solving polynomials in a single variable, and won't attempt a numerical solution while back-substituting if a symbolic solution is found at the lowest level.
Another related bug. algsys only finds two solutions of the cubic x^3+x^2-x+%pi-1. Solve returns three, as expected.
This is now bug [#4252]
Related
Bugs: #4252
Last edit: David Billinghurst 2024-01-16
I added an example of this to the algsys documentation as 20.2.3 Example 2: Equations with irrational coefficients. Not much of a solution.