FullSimplify[
LogicalExpand[(y == 0 && x == 0) || (y == 1 &&
x == 1) || (0 < y < 1 && x == y)] \[Implies] (0 <= y <= 1 &&
x == y), (x | y) \[Element] Reals]
Out: True
However, the residue remains. It doesn’t handle equivalence, requires two implications and LogicalExpand. And most importantly, it is unclear why there is a difficulty with this task.
(x == -1 && y == 1) || (-1 < x < 0 && y == -x) || (x == 0 && y == 0)
I also don’t understand. If “x” is the ordinate and “y” is the obcissa, then many x’s can correspond to one y. As far as I understand, your formula excludes this. In my formula, x determines y, not the other way around.
If we take
Reduce[(x == -1 && y == 1) || (-1 < x < 0 && y == -x) || (x == 0 && y == 0) || (0 < x < 1 && y == x), Reals]
we’ll get the right result. But that’s not what I’d like to get, namely:
(-1 <= x <= 0 && y == -x) || (0 <= x <= 1 && y == x)
In other words, that which is closer to piecewise functions
I think it’s that y is implicitly real, but x is probably treated as complex. Specifying the domain Reals adds one further constraint beyond the variables belonging to the domain: namely, that the function values in the problem and solution must also belong to the domain. I’m not sure what that means practically in the OP’s problem, but possibly a different algorithm is used that works better on inequalities. I strongly suspect that the algorithms over the Reals are distinct from the default ones, even if they overlap to a great extent. What exactly the methods are and how they’re related seems to change over time, which is to be expected as it has been an area of active research for some decades now.
Concerning the additional constraint: In the casus irreducibilis, some real roots of a polynomial solvable can be expressed in terms of n-th roots that have complex values and cannot be expressed with roots that have only real values. So for instance, in the following which has three real solutions, we get the result in terms of complex-valued cube and square roots:
For the second part, the following nearly does what you wrote as the desired result:
Reduce[
(x == -1 && y == 1) || (-1 < x < 0 && y == -x) ||
(x == 0 && y == 0) || (0 < x < 1 && y == x),
{x, y}, (* or equivalently y instead of {x, y} *)
Reals]
(* (-1 <= x <= 0 && y == -x) || (0 < x < 1 && y == x) *)
The conditions in front of the equations are disjoint; that is, the intervals -1 <= x <= 0 and 0 < x < 1 do not overlap. This is because of the way Reduce[] handles the cylindrical decomposition. I doubt there’s anyway to get Reduce[] to close the interval. Of course x <= 1 is ruled out by the x < 1 in the input. (I assume one of them is a typo, or something was omitted from the input.)
I suppose it’s because Head[Pi] is Symbol, and Pi is numeric but not a number.
For instance, it seems Pi is replaced by an internal variable, the system reduced, and then the internal variable is replaced by Pi. The cylindrical decomposition seems to apply something like the trichotomy law and consider the three cases x < ..., x == ..., and x > ... separately. Actual numbers are handled more simply, or Reduce looks to see if cases can be combined for numbers and not for symbols. I’m just guessing here. I don’t think these details are published.
Pursuing this line may be futile.
Here’s a somewhat bizarre workaround, replacing Pi by a nonnumeric symbol:
Reduce[a == Pi &&
((x == -\[Pi] && y == \[Pi]) || (-\[Pi] < x <= 0 && y == -x) ||
(0 < x < \[Pi] && y == x) /. Pi -> a),
{a, x, y}, Reals] /. a -> Pi
(* (-\[Pi] <= x <= 0 && y == -x) || (0 < x < \[Pi] && y == x) *)
On the other hand, it handles equivalence without tricks:
Reduce[
Equivalent[
(x == -\[Pi] && y == \[Pi]) || (-\[Pi] < x <= 0 && y == -x) ||
(0 < x < \[Pi] && y == x),
(-\[Pi] <= x <= 0 && y == -x) || (0 < x < \[Pi] && y == x)]
, {x, y}, Reals]
(* True *)
I suspect that the obstacle may be that Pi is trascendental. Sqrt[2] is also not a NumberQ, but it behaves differently
With[{a = Pi},
Reduce[(x == -a && y == a) || (-a < x <= 0 &&
y == -x) || (0 < x < a && y == x),
{x, y}, Reals]]
With[{a = Sqrt[2]},
Reduce[(x == -a && y == a) || (-a < x <= 0 &&
y == -x) || (0 < x < a && y == x),
{x, y}, Reals]]
Dear Michael!
It seems to me that the problem is not related to Pi properties. For some reason Wolfram breaks the calculation. It is the expression that Wolfram is evaluating.
Reduce[(\[Pi]/2 < x < \[Pi] && y == \[Pi] - x) || (x == \[Pi] && y == 0), {x, y}, Reals]
Out: \[Pi]/2 < x <= \[Pi] && y == \[Pi] - x
This one, which is a bit more complicated, does not:
Reduce[(0 < x < \[Pi]/2 && y == x) || (x == \[Pi]/2 && y == \[Pi]/2) || (\[Pi]/2 < x < \[Pi] && y == \[Pi] - x) || (x == \[Pi] && y == 0), {x, y}, Reals]
What I thought before: Pursuing this line may be futile.
I ran into this difficulty when I wrote some code to decompose integration regions. I ended up writing my own simplification routines. Integration is a bit easier to deal with, since the edges in edge cases generally have measure zero and can simply be deleted. (Or included, but as I recall, deleting turned out to make things simpler.)