Services & ResourcesWolfram ForumsMathGroup Archive

[Date Index] [Thread Index] [Author Index]

Re: Strange behaviour of Solve without VerifySolutions

• To: mathgroup at smc.vnet.net
• Subject: [mg85179] Re: [mg85146] Strange behaviour of Solve without VerifySolutions
• From: Daniel Lichtblau <danl at wolfram.com>
• Date: Thu, 31 Jan 2008 00:49:18 -0500 (EST)
• References: <200801301106.GAA11322@smc.vnet.net>

Jaccard Florian wrote:
> Dear Mathematica-specialists,
> 
> One of my students needed to solve a simple system:
> 
> equations =
>      {(2 + 1.6*a + 8*b)^2/
>              (8*a*(3 + 8*c + 1.6*b)) -
>            1.7 == 0,
>        (3 + 8*c + 1.6*b)^2/
>              ((8*b + 2 + 1.6*a)*
>                 (3 + 1.6*c)) - 1.7 == 0,
>        (3 + 1.6*c)^2/(3 + 8*c +
>                 1.6*b) - 1.7 == 0};
> res = Solve[equations, {a, b, c}]
> 
> My student saw that there is a problem because he compared with the 
> answers he obtained using another system, which were completely different!
> 
> Just type :
> 
> Chop[equations /. (expr_) == (n_) ->
>          expr /. res]
> 
> As you easily can see, all solutions are wrong!
> 
> Looking in the Solve options, I saw that you can add the option : 
> VerifySolutions->True:
> 
> res2 = Solve[equations, {a, b, c},
>      VerifySolutions -> True]
> And here, you can see that the solutions are all OK:
> 
> Chop[equations /. (expr_) == (n_) ->
>          expr /. res2]
> 
> My question: Why did Wolfram make such a, I believe, stupid thing? Is 
> there a good reason?

The stupid thing, in my opinion, was to let the VerifySolutions option 
cause internal raising of precision in Solve so that such examples might 
"work". The reason I did that was because a few people had sent 
examples, many years ago, where that seemed to help. At the time I had 
not rewritten NSolve, a function much better equipped for such problems.

Okay, maybe that raising of precision was not stupid. I'm not convinced 
one way or the other. I am pretty sure Solve should not abandon machine 
arithmetic by default, that is, when VerifySolutions is set to Automatic.

Pretty much any variation of this, other than using machine arithmetic, 
will behave at least a bit better. Solving a nonlinear system, at 
machine precision, and using symbolic solver, is much less reliable. 
There is a bit more to the story, which I will explain below.


> I'm not sure students (ore engineers and so on) will take the time to 
> verify all solutions (usually, Mathematica tells when there may be a 
> problem!) ore to Rationalize all the numbers of the equations... and I'm 
> afraid they won't think about VerifySolutions. And as Mathematica is 
> used to make a good job, students usually believe in the 
> Mathematica-responses...

I'm hoping they'll discover NSolve. It is intended for such problems.


> I'm also afraid the other system does in this case a better job...
> 
> In a future release, I would appreciate more trustworthiness!
> 
> Best Regards
> 
> 
> Florian Jaccard

One should not rule out the possibility of a bug, or at least slightly 
weak code, in the default handler itself. In this case the problem shows 
up when we rationalize coefficients. We use Rationalize[number,0] to be 
certain to get a rational from a float. With machine numbers, and their 
roundoff error, we wind up with huge fractions that lead to the numeric 
instability. A change in our internals to do, in effect, 
Rationalize[Rationalize[number],0]
will tend to give more modest sized fractions, when possible. So a 
future version of Mathematica should play nicer with this example.

All the same, use of NSolve (which has no need of Rationalize) is 
recommended for such inputs. That's why we have this function.


Daniel Lichtblau
Wolfram Research

• Follow-Ups:
  • RE: Re: Strange behaviour of Solve without VerifySolutions
    • From: "Jaccard Florian" <Florian.Jaccard@he-arc.ch>

• References:
  • Strange behaviour of Solve without VerifySolutions
    • From: "Jaccard Florian" <Florian.Jaccard@he-arc.ch>