Re: sq[x_]:=x*x vs sq=Function[x, x*x]
- To: mathgroup at smc.vnet.net
- Subject: [mg113867] Re: sq[x_]:=x*x vs sq=Function[x, x*x]
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Tue, 16 Nov 2010 05:06:23 -0500 (EST)
Hi kj,
The two forms are only superficially the same. There are many differences
in both the semantics and the use. Below I will illustrate some.
Generally, pure functions are more common as defined at run-time and used
as arguments to higher-order functions which then call them. Pure functions
need
not be stored in a variable or given a name (although one can do it - as you
did).
They are less suited for type-checking and dispatching based on different
forms
of the argument (overloading). For example, restricting your argument to be
numeric
will require something like
sq = Function[x,If[NumericQ[x], x*x, $Failed]];
and here I assumed that the non-numeric input is an error. But what if I
want the function
to return unevaluated for non-numeric input? There is no easy way to achieve
that with
pure functions, while this is often useful.
Functions defined with patterns, OTOH, are not functions really - they are
global rewrite
rules which imitate the function call semantics. They are well - suited for
overloading and
argument checks based on patterns. For example, I may restrict:
sq[x_?NumericQ]:=x^2
In the absence of other definitions for sq, it will remain unevaluated on
non-numeric inputs
(which may be desirable). I can add more definitions as well, for example:
sq[x_Symbol]:=x
or whatever I need, including the convenient catch-all conditions such as
sq[___]:=$Failed
You can add all this to pure function with If or Switch or Which, but this
would arguably be
a worse solution.
The next issue is multiple arguments. This issue is best illustrated by the
following:
In[22]:= Function[x, x^2][2, 3]
Out[22]= 4
What happens is that the extra arguments to pure functions are silently
ignored by them.
This is a source of subtle and hard to track bugs. The pattern-defined
functions give you more
safety and control - the sq defined with the patterns as above would either
return unevaluated or
throw and error if you have defined a catchall condition.
Besides, there is no way to define a pure function with a variable number of
arguments
*and* attach some attribute to it, unless you use the undocumented form
Function[Null, body,{attributes}],
with <body> referring to ## (SlotSequence). With pattern-defined functions,
it is as easy as using the BlankSequence (__) or BlankNullSequence (___)
patterns, like x__, and assigning attributes
to the function name.
Speaking of more advanced uses, pattern-defined functions allow you to share
local variables
between the body and the condition. To illustrate, here is a model example:
a function to return
its integer argument squared when the number of primes between 1 and the
input is larger than half
the input, otherwise return the input.
Clear[f];
f[n_Integer] :=
Module[{nprimes = Length@Select[Range[n], PrimeQ]},
n^2 /; nprimes >= n/2];
f[n_Integer] := n;
In[59]:= f /@ Range[20]
Out[59]= {1, 4, 9, 16, 25, 36, 49, 64, 9, 10, 11, 12, 13, 14, 15, 16, \
17, 18, 19, 20}
What matters is that by using this construct, some non-trivial computation
may happen
in the body of the first definition, but, if the condition (involving the
results of computation)
has not been satisfied, the function goes on to the next rule in the list of
definitions, as if
the computation of the body of the preceding ones never took place. In this
primitive example
this looks like a weird way to solve the problem, but there are situations
where this construct
is indispensable. With pure functions, it will be much harder to do,
especially given that the
list of definitions can be manipulated dynamically at run-time (memoization
is a prime example).
Speaking of memoization, dynamic programming is another place where
rule-based functions
give you the edge. Here is a well-known memoization-based implementation for
Fibonacci
numbers:
Clear[fib];
fib[0] = fib[1] = 1;
fib[n_Integer?Positive] := fib[n] = fib[n - 1] + fib[n - 2]
You will have a hard time using a pure function to implement memoization.
And besides,
this is the simple form of memoization. You can also use the form where new
rules
containing patterns are formed at run-time and added to the function, which
would be
even harder to reproduce with the pure functions.
On the other hand, pure functions are useful to produce closures - functions
which encapsulate
(part of the) state of the surrounding environment. Since you don't need to
introduce names
for them, and since they are well - suited to be created at run-time, they
are typically a better
fit for this than functions based on patterns.
One more advantage of pure functions is that, at least in their anonymous
form (#-& notation),
they are typically faster than pattern-defined ones, since no
pattern-matching is taking place.
Moreover, they often can be compiled with Compile, which is not the case for
pattern-based
functions. This becomes now even more important for parts of the program
where speed is
relevant, given the new capabilities of Compile in version 8, such as
compilation to C or
automatic parallelization (multi-threading).
There are many more differences. I will mention just one more: the pattern -
defined functions
allow one to assign a wider set of attributes to them than the set of
attributes that make sense
to pure functions. Therefore, any problem which requires an attribute not
understood by pure
functions can not be solved with them (without re-implementing a part of the
pattern-matcher
and evaluator), but can be solved with the pattern-based ones.
To summarize, pure functions are useful in situations more typical for
programming / software
engineering problems, while pattern-defined functions (rules really) are
more useful for symbolic
programming. One more thing: because patterns and rules are at the heart of
Mathematica
evaluator, rule-based defintions often give you the most direct solutions,
since they can leverage
the most powerful features of Mathematica such as its term-rewriting engine
and the pattern-matcher.
Hope this helps.
Regards,
Leonid
On Mon, Nov 15, 2010 at 1:52 PM, kj <no.email at please.post> wrote:
>
>
> One could define a squaring function as either
>
> sq[x_] := x*x
>
> or
>
> sq = Function[x, x*x];
>
> Why/when would one want to choose one form over the other?
>
> TIA!
>
> kj
>
>