0
$\begingroup$

As indicated by its name, PiecewiseExpand's most natural application is to Piecewise expressions but nonetheless, it is still documented as being applicable to (unevaluated) If, Which and Switch expressions. Has anyone ever had any experience of usefully applying PiecewiseExpand to these procedural-like conditionals?

Applications like

Clear@f;

f[x_] := Which[
   EvenQ@x, "even",
   LessThan[10]@x, "lessThan10",
   GreaterThan[20]@x, "greaterThan20"];

PiecewiseExpand[f[x], Assumptions -> x \[Element] Integers]

enter image description here

don't expand as expected in more general programming contexts whereas PiecewiseExpand's simplifying engine seems more apt in mathematical settings in which case Piecewise then seems more natural.


Clear@f;

f[x_] := Piecewise[{
    {"even", Mod[x, 2] == 0},
    {"lessThan10", x < 10},
    {"greaterThan20", x > 20}}];

PiecewiseExpand[f[x], Assumptions -> x \[Element] Integers]

enter image description here

$\endgroup$
15
  • $\begingroup$ Just search piecewiseexpand if in this site and you'll see a number of related answers. $\endgroup$
    – xzczd
    Oct 7, 2021 at 10:03
  • $\begingroup$ I did do this as well as search Mathematica's internal files for any examples of PiecewiseExpand being effectively applied to If, Which or Switch. Could you perhaps provide a link or two? $\endgroup$ Oct 7, 2021 at 10:09
  • 1
    $\begingroup$ Well, I myself use the combination of PiecewiseExpand and If (and in many cases Simplify`PWToUnitStep) quite a bit, because for simple binary decision I found e.g. PiecewiseExpand@If[x > 2, 1, 3] is easier to code and cleaner than Piecewise[{{1, x > 2}}, 3]. For more info just check the link above. $\endgroup$
    – xzczd
    Oct 7, 2021 at 10:18
  • 1
    $\begingroup$ So, you're not that interested in arithmetic application of If, Which, Switch? Then I think it's better to clarify a bit in the body of question. $\endgroup$
    – xzczd
    Oct 7, 2021 at 12:16
  • 2
    $\begingroup$ My memory, fwiw, of algebraic/functional Piecewise vs. control-flow/procedural If etc. is the robustness @xzczd refers to (in algebraic/numerical solvers) was more apparent in earlier versions. Over time, PiecewiseExpand has been added under the hood to the solvers because (I surmise) users did appreciate the difference between Piecewise and If. I don't recall seeing someone use Piecewise to select, say, a method subroutine depending option values. The confusion seems to be one-way. $\endgroup$
    – Michael E2
    Nov 6, 2021 at 12:22

1 Answer 1

3
$\begingroup$

The problem here is that EvenQ@ximmediately evaluates to False. As you note, if you replace this by Mod[x,2]==0 then PiecewiseExpand works fine.

In my view, what you really need here is a domain, say adding Evens and Odds—just as NonNegativeIntegers and friends were added in 12.0—so that you can write Element[x,Evens] instead.

As a related example, instead of using PrimeQ@n we have a domain to work with: Element[n,Primes].

$\endgroup$
2
  • $\begingroup$ +1 Ok, thanks for noticing that and which on further investigation had been previously observed. Yes a domain "Evens" solution is a more literate one over Mod however the pathway it suggests portends large downstream "duplication"-one version of (potentially unevaluated) functions for PiecewiseExpand and another (never unevaluated) for the procedural conditionals. This seems less than ideal; note also the (potentially unevaluated) Positive, Negative NonNegative,NonPositive ... $\endgroup$ Nov 8, 2021 at 4:11
  • 1
    $\begingroup$ ... This all stems from the idiom of *Q functions being "never unevaluated" which seems to me to be an unfortunate early design decision but that horse seems to have bolted ... $\endgroup$ Nov 8, 2021 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.