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

Improve this question
$\endgroup$
15
  • $\begingroup$ Just search piecewiseexpand if in this site and you'll see a number of related answers. $\endgroup$ Commented 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$ Commented 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$ Commented 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$ Commented 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$ Commented Nov 6, 2021 at 12:22

1 Answer 1

Reset to default
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].

Improve this answer
$\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$ Commented 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$ Commented Nov 8, 2021 at 4:14

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.