Re: Assignment problem
- To: mathgroup at smc.vnet.net
- Subject: [mg86362] Re: Assignment problem
- From: Szabolcs Horvát <szhorvat at gmail.com>
- Date: Sun, 9 Mar 2008 05:04:23 -0500 (EST)
- Organization: University of Bergen
- References: <fqo8o1$suo$1@smc.vnet.net> <fqqs3b$kf5$1@smc.vnet.net> <fqtqin$d3j$1@smc.vnet.net>
Helen Read wrote:
> Albert Retey wrote:
>> Note that usually using a Do-Loop is the better choice in Mathematica:
>
> (as compared with a For loop).
>
> This is the second post I've seen today that says that Do loops are
> better than For loops in Mathematica. What is better about them (aside
> from slightly simpler syntax)?
If it were up to me, I would ban the For construct from the Mathematica
language. We wouldn't loose anything by eliminating For.
1. It is completely redundant. It is almost always used to iterate
over a numeric range, and Do[] can do this as well. In the rare cases
when it is used in a different way, it can be easily replaced with While[].
2. When newcomers to the language want a looping construct, the first
thing they search for is "for", because this is what they are familiar
with from other languages. This results in abominations like this:
l = {};
For[i = 1, i <= 10, i++,
AppendTo[l, f[i]];
]
(It's easy to pick up the habit of using ; everywhere to suppress all
that "useless" output. I know that it's not required after AppendTo)
Now this example is too simple to show how unreadable this can get ...
but add a few more lines of code with some semicolons and If[]
constructs, and it'll become terrible (partly because the roles of , and
; in For are reversed in Mathematica compared to C-like languages).
3. For[] usually results in slow code, mainly because assignment (and
changing the values of variables) is slow in Mathematica. It changes
the value of "i" in every cycle, and it encourages things like the slow
AppendTo in the example.
4. Using For[] is error-prone.
When using For[], one is forced to create an otherwise useless global
variable, "i". Since this "i" is just an artifact of looping, and it is
not associated (in one's mind) with any object that is actually *used*
during the calculations, it is easy to forget about it's existence, and
use it again in a symbolic context (which will result in errors because
it already has a value).
Another possiblity of error is to just run the For[] loop without the
initialization l = {}, which will create unexpected results with no
error or warning message.
5. Once a newcomer has found For[], s/he might just stick to it,
thinking that it is "the main looping construct". Soon s/he might
conclude that Mathematica is an ungly and difficult to use language, and
s/he will be right if s/he is mostly using the common subset of
Mathematica and C.
The path to a more Mathematica-like style is much easier to find when
one starts with Do[], and not For[]. Just think about how similar
Table[] and Do[] are. The above example should have been implemented as
Table[f[i], {i, 10}]
Here 'i' is localized automatically, and the results are collected and
returned as a list automatically. Using Table[] is shorter and more
readbale. It is also *much* faster than using AppendTo[].
I think that For[] is completely useless for experienced users (in the
sense that its absence would not make a difference), but it can cause
considerable damage when newbies start using it. I don't understand at
all why it was included in the language. Maybe it was just a marketing
decision, so those coming from other languages will feel more at home,
and Mathematica can be advertised as a multiparadigm programming system
(which it is even without For!). I don't think that a C programmer who
is transliterating from C to Mathematica will feel at home in
Mathematica ...
Note that I am *not* arguing against the use of a procedural style in
Mathematica. In fact, a procedural approach is the best solution to
*certain* problems. But when newbies find For[] they tend to not look
further and not learn the style of programming which makes Mathematica
really effective. For[] also brings out most of the disadvantages of
using a procedural style in Mathematica: bad performance because of
constantly changing variables; too much verbosity and a too "low-level"
approach to problems; and leaking of temporary variables into the global
namespace (because of the way scoping works in Mathematica).