Recently, I learned that it is possible to assign "types" to function arguments in the definition of a function. Suppose I have a function stringFun
that does some operation (e.g., StringSplit
) on an input string str
. I could define the function in this way:
stringFun[str_] := StringSplit[str]
Or, I could define the argument str_
as being of type String
:
stringFun[str_String] := StringSplit[str]
What other argument "types" exist in Mathematica? Can I use, for example, Real
, List
, or Table
? I am using Mathematica 7, and I am having some difficulty locating a list of "types" in the documentation. Thanks for your time.
Answer
The notation foo[x_bar] := ...
merely states that you're defining the function foo
only for arguments that have the head bar
. Here's a silly example to show you that:
Clear@foo
foo[x_bar] := First@x
foo[bar[2, 3]]
(* 2 *)
foo[{2, 3}]
(* foo[{2, 3}] *)
Note that the head can be any symbol (function) and not necessarily types such as string/real/integer, etc. Since everything in Mathematica is an expression which has a Head
and possibly several Part
s, you can create your own patterns to work only with certain heads as in the example above.
Differences between patterns with specific heads (_h
) and equivalent pattern tests (_?hQ
)
Probably a more important distinction is the difference between specifying heads in patterns and pattern tests for the same head, i.e. between, say, x_Integer
and x_?IntegerQ
. On the surface, they behave the same:
Clear[f, g]
f[x_Integer] := x^2
g[x_?IntegerQ] := x^2
{f[4], g[4]}
(* {16, 16} *)
but they have two important distinctions that are worth highlighting
1. Behaviour in functions with the HoldAll
attribute
If your functions have the HoldAll
attribute (or any Hold*
attribute that has an equivalent effect on the pattern), the arguments are not evaluated by default. The latter form (using PatternTest
) forces evaluation of the argument and hence is useful in this case. For example, slightly modifying the above:
Clear[f, g]
SetAttributes[#, HoldAll] & /@ {f, g};
f[x_Integer] := x^2
g[x_?IntegerQ] := x^2
{f[2 + 2], g[2 + 2]}
(* {f[2 + 2], 16} *)
2. Calls to the main evaluator
As Leonid notes, matches (or not) for patterns of the type x_foo
are easily established by the pattern matcher, which can be very fast. On the other hand, the presence of a pattern test passes the evaluation to the main evaluator and introduces a sub-evaluation during the pattern matching and this can result in a big performance hit. As a simple example, consider the following:
Cases[Hold@{2, {Print["Evaluated!"]}, Pause[1.]}, _Integer, ∞] // AbsoluteTiming
(* {0.000028, {2}} *)
You can see that using the _Integer
pattern did not result in evaluation of either the Print
statement or the Pause
statement. Now compare:
Cases[Hold@{2, {Print["Evaluated!"]}, Pause[1.]}, _?IntegerQ, ∞] // AbsoluteTiming
(* Evaluated!
Evaluated!
Evaluated!
{2.000453, {2}} *)
You can see that the Print
statement was evaluated as Cases
walked through the expression tree (three times in total) and the Pause
statement was executed twice.
So the take away message is that if you want to do something like strong type checking, then avoid PatternTests
.
Comments
Post a Comment