Services & ResourcesWolfram ForumsMathGroup Archive

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

Re: Re: Solve's Strange Output

• To: mathgroup at smc.vnet.net
• Subject: [mg89119] Re: [mg89096] Re: Solve's Strange Output
• From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
• Date: Mon, 26 May 2008 01:30:51 -0400 (EDT)
• References: <g1avr4$fev$1@smc.vnet.net> <200805251027.GAA22888@smc.vnet.net> <ED37A1A0-5DA8-44C9-8196-783A9DF06616@mimuw.edu.pl> <f831b3d60805251300v69adaa8m8d3f98a2c5347513@mail.gmail.com>

On 26 May 2008, at 05:00, Szabolcs Horv=E1t wrote:

> On Sun, May 25, 2008 at 3:51 PM, Andrzej Kozlowski 
> <akoz at mimuw.edu.pl> wrote:
>>
>> On 25 May 2008, at 19:27, Szabolcs wrote:
>>
>>> On May 25, 9:09 am, Bruce Colletti <bwcolle... at verizon.net> wrote:
>>>>
>>>> Re 6.0.2 under WinXP.
>>>>
>>>> This code's output is strange:  what does 0.-7.9424 g mean?  
>>>> Ditto for=
>>>
>>> all values returned by Solve.
>>>>
>>>> Thankx.
>>>>
>>>> Bruce
>>>>
>>>> {x[0],y[0]}={10.5,6.08};
>>>> {x[1],y[1]}={3.23,14.4};
>>>> {x[2],y[2]}={18,12.7};
>>>> m=16.1;
>>>>
>>>> Solve[{a+c==0,b+d==m*g,d(x[2]-x[0])==c(y[2]-y[0]),a(y[1]-=
y[0])=
>>>
>>> ==b(x[1]-x[0])},{a,b,c,d}]
>>>>
>>>> Out[11]= {{a->0.-7.9424 g,b->0.+9.08951 g,c->0.+7.9424 g,d-
>>>> >0.+7.01049 g=
>>>
>>> }}
>>>
>>> It has been mentioned many times that using Solve with inexact 
>>> numbers
>>> invites trouble.  Though in this specific case nothing bad 
>>> happens, it
>>> is better to Rationalize the numbers before solving:
>>>
>>> Solve[Rationalize[{a + c == 0, b + d == m*g,
>>> d (x[2] - x[0]) == c (y[2] - y[0]),
>>> a (y[1] - y[0]) == b (x[1] - x[0])}], {a, b, c, d}]
>>>
>>> 0 is not the same as 0.0.  The latter is an inexact zero (we only =

>>> know
>>> that it is closer to 0 than $MinMachineNumber), so Mathematica does
>>> not simplify 0. + g.
>>>
>>
>>
>> The advice not to mix symbolic algebraic methods with approximate 
>> numbers is
>> a sound one in general, but in this particular case no serious 
>> symbolic
>> algebra is involved, so one can simply apply Chop to the answer 
>> returned by
>> Solve:
>>
>> Chop[Solve[{a + c == 0, b + d == m*g,
>>     d*(x[2] - x[0]) == c*(y[2] - y[0]),
>>     a*(y[1] - y[0]) == b*(x[1] - x[0])},
>>   {a, b, c, d}]]
>> {{a -> -7.942397088866652*g, b -> 9.089510836227038*g,
>>   c -> 7.942397088866652*g, d -> 7.010489163772964*g}}
>>
>> In more complicated situations the alternative to rationalizing is =

>> to use
>> NSolve, which can be very much faster and is intended for dealing 
>> with
>> algebraic-numeric issues:
>>
>> Chop[NSolve[{a + c == 0, b + d == m*g, d*(x[2] - x[0]) ==
>>       c*(y[2] - y[0]), a*(y[1] - y[0]) == b*(x[1] - x[0])}, {a, =
b, 
>> c, d}]]
>> {{a -> -7.942397088866652*g, b -> 9.089510836227038*g,
>>   c -> 7.942397088866652*g, d -> 7.010489163772964*g}}
>>
>> but of course in this very simple case it makes not difference 
>> which method
>> we use.
>>
>
> Yes, you are right.  Actually the only kind of possible problem that I
> know about is that Solve checks the validity of solutions, and drops
> those that appear to be invalid because of rounding errors.  This
> problem can be prevented by using the option VerifySolutions -> False.
> However, the docs say that with VerifySolutions -> False some of the
> solutions returned may be incorrect.


That will happen only with certain types of equations, where the 
solution method may introduce so called "parasite" solutions. The most 
common type are equations involving radicals. For example, this has no 
solutions:

Solve[1/(Sqrt[x] + 1) - Sqrt[x + 1] == 2, x]
{}

However, setting VerifySolutions->False we find lots of "parasites"

Solve[1/(Sqrt[x] + 1) - Sqrt[x + 1] == 2, x,
   VerifySolutions -> False]

{{x -> 0}, {x -> 8/3 - (7*2^(2/3)*(1 + I*Sqrt[3]))/
           (3*(67 + 3*I*Sqrt[111])^(1/3)) -
         ((1 - I*Sqrt[3])*(67 + 3*I*Sqrt[111])^(1/3))/
           (3*2^(2/3))},
   {x -> 8/3 - (7*2^(2/3)*(1 - I*Sqrt[3]))/
           (3*(67 + 3*I*Sqrt[111])^(1/3)) -
         ((1 + I*Sqrt[3])*(67 + 3*I*Sqrt[111])^(1/3))/
           (3*2^(2/3))},
   {x -> 8/3 + (14*2^(2/3))/(3*(67 + 3*I*Sqrt[111])^
                (1/3)) + (1/3)*(2*(67 + 3*I*Sqrt[111]))^(1/3)}}

Note that NSolve has no such problem:

NSolve[1/(Sqrt[x] + 1) - Sqrt[x + 1] == 2, x]
{}

Andrzej Kozlowski

• References:
  • Re: Solve's Strange Output
    • From: Szabolcs <szhorvat@gmail.com>