6

I would like to test whether an argument is a valid variable for functions like Solve and DSolve. For instance several functions generate a "dsvar" or "ivar" message on bad input:

DSolve::dsvar: 2 x cannot be used as a variable. >>
Integrate::ivar: Sin[x] is not a valid variable. >>

I would like to check an argument before passing it onto one of these functions.

I used the function withBlockedVars in this answer to come up with what seems like a maybe-not-very-bad way. I block the variable and attempt to assign a value to it.

ClearAll[withBlockedVars];
SetAttributes[withBlockedVars, HoldRest];
withBlockedVars[Hold[expr_], code_] :=
 With[{heldVars =
    Thread[Cases[Unevaluated[expr],
        s_Symbol /; Context[s] === "Global`" && DownValues[s] === {} :> HoldComplete[s],
        Infinity,
        Heads -> True],
     HoldComplete]},
  heldVars /. HoldComplete[vars_List] :> Block[vars, code]]


SetAttributes[variableQ, HoldAll];
variableQ[x_] := withBlockedVars[Hold[x], Quiet@Check[x = 0; True, False]];

Tests:

t = 2;
variableQ[2^t]
(* False *)

t = 2; x = 3;
variableQ[x[2^t]]
(* True *)

variableQ[t[2]]
(* True *)

variableQ[Subscript[t, 2]]
(* True *)

My use-case is for defining functions, something like this:

f[eqn_Equal, var_?variableQ] := code

The code might call NDSolve or Plot and so on.

Is there a better way to check var? Perhaps there is a built-in function I missed?

