Services & ResourcesWolfram ForumsMathGroup Archive

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

Re: Re: Solve's Strange Output

• To: mathgroup at smc.vnet.net
• Subject: [mg89116] Re: [mg89096] Re: Solve's Strange Output
• From: "Szabolcs HorvÃt" <szhorvat at gmail.com>
• Date: Mon, 26 May 2008 01:30:18 -0400 (EDT)
• References: <g1avr4$fev$1@smc.vnet.net> <200805251027.GAA22888@smc.vnet.net>

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.

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