Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2006
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2006

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

Search the Archive

Re: Solve chokes on Piecewise input that Reduce handles quite well??

  • To: mathgroup at smc.vnet.net
  • Subject: [mg72034] Re: [mg72007] Solve chokes on Piecewise input that Reduce handles quite well??
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Sat, 9 Dec 2006 06:09:41 -0500 (EST)
  • References: <200612081117.GAA20182@smc.vnet.net> <478C4754-5ED4-48A0-88F2-1D9F445BFCFF@mimuw.edu.pl>

Perhaps I should have added that, besides aesthetic purity, I see  
many concrete advantages in keeping Solve as it is now: an (almost)  
pure algebraic equation solver. First of all, there is no need at all  
to duplicate the functionality of Reduce. Secondly: algebraic  
equation solving is an area where (more or less) complete algorithms  
are known, and where one can (more or less) identify the class of  
problems that are in principle solvable, so one can dismiss the other  
ones without wasting time on hackery which is likely to fail anyway.  
(Of course even in the case of purely algebraic equations there  
remains the issue of algebraic complexity so it is quite possible for  
Solve to embark on an attempt to solve something that is solvable in  
principle but it might take 100 years to get the answer. But that's  
part of the nature of computer algebra).
Finally, not having to mix algorithms of very different kind, makes  
it possible to make the output very predicatble. The output of Solve  
is always a list of rules this greatly facilitates using Solve in  
programming. By comparison just look at these two examples of using  
Reduce on very similar input:


ToRules[Reduce[x^3 - x^2 - y^2 >= 0 && x < 1, x, Reals]]

{y -> 0, x -> 0}


ToRules[Reduce[x^3 - x^2 - y^2 >= 0 && x < 2, x, Reals]]


Sequence[ToRules[-2 < y && y < 0 && Root[#1^3 - #1^2 - y^2 & , 1] <=  
x && x < 2],
   {y -> 0, x -> 0}, ToRules[y == 0 && 1 <= x && x < 2],
   ToRules[0 < y && y < 2 && Root[#1^3 - #1^2 - y^2 & , 1] <= x && x  
< 2]]

I wouldn't call that "predictable", would you?

Andrzej Kozlowski



On 8 Dec 2006, at 23:02, Andrzej Kozlowski wrote:

> I can see no reason at all why Solve should handle  Piecewise with  
> inequalities. Solve is meant for solving algebraic equations over  
> the complex numbers and what you have got are inequalities, which  
> do not make sense in this setting. The following does make sense
>
> Solve[Piecewise[{{2, x == 3}, {3, x == 2}}] == 3, x]
>
> {{x -> 2}}
>
> But but my aesthetic judgment would be seriously offended if this  
> worked:
>
> Solve[Piecewise[{{2, x >= 2}, {3, x == 2}}] == 3, x]
>
> Fortunately, it does not.
>
> Andrzej Kozlowski
>
>
>
>
> On 8 Dec 2006, at 20:17, Chris Chiasson wrote:
>
>> Solve[{0 == Piecewise[{{1/(-1 + X[1] + X[2])^2, X[1] + X[2] <= -1}},
>> (1/2)*(3/2 + (1/2)*(-1 + X[1] + X[2]))] +
>>      Piecewise[{{(1/2)*(-(3/2) + X[1]/2), X[1] < 2}, {-(1/4), X[1] ==
>> 2}}, -(1/X[1]^2)] + 2*(-1 + X[1]),
>>    0 == Piecewise[{{1/(-1 + X[1] + X[2])^2, X[1] + X[2] <= -1}},
>> (1/2)*(3/2 + (1/2)*(-1 + X[1] + X[2]))] +
>>      2*(-1 + X[2])}, {X[1], X[2]}]
>>
>> Solve::eqf: X[1]+X[2]\[LessEqual]-1 is not a well-formed equation.
>>
>> ...
>>
>> (and it returns the input)
>>
>> Here is the same command using Reduce:
>>
>> Reduce[{0 == Piecewise[{{1/(-1 + X[1] + X[2])^2, X[1] + X[2] <= -1}},
>> (1/2)*(3/2 + (1/2)*(-1 + X[1] + X[2]))] +Piecewise[{{(1/2)*(-(3/2) +
>> X[1]/2), X[1] < 2}, {-(1/4), X[1] == 2}}, -(1/X[1]^2)] + 2*(-1 +
>> X[1]),
>>    0 == Piecewise[{{1/(-1 + X[1] + X[2])^2, X[1] + X[2] <= -1}},
>> (1/2)*(3/2 + (1/2)*(-1 + X[1] + X[2]))] +
>>      2*(-1 + X[2])}, {X[1], X[2]}]
>>
>> X[1] == 75/89 && X[2] == 51/89
>>
>> Did I do anything wrong? Is this a bug? If it is a bug, please  
>> file it
>> and fix it.
>>
>> -- 
>> http://chris.chiasson.name/
>>
>


  • Prev by Date: Re: K-nearest neighbhors on an equispaced multidimensional grid
  • Next by Date: Re: Re: Finding the periphery of a region
  • Previous by thread: Re: Solve chokes on Piecewise input that Reduce handles quite well??
  • Next by thread: Re: Solve chokes on Piecewise input that Reduce handles quite well??