[Date Index]
[Thread Index]
[Author Index]
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??**
| |