[Edit: Any solution involving Pattern, PatternTest, Condition etc. would be acceptable. I'm not sure I can think of all the alternative possibilities.]

Community
  • 1
Michael E2
  • 235,386
  • 17
  • 334
  • 747
  • I thought perhaps "bulletproofing" or "package-writing" might be a good tag, but I found none similar. – Michael E2 Jan 10 '14 at 21:18
  • Are you looking for another variableQ or are you OK with alternate approaches? – rm -rf Jan 10 '14 at 21:26
  • @rm-rf I'm ok with alternate approaches. – Michael E2 Jan 10 '14 at 21:29
  • If you define a variable as an expression which can be assigned a value (is an L-value), then the test based on Block alone will miss some cases, e.g. Protected symbols. – Leonid Shifrin Jan 10 '14 at 21:32
  • 3
    What about using the built-in checks? Something like variableQ[var_] := Quiet[Check[Solve[0, var]~Quiet~Solve::naqs; True, False, Solve::ivar], Solve::ivar] – Rojo Jan 11 '14 at 00:59

2 Answers2

6

Instead of a variableQ, how about constraining var to be a Symbol, giving your function the HoldAll attribute and then Blocking the variable? I use this idiom/pattern all the time. As an example:

Clear@f
SetAttributes[f, HoldAll]
f[expr_, var_Symbol] := Block[{var}, Solve[expr, var] /. var -> Defer@var]
f[expr_, var_[n___]] := Block[{var}, f[expr /. var[n] -> var, var] /. var -> var@n]

Now try the following:

x = 1;
f[x^2 + 2 x + 1 == 0, x]
(* {{x -> -1}, {x -> -1}} *)

a[1] = 2;
f[a[1]^2 + 2 a[1] + 1 == 0, a[1]]
(* {{a[1] -> -1}, {a[1] -> -1}} *)

No ivar error. This also takes care of cases like x^2 or 2 x, because these are not Symbols.

rm -rf
  • 88,781
  • 21
  • 293
  • 472
  • 1
    You don't have to use Block - if the symbol evaluates, it is not a valid variable (does not match _Symbol any more) :). Otherwise, that's what I'd also do - +1. – Leonid Shifrin Jan 10 '14 at 21:35
  • 1
    @LeonidShifrin The Block takes care of cases where there might be stray assignments in Global that you don't want evaluating inside the body. (for instance, in my example above, removing the Block will give you an ivar error) Given Michael's use case, I suspect this would be a desirable option. – rm -rf Jan 10 '14 at 21:37
  • I see. As an alternative, you could simply use HoldFirst, and omit the Block. But I agree, you construct is generally more useful, and this is also what I usually do. – Leonid Shifrin Jan 10 '14 at 21:42
  • This was the first thing I thought of, too, mainly for simplicity (for myself). But I'm writing it for students and I anticipate their wanting to do things their own way and having "stray assigments" about. We also will have systems and I wondered if it would be hard to handle x[1] etc. If I do it this way, I could write my own error message. +1 – Michael E2 Jan 10 '14 at 21:44
  • @MichaelE2 x[1] can be handled with a second definition: f[expr_, var_[n___]] := Block[{var}, f[expr /. var[n] -> var, var] /. var -> var@n]. – rm -rf Jan 10 '14 at 21:57
  • Since expressions contained in Defer cannot be easily used programmatically I do not anticipate using this construct. In fact I would find it confusing for this to fail: a[1] = 2; r = f[a[1]^2 + 2 a[1] + 1 == 0, a[1]]; ClearAll[a]; a[1] /. r, meaning that it returns:

    {{a[1] -> -1}, {a[1] -> -1}} and {a[1], a[1]}. One could replace Defer with HoldPattern which would give this output for the same input: {{HoldPattern[a[1]] -> -1}, {HoldPattern[a[1]] -> -1}} and {-1, -1} but that is hardly clean. What utility do you see in this construct?

     – Mr.Wizard Jul 08 '14 at 21:29
3

It seems to me that for the basic case described in the question it would be best to simply check if a System function considers it valid, as I did for Pattern that matches colors. Therefore:

variableQ = Quiet @ ListQ @ Solve[{}, #] &;
Community
  • 1
Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • +1 Thanks, I like this (similar to Rojo's comment above). The problem is for me that the requirements of the functions mentioned in the question, Solve, DSolve, Plot, etc., are different. And I don't think I fully appreciated the differences when I posed the question. For instance, Plot tries to use something like Set on the plot variable. So while {E[1], D[x], x[1]} all pass your variableQ but only x[1] works with Plot. Solve seems very forgiving of what sort of expression may be used as a variable: Solve[Plot[x^2, {x, 0, 1}]^2 == 4, Plot[x^2, {x, 0, 1}]] – Michael E2 Jul 09 '14 at 04:12
  • @MichaelE2 Perhaps a separate test for each kind of function? (solveVariableQ etc.) Or how about using the Message itself to check for the error? Would that be acceptable to you? – Mr.Wizard Jul 09 '14 at 04:44
  • Perhaps a plotVariableQ would be the most restrictive and would work for the other functions. Plot[0, {var, 0, 1}, PlotPoints -> 2, MaxRecursion -> 0] is quick to fail and not too slow to succeed. I wanted to avoid a long computation that ends in a message that the input was invalid. For instance a long (N)DSolve followed by Plot. Perhaps my withBlockedVars method is ok? (My Q really was a generalization based on the observation that M checks for valid variables for some alg./calc. functions. In the case of Plot it does it early.) – Michael E2 Jul 09 '14 at 15:29
  • This seems good: variableQ = Quiet@Check[Table[0, {#, 1}]; True, False] & - what do you think? It's fast to fail or succeed and it tries to write the variable, like Plot. – Michael E2 Jul 09 '14 at 15:52
  • @MichaelE2 Table is no good for your purpose because it does not respect Protected on bare Symbols, e.g.: Table[E, {E, 1}]. (Enigmatically it complains with E[1].) Then again Plot accepts input such as Plot[E, {E, 0, 15}] without issuing a message but doesn't work properly, yielding a flat line. Does your original method return the correct True/False for all cases? If so I can base a method on those results. – Mr.Wizard Jul 09 '14 at 19:26
  • Actually, no, not on all the cases I've come up with. I had to change the last line of withBlockedVars to heldVars /. HoldComplete[vars_List] :> Block[vars, code] /. {} -> Block[{}, code] to handle E, E[1], etc. (where Cases returns an empty list). Then it works. – Michael E2 Jul 09 '14 at 19:46
  • Thanks. This answers the question, although I often follow rm-rf's example. (I must have gotten busy and forgotten this Q until I wanted to check it.) – Michael E2 Nov 25 '14 at 19:44