Function Repository Resource:

SameExpressionShapeQ

Check if expressions have the same shape

Contributed by: Richard Hennigan (Wolfram Research)
 ResourceFunction["SameExpressionShapeQ"][expr1,…,exprn] yields True if all the expri have the same shape and yields False otherwise.

Details and Options

Two expressions expr1 and expr2 are defined to have the same shape when, for any valid position specification p1,,pn, the subexpression expr1[[p1,,pn]] exists if and only if the subexpression expr2[[p1,,pn]] exists.

Examples

Basic Examples (1)

Check if expressions have the same shape:

 In[1]:=
 Out[1]=
 In[2]:=
 Out[2]=
 In[3]:=
 Out[3]=
 In[4]:=
 Out[4]=
 In[5]:=
 Out[5]=

Scope (5)

Associations must agree on keys:

 In[6]:=
 Out[6]=
 In[7]:=
 Out[7]=

A reordering of keys only changes the shape if the corresponding values have a different shape:

 In[8]:=
 Out[8]=
 In[9]:=
 Out[9]=

Compare expressions without evaluation:

 In[10]:=
 Out[10]=
 In[11]:=
 Out[11]=

The Unevaluated wrapper is not considered part of the expression:

 In[12]:=
 Out[12]=

Any number of arguments can be given:

 In[13]:=
 Out[13]=
 In[14]:=
 Out[14]=

Applications (4)

Check if ragged arrays have compatible dimensions:

 In[15]:=
 Out[15]=
 In[16]:=
 Out[16]=
 In[17]:=
 Out[17]=

These are compatible:

 In[18]:=
 Out[18]=
 In[19]:=
 Out[19]=

These are not:

 In[20]:=
 Out[20]=

Attempting to add them results in an error:

 In[21]:=
 Out[21]=

Properties and Relations (6)

An expression is always the same shape as itself, so SameExpressionShapeQ is always true for a single argument:

 In[22]:=
 Out[22]=

SameExpressionShapeQ[] is defined to be True:

 In[23]:=
 Out[23]=

This is consistent with the behavior of SameQ:

 In[24]:=
 Out[24]=

For normal expressions, SameExpressionShapeQ[expr1,,exprn] is effectively equivalent to testing if all the ExpressionGraph[expri] are equivalent under IsomorphicGraphQ:

 In[25]:=
 In[26]:=
 Out[26]=
 In[27]:=
 Out[27]=

Compare using TreeForm:

 In[28]:=
 Out[28]=

These two have different shapes:

 In[29]:=
 Out[29]=
 In[30]:=
 Out[30]=

Compare using TreeForm:

 In[31]:=
 Out[31]=

Represent the underlying "shape" of expressions by replacing all atomic values with one identical value:

 In[32]:=
 In[33]:=
 Out[33]=
 In[34]:=
 Out[34]=
 In[35]:=
 Out[35]=

These have the same shape:

 In[36]:=
 Out[36]=
 In[37]:=
 Out[37]=

These do not:

 In[38]:=
 Out[38]=
 In[39]:=
 Out[39]=

Highlight differences:

 In[40]:=
 Out[40]=

Another way to understand the shape of a normal expression is by looking at the positions of all subexpressions:

 In[41]:=
 In[42]:=
 Out[42]=
 In[43]:=
 Out[43]=
 In[44]:=
 Out[44]=

When the positions are the same, the expressions have the same shape:

 In[45]:=
 Out[45]=
 In[46]:=
 Out[46]=
 In[47]:=
 Out[47]=
 In[48]:=
 Out[48]=

For associations to be considered the same shape, their corresponding parts must be the same shape whether indexed by key or numeric position:

 In[49]:=

Check subexpressions by key indexing:

 In[50]:=
 Out[50]=

Check subexpressions by their ordinal positions:

 In[51]:=
 Out[51]=

Since both methods of indexing are in agreement, these have the same shape:

 In[52]:=
 Out[52]=

Here is another Association that only differs in key order:

 In[53]:=

Check subexpressions by key indexing:

 In[54]:=
 Out[54]=

Check subexpressions by their ordinal positions:

 In[55]:=
 Out[55]=

It is not considered the same shape, since indexing by numeric position yields incompatible subexpressions:

 In[56]:=
 Out[56]=

Possible Issues (2)

For associations, SameExpressionShapeQ considers keys to be structural positions rather than subexpressions:

 In[57]:=
 Out[57]=
 In[58]:=
 Out[58]=

For lists of rules, the keys are normal subexpressions:

 In[59]:=
 Out[59]=

Version History

• 1.0.0 – 24 August 2020