Logged In: YES
user_id=501686
Observed in 5.9.3.
In a very simple case, Solve/Algsys (a) reports many
incorrect solutions and (b) misses all the parameterized
solutions.
-- Define equations
eqs: [a+b+c=0, a*b*c=1]
-- These seem pretty simple, don't they?
-- Solve 2 equations for 3 unknowns (normal algsys)
sols: solve(eqs,[a,b,c])
-- Gives 12 solutions
-- Substitute back the solutions
subst: map(lambda([sol],subst(sol,eqs)),sols)
-- Big mess
-- Now evaluate them numerically to eyeball them
rectform(subst),numer
-- Surprise! Only 6 of the 12 are right.
And it is completely missing the parametric solution(s)!!!
For example,
a= 2 / ( sqrt( Q^4-4*Q ) - Q^2 )
b= ( sqrt( Q^4-4*Q ) - Q^2 ) / (2*Q)
c= Q
Logged In: YES
user_id=501686
Observed in 5.9.3.
With algebraic : true, we get another bug:
(%i34) eqs: [a+b+c=0, a*b*c=1];
(%o34) [c+b+a=0,a*b*c=1]
(%i35) algsys(eqs,[a,b,c]), algebraic : true;
Quotient by a polynomial of higher degree
-- an error. To debug this try debugmode(true);
I think I've figured out why this dies with algebraic set to true. I don't have a fix yet, but I'm attaching an org file with a (long!) discussion that explains what's happened.
Short version: We call SUBRESULT on two polynomials in the variable b
. Some of the coefficients happen to contain sqrt(b^3-4)
. When squaring the coefficients as part of the PRS calculation, the hidden b
's escape and play havoc with the rest of the algorithm.
I've just pushed a patch ([c813e4]) that avoids us dying with algebraic set to true.
Well, I definitely spoke (and pushed) too soon there. Just realised that the patch avoids the lisp error by completely breaking the example. Aargh. Will look into this further over the next couple of days.
Log in to post a comment.