Skip to main content
19 events
when toggle format what by license comment
Nov 9, 2021 at 5:10 comment added Ronald Monson ... not needed in conditional definitions or in say Select operations 3) Its covenant is already broken in many places 4) it can lead to clear bugs in negative definitions like SatisfiabilityQ@2 5) Its definitiveness can be forced with TrueQ in conditionals or in the case of If with extra flexibility in its final argument. I imagine there are important use-cases for this T/F mandate (which also breaks the covenant of "lazy unevaluation" in a symbolic language) but I have to confess to struggling to come up with examples?
Nov 9, 2021 at 5:01 comment added Ronald Monson ... There are a couple of examples of differentiability and statistical distributions where PiecewiseExpand seems necessary although I tend to think these are bugs that will eventually be resolved to restore their interchangeability. As for "As for *Q[] functions, immediate T/F evaluation is useful. It's nice that one can predict when that's going to happen"; I wonder if this really is the case; 1) it creates angst/gotchas in several places (Piecewise/Reduce etc) 2) it is ...
Nov 9, 2021 at 4:59 comment added Ronald Monson @MichaelE2 AFAICMO none of the 3 examples suggest a lack of interchangeability 1) is using PiecewiseExpand to control evaluation which could be handled using a With injection with If 2) in my latest Mma version the If and Piecewise versions work identically (although this might be later versions catching up as suggested) while in 3) the graphing issue seems to be related to and resolvable by options not any Piecewise casting/defining. Hence all these seem to be examples of ready interchangeability ...
Nov 8, 2021 at 5:00 comment added Michael E2 Some cases where they didn't seem to be interchangeable: 1) 2) 3) -- As for *Q[] functions, immediate T/F evaluation is useful. It's nice that one can predict when that's going to happen (except EllipticNomeQ[] or LegendreQ[]). One has to think about other approaches for use-cases in which immediate evaluation is problematic.
Nov 8, 2021 at 4:32 comment added Ronald Monson ... both. It seems that this tension is the main reason why the *Q functions are designed to always evaluate. I think there is potentially a way around this but alas at least with the current designs this seems baked in.
Nov 8, 2021 at 4:29 comment added Ronald Monson @MichaelE2 Perhaps that is the chronology (I don't have any sense/data either way) but I would also say the original design intent seems to have been for these to both be interchangeable even if such interchangeably seems to have been sparingly realised save for some appreciative users. The problem is that to implement the interchangeability there is a tension between forcing evaluation (to avoid annoying TrueQ boilerplate) for control-flow usage and maintaining non-evaluation for mathematical/piecewise usage - a tension that comes home to roost when PiecewiseExpand is set to apply to ...
Nov 6, 2021 at 12:22 comment added Michael E2 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.
Nov 6, 2021 at 6:48 answer added TheDoctor timeline score: 3
Oct 8, 2021 at 1:38 history edited Ronald Monson CC BY-SA 4.0
edited title
Oct 7, 2021 at 22:56 comment added Ronald Monson Well, yes and no, yes, mainly yes but no, not never no (I'll clarify in question in due course)
Oct 7, 2021 at 12:16 comment added xzczd 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.
Oct 7, 2021 at 11:30 comment added Ronald Monson At any rate, thanks for digging those up but I guess I'm looking more for some examples/idioms using more "control-flow-like" branching found in "general programming" rather than alternative, syntactical definitions of mathematical functions -- although this is admittedly a bit vague.
Oct 7, 2021 at 11:23 comment added Ronald Monson I don't see evidence of such robustness in the three links provided: the first link seems to produce identical output with PiecewiseExpand removed; the second link doesn't seem to need PiecewiseExpand as its role is in forcing a default value (achieved by putting a final 0 in the corresponding If statement) while in the third link the same output is generated by removing PiecewiseExpand after some minor re-factoring. Further, outside these, it seems SE posts very rarely use PiecewiseExpand on a conditional and when they do, it is to illustrate some documentation-like toy example.
Oct 7, 2021 at 10:29 comment added xzczd As to the reason for transforming If[…] to Piecewise[…], generally Piecewise is more robust for defining piecewise functions, see the following posts: mathematica.stackexchange.com/a/69066/1871 mathematica.stackexchange.com/a/29610/1871 mathematica.stackexchange.com/a/156913/1871
Oct 7, 2021 at 10:18 comment added xzczd 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.
Oct 7, 2021 at 10:09 comment added Ronald Monson 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?
Oct 7, 2021 at 10:03 comment added xzczd Just search piecewiseexpand if in this site and you'll see a number of related answers.
Oct 7, 2021 at 9:25 history edited Ronald Monson CC BY-SA 4.0
added 22 characters in body
Oct 7, 2021 at 7:09 history asked Ronald Monson CC BY-SA 4.0