WOLFRAM

Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2008

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

Search the Archive

RE: Re: Strange behaviour of Solve without VerifySolutions

Dear Daniel,

After having read the answer of Andrzej and yours, I have to apologize: 
What you did was very fine and logical...
Thank you for having taken time to explain this to the rather stupid 
mathematician that I am! I should have understood this by myself!

No doubt Mathematica is very trustworthy! But the user really still has 
to use his brain...

Best Regards

Florian




-----Message d'origine-----
De=A0: Daniel Lichtblau [mailto:danl at wolfram.com]
Envoy=E9=A0: jeudi, 31. janvier 2008 06:49
=C0=A0: mathgroup at smc.vnet.net
Objet=A0: [mg85179] Re: [mg85146] Strange behaviour of Solve without 
VerifySolutions

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
  • Prev by Date: Re: Strange behaviour of Solve without VerifySolutions
  • Previous by thread: Re: Strange behaviour of Solve without VerifySolutions
  • Next by thread: Re: Strange behaviour of Solve without VerifySolutions