MathGroup Archive 2004

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

Search the Archive

Re: Re: Solve Feature?

  • To: mathgroup at
  • Subject: [mg52869] Re: [mg52843] Re: Solve Feature?
  • From: Daniel Lichtblau <danl at>
  • Date: Wed, 15 Dec 2004 04:26:43 -0500 (EST)
  • References: <> <> <002401c4dfb5$809b6a00$1802a8c0@Pentium4> <> <> <> <>
  • Sender: owner-wri-mathgroup at

Andrzej Kozlowski wrote:
> On 14 Dec 2004, at 20:00, Daniel Lichtblau wrote:
>> *This message was transferred with a trial version of CommuniGate(tm) 
>> Pro*
>> DrBob wrote:
>>> By the way, it gets even worse if I use NSolve:
>>> solution = NSolve[{c1, c5}]
>>> {c1, c5} /. solution
>>> Apply[Subtract, {c1, c5}, {1}] /. solution
>>> {{x -> -4.27759132*^8,
>>>    y -> 43.74999927054117},
>>>   {x -> 4.2775924*^8,
>>>    y -> 43.75000072945884}}
>>> {{False, False}, {False, False}}
>>> {{1.82977917785309*^17,
>>>    1.82977917785309*^17},
>>>   {1.8297792462945597*^17,
>>>    1.8297792462945597*^17}}
>>> These are simple polynomial equations, so this is really puzzling.
>>> Bobby
>>> [...]
>> The NSolve result is more troublesome. I tracked it to some difficulty
>> in assessing either of two important facts.
>> (1) The precision used in an eigen decomposition is not adequate for the
>> problem at hand.
>> (2) The result gives a large residual for the inputs when normalized in
>> what I believe to be a reasonable way (obviously we can make the
>> residual as large or small as we please by suitably rescaling the input).
>> It is not too hard to fix the code for either of these but there are
>> drawbacks.
>> The second issue came about from a poor choice on my part of what to
>> check: I used a numerical Groebner basis instead of the original inputs.
>> So this can (and will) be addressed. In those cases where it catches
>> trouble (as in this example) the fix is to redo certain computations at
>> higher precision. As the code for this is already present the only issue
>> is in the detection itself. The down side is that I am not certain it
>> will be adequate to assess poor solutions in general, though it works
>> reasonably well for this example.
>> [...]
>> Whatever the outcome of investigating that numeric Groebner basis part,
>> EigenXXX computation needs to sort out how to handle the resulting
>> matrix. So this part at least is a bug to be fixed.
>> Daniel Lichtblau
>> Wolfram Research
> I still don't fully understand why (as I pointed out in one of my 
> postings on this topic)
> NSolve[{c1, c5}, {x, y}, WorkingPrecision -> 16]
> gives a good answer (and also, of course,  for all values of 
> WorkingPrecision >=16). Presumably this is because of the use of 
> significance arithmetic (a good thing to point out to some of it's 
> critics ;-)). If so, why can't Mathematica always use significance 
> arithmetic in such cases?
> Andrzej Kozlowski
> Chiba, Japan

Setting WorkingPrecision->16 forces significance arithmetic use in the 
eigen decomposition and also in later code that checks residuals. That 
precision happens, in this case to suffice to recognize a bad result, 
and the EigenXXX computation is redone at higher precision.

Arguably the significance arithmetic should be used if we specify
WorkingPrecision->15, say. But the code is not set up at this time to 
switch from MachinePrecision to bignum arithmetic at a lower precision. 
I view this as a relatively minor shortcoming (certainly compared to the 
task of recognizing and handling ill conditioning).

This gets to the question of why not use significance arithmetic. The 
answer is that it is used, in cases where NSolve can discern the need. 
That's the hard part, it's where NSolve fell short in this particular 
example, and it's what will receive some attention in development this week.

Daniel Lichtblau
Wolfram Research

  • Prev by Date: Integrate in version 5.1
  • Next by Date: Re: Re: Solve Feature?
  • Previous by thread: Re: Solve Feature?
  • Next by thread: Re: Re: Solve Feature?