One of the things I like about * Elixir* is its support for patterns at the core language level, not through library functions as in most other languages. This contributes to writing cleaner code, in my opinion.

Another environment that I am familiar with, namely * Mathematica*, boasts of (arguably) the most powerful symbolic programming language called

*.*

**“Wolfram Language”***is primarily used in mathematical and scientific programming. Patterns and Rules are all-pervasive in this language.*

**Mathematica**It is not fair to compare these two languages since each addresses a different kind of problem. * Elixir* is meant for highly scalable and fault tolerant general-purpose computing, whereas

*excels in complex symbolic (and numeric) computations, and over the years has been extended to include Neural Networks, Machine Learning, Natural Language Understanding, and so on.*

**Mathematica**In this article, I am going to compare the pattern matching ideas supported by * Elixir* and

*. Even this is a vast topic to address, so I will limit the discussion to the most striking aspects of pattern matching.*

**Mathematica**In the following sections, when I use the term * “Mathematica”*, I actually mean

*.*

**“Wolfram Language”**### The “=” Operator

Let us start with a simple idea. In * Elixir*, the operator

*is called*

**“=”***operator, not an*

**“Pattern Matching”***, although the operation can involve assignment. Look at the following example:*

**“Assignment Operator”**Here, the two patterns will match only if * X, Y, *and

*are bound respectively to 1, 2 and 3. This causes the values to be bound to the variables. The operator, in this case, behaves like the assignment operator.*

**Z**Here is a slight variation:

In this case, the first value of the LHS tuple is a constant and hence for the pattern to succeed, the RHS must have the same first element. The match succeeds since this is true, and * Y* and

*are bound as before.*

**Z**What happens if there is a pattern mismatch? The following example shows this.

I hope you understand what is going on. There are other interesting variations of the pattern matching operator in * Elixir*, but we will not get into those here.

Coming to * Mathematica*, the

*operator is the traditional*

**“=”***operator. No pattern matching is occurs here. The following example is similar to what we tried in*

**“Assignment”***:*

**Elixir**There is no surprise here since it merely involves assignment to the 3 variables on LHS. Now consider this:

Since we cannot assign to a constant on the LHS, the above fails. There is no attempt to * “pattern match”* in this case.

As the above examples show, the * “=”* operator in

*is more general than*

**Elixir***assignment operator.*

**Mathematica’s**### Case Statement

* Elixir* differs from most other programming languages in that it supports patterns (instead of simple conditions) in the

*statement. Here is an example:*

**“case”**Notice how we use a * “guard”* along with the first pattern to check if the second element of the list is greater than 10. The second pattern matches any element in the second position of the list. The third pattern only checks if the expression is a list without considering its internal structure. The last condition will match anything that hasn’t matched the earlier three patterns. In this case, the given list

*matches the first pattern.*

**“[1, 11, 3]”**Here is the same code as above but with the expression * “[1, 9, 3]”*. It matches the second pattern.

What is the result if we pass a 4-element list instead of a 3-element list? The third * “qualified”* pattern matches.

Finally, we pass a * “string” *instead of a list. In this case, the

*pattern matches!*

**“catch all”*** Mathematica* uses

*instead of*

**“Switch”***. Otherwise, the structure is quite similar. The following examples correspond to the above*

**“case”***examples:*

**Elixir**The operator * “/;”* puts constraints on the associated pattern. The following matches the second condition.

The following matches the third condition, a pattern that matches any * “List”*.

The last case corresponds to a “* non-List”* expression.

As you can observe, the behaviour is quite similar to * Elixir*.

### Patterns and Guards in Functions

Both * Elixir* and

*allow*

**Mathematica***(or conditions) to be associated with function definitions. This is quite powerful. Let us go through an example to see how this is done.*

**“guards”**Suppose that we want to compute the * n^{th} “Fibonacci”* number. Here is one way to do this in

*:*

**Elixir**Instead of coding the different trivial cases in a single function, we split the logic across multiple definitions. Notice also, how we are able to associate a * “guard”* or condition with the third definition to check if the passed argument is an integer (we take for granted that the argument is positive).

Here is yet another way. We have merged the first two definitions by introducing a * “guard”*.

It is important to keep in mind that * Elixir* tries the functions in the order of definition. So, if we change the order as in the following case, it will not work.

How do we write this function in * Mathematica*? The following implementation corresponds to the first version we wrote in

*.*

**Elixir*** Mathematica* too allows us to use

*as part of function definition. The code given below matches the second version we wrote in*

**“conditions”***.*

**Elixir**A nice thing about * Mathematica* is that there is no restriction on the order in which the definitions must be provided. So, even the following will work correctly.

#### Arbitrary Pattern-based Transformations in Mathematica

Unlike * Elixir*,

*allows us to define functions that work with symbolic expressions. Take a look at the following snippet:*

**Mathematica**The first line above defines a function that takes two arguments. The first argument can be anything as denoted by the pattern * “x_”*. The second argument must be an expression of the form

*. Given two arguments like this, this function applies another function*

**“x_ raised to the power of anything”****“p”**to

*(remember*

**2 times “x”***refers to the first argument).*

**“x”**The second and third lines show what happens when this function is called with * “(m+n)”* and

**. The fourth and fifth lines show another valid invocation example. In both these cases, the**

*“(m+n)*^{3}”*is maintained and hence the expected transformation takes place. The last two lines show what happens when the second argument does not satisfy the required structure (it uses*

**argument structure***instead of*

**“n”***).*

**“m”**As the final example of pattern transformations, * Mathematica* has a special

*operator*

**“substitution”***that can be applied to an arbitrary expression to transform it into another expression. Here is an example:*

**“//.”**Here, the expression to the left of * “//.”* Is

*. To the right of*

**“X**^{2}+ Y^{2 }+ Z”*we have a list of substitutions to apply. The substitution operator*

**“//.”***applies the given values to the LHS expression until it changes no more. Finally, we get the answer*

**repeatedly***.*

**“16”**Of course, the substitution can also be symbolic. Look at this:

Here we transform one symbolic expression to another. Such transformations are quite common in the domain of * Mathematica*.

In my view, * Mathematica’s* pattern matching capabilities are richer and more powerful than

*. What I have covered is just a tiny part of what*

**Elixir***allows.*

**Mathematica**Hope you enjoyed reading this article. Have a nice weekend and a wonderful week ahead!

## Recent Comments