Michael,

SetDelayed is still most often used for "function"-like definitions. The advantage of SetDelayed is that it delays evaluation of the right side until the arguments are presented (at evaluation time). This is useful in most cases because it fits the "usual" model of define the function and, like a C program, substitutes those arguments at "run time".

You got burned not because you used SetDelayed, but as Gianluca pointed out, you used the variable n twice -- for two different things. This is equivalent in C to using a Macro for the inner definition -- the macro is blindly substituted and if its variable conflicts with the function you will have a bug. In C if n were a global variable and you used variable n in both an inner function and some outer function when you expected it to be local you would also have had a bug.

Your problem arose because the variable n does NOT appear in the pattern -- it is embedded in the right hand side. If n were part of the pattern it would behaved more like a C function and less like a C macro.

As Yehuda pointed out, the most important place that you really have to reconsider delayed vs immediate evaluation is for efficiency (especially for plotting complicated things). It makes no sense to recompute entire expressions over and over again so the times that I think about evaluation order/delay is in situations of repetitive computations.

As a workflow, I usually start with SetDelayed definitions as they are most "C" like in that I can later feed them arguments.

I hope this helps.

There is this book: Fast Introduction for Programmers:

http://www.wolfram.com/language/fast-introduction-for-programmers/en

but I am not sure if this is what you want.

Thank you, everyone. I did not realize that DelayedSet gets literally substituted (like a define in C). Back to reading about basics...

My bad about those rules: this UI is quite different from what I got used to (on typical forum) and confused me quite a bit -- I don't remember running across them.

See what happens if you use a different variable, for instance k, instead of n in the definition of M, leaving everything else the same:

Clear[F, G, M];
F[x_] := UnitStep[x]*UnitStep[10 - x]*1/10
G[x_] := DiscreteConvolve[F[n], F[n], n, x]
M[x_] := DiscreteConvolve[G[k], F[k], k, x]
DiscretePlot[{F[x], G[x], M[x]}, {x, 0, 30}]

In your definition of M[x_] you call G[n], which translates to

DiscreteConvolve[F[n], F[n], n, n]

which is trouble, because the summation index is the same as the parameter. Look at the difference between G[m] and

G[n] // PiecewiseExpand

The problem goes away with immediate definition = instead of your delayed definition :=

Unfortunately DiscretePlot does no check on the variables it is fed.

Hi First, your code is highly inefficient, since you do not really compute the discrete convolution until you call the graphics, and then for each value of the horizontal axis you repeat the convolutions. This happens since you used := (SetDelayed) in place of = (a simple Set). So,

F[x_] = UnitStep[x]*UnitStep[10 - x]*1/10;
DiscretePlot[F[n], {n, -5, 15}]
G[x_] = DiscreteConvolve[F[n], F[n], n, x];
DiscretePlot[G[n], {n, -5, 22}, PlotRange -> All]
M[x_] = DiscreteConvolve[G[n], F[n], n, x];
DiscretePlot[{F[x], G[x], M[x]}, {x, 0, 30}]

F is defined for a support range between 0 and 10 therefore G has a support range of 20. Changing the support range to 1 (in place of 0) shows the expected results HTH yehuda