7
$\begingroup$

Bug introduced in 8.0 or earlier and fixed in 11.0.0.

Confirmed, as bug, by WRI: [CASE:3527549]


I have observed curious behaviour on domains supplied to NotElement and Reduce and domain of an argument in calculation inside NotElement:

Reduce[x == 1 && NotElement[x + 1/2, Integers], x, Integers]

(* False *)

Reduce[x == 1 && NotElement[x + 1/2, Integers], x, Rationals]

(* x == 1 *)

Reduce[x == 1 && NotElement[x + Sqrt[2], Rationals], x, Rationals]

(* False *)

Reduce[x == 1 && NotElement[x + Sqrt[2], Rationals], x, Algebraics]

(* x == 1 *)

Reduce[x == 1 && NotElement[x + E, Algebraics], x, Algebraics]

(* False *)

Reduce[x == 1 && NotElement[x + E, Algebraics], x, Reals]

(* x == 1 *)

Reduce[x == 1 && NotElement[x + I, Reals], x, Reals]

(* False *)

Reduce[x == 1 && NotElement[x + I, Reals], x, Complexes]

(* x == 1 *)

It would seem that these trivial operations result False (no solutions exist) when the domain of the added constant in equation inside NotElement is in larger domain than one used as an argument of Reduce. Does this make sense, or is it actually a bug? If it does make sense, why exactly? To me it seems at best highly unintuitive.

Before someone says that all equations, or constants in equations or domain specifications inside Reduce should be at most at the domain supplied to it, consider the following, sensible results when using Element:

Reduce[x == 1 && Element[x + 1/2, Integers], x, Integers]

(* False *)

Reduce[x == 1 && Element[x + 1/2, Rationals], x, Integers]

(* x == 1 *)

EDIT: To add more hair-splitting semantics leading to hair-pulling, the following variation does work nicely:

Reduce[x == 1 && NotElement[x + 1/2, Integers], Element[x, Integers]]

(* x == 1 *)

I know this only constrains the result, not the domain where solution is sought.

Also, it seems Reduce is not particularly picky about out-of-domain constants on other parts of the equation:

Reduce[x - E == 1 - E, x, Integers]

(* x == 1 *)

So, what (combination of factors) exactly makes NotElement so special in the equation part? Is this a very unintuitive feature (particularly as from user perspective, simple Element statements seem to work), or should it really be considered to be a bug?

$\endgroup$
  • $\begingroup$ The documentation for Reduce says that Reduce[expr,vars,dom] restricts all variables and parameters to belong to the domain dom. Since in the first example 1/2 does not belong to Integers that makes it False. Reduce[ x== 1 && NotElement[ x + 1/2 ], x] therefore does what it should do. $\endgroup$ – gwr Feb 2 '16 at 17:53
  • 2
    $\begingroup$ If you use Traceyou will see what happens with your last two statements: In the first case (Integers) the 1/2 stays inside the Reducemaking it false. The condition Element[ 1/2 + x, Rationals] though can be reduced to Element[ x, Rationals ] since for any Rational this should hold; the 1/2 vanishes making this work out. I admit unintuitive. :) $\endgroup$ – gwr Feb 2 '16 at 18:14
  • 1
    $\begingroup$ @gwr This all makes me wonder what's special about Element and NotElement inside Reduce, and how they're handled there. One more example to consider: Reduce[x - E == 1 - E, x, Integers] doesn't fail to return the correct answer, and according to Trace, the equation is not simplified before it gets passed to Reduce. $\endgroup$ – kirma Feb 2 '16 at 18:42
  • 3
    $\begingroup$ @gwr unintuitive is a soft way of saying it... The documentation doesn't exactly say "restricts all variables and parameters... [except those that are obvious to be reduced before being considered by Reduce]. :) $\endgroup$ – P. Fonseca Feb 2 '16 at 21:20
  • 2
    $\begingroup$ @kirma My bad, there is actually a remaining code issue. It's being fixed today. $\endgroup$ – ilian Mar 4 '16 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.