12
$\begingroup$

I'm seeing some perplexing behavior from ValueQ in 10.3. Consider:

f[r_List, n_Integer] := r^n;
ValueQ[f[{}, 1]]

(* ==> True *)

ValueQ[f[{}, 0.3]]

(* ==> False *)

ValueQ[f[{}, \[Pi]]]

(* ==> False *)

ValueQ[f[{a, b, c}, 3/2]]

(* ==> True *) (* THIS IS UNEXPECTED *)

f[{1,2,3}, 3/2]

(* ==> f[{1,2,3}, 3/2] *)

What I expect is that any ValueQ call that has an argument list that matches the types in the function definition's pattern -- and therefore could be transformed by the rule associated with that definition -- will return True. Any call with an argument list having different types will return False. As I understand it, what ValueQ does is test whether a rule exists that would transform its argument.

And that's what happens, EXCEPT for the final case, in which a {List,Rational} slips through when only a {List,Integer} should. ValueQ returns True. And yet, if I actually evaluate that function with those arguments, no transformation occurs, because (of course) no appropriate rule exists.

It seems that ValueQ is simply failing. Is this a bug, or do I fail to understand some subtlety here?

$\endgroup$
13
$\begingroup$

Well, the documentation of ValueQ states

ValueQ gives False only if expr would not change if it were to be entered as Wolfram Language input.

This explains pretty much everything you are experiencing. Very easy example:

Hold[1/2]//FullForm
(* Hold[Times[1,Power[2,-1]]] *)

You see that you enter 1/2 as a multiplication but what if we don't hold it? See what happens:

1/2//FullForm
(* Rational[1,2] *)

The expression changes into something different. Therefore, you should be able to guess the answer of

ValueQ[1/2]

without evaluating it. And indeed, using the PrintDefinitions[ValueQ] function (I saw it in the Trace) from the <<GeneralUtilities` package in version 10 shows you that ValueQ for general expressions like yours does nothing more than

ValueQ[expr_] := !Hold[Evaluate[expr]] === Hold[expr];

So it compares the completely evaluated form of your f[...] call, with the held one. So even if your pattern does not match, as long as anything changes in the expression, the result will be True.

So one solution for you is simply, to prevent this behavior by evaluating the arguments of f before feeding it to ValueQ. I'm not completely sure about all consequences, but it seems in your situation this could be what you want:

SetAttributes[valueQ, {HoldFirst}];
valueQ[h_[args__]] := With[{eval = args},
  ValueQ @@ (HoldComplete[eval] /. Sequence :> h)
]

f[r_List, n_Integer] := r^n;
valueQ[f[{},1]]
valueQ[f[{},0.3]]
valueQ[f[{},π]]
valueQ[f[{a,b,c},3/2]]
(* True *)
(* False *)
(* False *)
(* False *)

A different, but similar way is to define your valueQ in the same manner as the real ValueQ:

valueQ2[h_[args___]] := With[{eval = args},
  ! Hold[Evaluate[h[args]]] === (Hold[eval] /. Hold[expr___] :> Hold[f[expr]])
]
$\endgroup$
  • $\begingroup$ Ah! :D In that case, the cure is something like SetAttributes[f, HoldAll]... $\endgroup$ – J. M. is away Nov 5 '15 at 3:40
  • $\begingroup$ Aha! So I can instead use ValueQ[f[{}, Rational[3,2]]] instead of ValueQ[f[{}, 3/2]] to check whether f[_List,_Rational] has been defined! Thank you. $\endgroup$ – ibeatty Nov 5 '15 at 3:41

Your Answer

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

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