# Putting Constraints on Patterns

The Wolfram Language provides a general mechanism for specifying constraints on patterns. All you need to do is to put /;condition at the end of a pattern to signify that it applies only when the specified condition is True. You can read the operator as "slash‐semi", "whenever", or "provided that".

pattern/;condition | a pattern that matches only when a condition is satisfied |

lhs:>rhs/;condition | a rule that applies only when a condition is satisfied |

lhs:=rhs/;condition | a definition that applies only when a condition is satisfied |

Putting conditions on patterns and transformation rules.

In[1]:= |

In[2]:= |

Out[2]= |

In[3]:= |

Out[3]= |

You can use on whole definitions and transformation rules, as well as on individual patterns. In general, you can put /;condition at the end of any definition or rule to tell the Wolfram Language that the definition or rule applies only when the specified condition holds. Note that conditions should not usually be put at the end of definitions or rules, since they will then be evaluated immediately, as discussed in "Immediate and Delayed Definitions".

In[4]:= |

In[5]:= |

Out[5]= |

You can use the operator to implement arbitrary mathematical constraints on the applicability of rules. In typical cases, you give patterns which *structurally* match a wide range of expressions, but then use *mathematical* constraints to reduce the range of expressions to a much smaller set.

In[6]:= |

In[7]:= |

Out[7]= |

In[8]:= |

Out[8]= |

In[9]:= |

In[10]:= |

Out[10]= |

In setting up patterns and transformation rules, there is often a choice of where to put conditions. For example, you can put a condition on the right‐hand side of a rule in the form , or you can put it on the left‐hand side in the form . You may also be able to insert the condition inside the expression lhs. The only constraint is that all the names of patterns that you use in a particular condition must appear in the pattern to which the condition is attached. If this is not the case, then some of the names needed to evaluate the condition may not yet have been "bound" in the pattern‐matching process. If this happens, then the Wolfram Language uses the global values for the corresponding variables, rather than the values determined by pattern matching.

Thus, for example, the condition in will use values for and that are found by matching , but the condition in will use the global value for , rather than the one found by matching the pattern.

As long as you make sure that the appropriate names are defined, it is usually most efficient to put conditions on the smallest possible parts of patterns. The reason for this is that the Wolfram Language matches pieces of patterns sequentially, and the sooner it finds a condition which fails, the sooner it can reject a match.

In[11]:= |

Out[11]= |

In[12]:= |

Out[12]= |

It is common to use to set up patterns and transformation rules that apply only to expressions with certain properties. There is a collection of functions built into the Wolfram Language for testing the properties of expressions. It is a convention that functions of this kind have names that end with the letter , indicating that they "ask a question".

IntegerQ[expr] | integer |

EvenQ[expr] | even number |

OddQ[expr] | odd number |

PrimeQ[expr] | prime number |

NumberQ[expr] | explicit number of any kind |

NumericQ[expr] | numeric quantity |

PolynomialQ[expr,{x_{1},x_{2},…}] | polynomial in , , … |

VectorQ[expr] | a list representing a vector |

MatrixQ[expr] | a list of lists representing a matrix |

VectorQ[expr,NumericQ],MatrixQ[expr,NumericQ] | |

vectors and matrices where all elements are numeric | |

VectorQ[expr,test],MatrixQ[expr,test] | |

vectors and matrices for which the function test yields True on every element | |

ArrayQ[expr,d] | full array with depth matching d |

Some functions for testing mathematical properties of expressions.

In[13]:= |

Out[13]= |

In[14]:= |

In[15]:= |

Out[15]= |

An important feature of all the Wolfram Language property‐testing functions whose names end in is that they always return False if they cannot determine whether the expression you give has a particular property.

In[16]:= |

Out[16]= |

In[17]:= |

Out[17]= |

Functions like IntegerQ[x] test whether x is explicitly an integer. With assertions like xIntegers you can use Refine, Simplify, and related functions to make inferences about symbolic variables x.

SameQ[x,y] or x===y | x and y are identical |

UnsameQ[x,y] or x=!=y | x and y are not identical |

OrderedQ[{a,b,…}] | a, b, … are in standard order |

MemberQ[expr,form] | form matches an element of expr |

FreeQ[expr,form] | form matches nothing in expr |

MatchQ[expr,form] | expr matches the pattern form |

ValueQ[expr] | a value has been defined for expr |

AtomQ[expr] | expr has no subexpressions |

Some functions for testing structural properties of expressions.

In[18]:= |

Out[18]= |

In[19]:= |

Out[19]= |

In[20]:= |

Out[20]= |

In[21]:= |

In[22]:= |

Out[22]= |

pattern?test | a pattern that matches an expression only if test yields True when applied to the expression |

Another way to constrain patterns.

The construction allows you to evaluate a condition involving pattern names to determine whether there is a match. The construction instead applies a function test to the whole expression matched by pattern to determine whether there is a match. Using instead of sometimes leads to more succinct definitions.

In[23]:= |

In[24]:= |

Out[24]= |

In[25]:= |

In[26]:= |

Out[26]= |

Except[c] | a pattern that matches any expression except c |

Except[c,patt] | a pattern that matches patt but not c |

In[27]:= |

Out[27]= |

In[28]:= |

Out[28]= |

In[29]:= |

Out[29]= |

Except[c] is in a sense a very general pattern: it matches *anything* except c. In many situations you instead need to use Except[c,patt], which starts from expressions matching patt, then excludes ones that match c.