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/ >> >

**References**:**Solve chokes on Piecewise input that Reduce handles quite well??***From:*"Chris Chiasson" <chris@chiasson.name>

**Re: K-nearest neighbhors on an equispaced multidimensional grid**

**Re: Re: Finding the periphery of a region**

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

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