Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I noticed this fact, that may be misleading for programmers used to C language.

In Mathematica, if you have a function f[] and an array v, and you write

v[[ f[] ]]++

the function f is called twice. Probably experts knows this very well, but I used Mma for years ignoring this. Normally this behaviour is harmless, but this should be taken into account if f is costly, has side-effects or can return different values based on the same input.

Indeed, I realized this property of ++ because of this:

t={0,0,0}; r[]:=RandomInteger[{1,3}]; Do[t[[r[]]]++,{10000}]; Print[t," ",Total[t]]

where I increment a random entry of t 10000 times, but at the end the sum of entries of t is not 10000.

This is insidious for C programmers, because in C if you write a similar code v[f()]++, the function f() is called just once.

I would like to ask if this semantic of ++ is somehow "forced" by the overall structure of Mathematica language or if they could have implemented it differently.

share|improve this question
12  
The interesting thing is that me and most other people I know who use Mathematica don't run into problems like these. The reason is that we program functionally, which is a more natural way to use Mathematica. It's true for any language that if you try to program it like another language, you're going to have a bad time. – Searke Feb 17 at 20:55
6  
I split my time between Mathematica (fast to code) and C (fast). I generally tend to use functional programming in Mma (I never in my life used a For[]), but ++ is so basic I did'nt notice the HoldFirst attribute. – Giovanni Resta Feb 17 at 21:01
up vote 24 down vote accepted

I believe Increment (more accurately PreIncrement as george2079 noted) is essentially this:

SetAttributes[inc, HoldFirst]
inc[a_] := a = (a + 1)

This exhibits the same behavior, e.g.

f[] := (Print[#]; #) &@RandomInteger[{1, 3}]

v = {0, 0, 0};
inc @ v[[f[]]];
2

1

Here f[] is evaluated twice because parameter a is used twice within Set. On the right hand side it draws the actual element to which to add one, and on the left hand side it is evaluated to get a valid index for assignment. (HoldFirst prevents the expression from being evaluated before it is substituted into the definition; a requirement for such an assignment to work correctly.)

This does follow from Mathematica design as a natural way to implement something like this, and evaluation follows established, if at times confusing, rules. This becomes apparent if one tries to avoid this problem. How exactly does one prevent double evaluation in a generic way? belisarius recommended in a comment memorizing f but that is a specific solution, not a broad one.

For the specific case of a Part one could add a rule:

inc[a_[[p__]]] := With[{eval = p}, a[[eval]] = (a[[eval]] + 1)]

Test:

v = {0, 0, 0};
inc @ v[[f[]]];
v
3

{0, 0, 1}

However this introduces a special case, and rather than clarifying behavior it may serve to confuse instead. After observing the above behavior one might expect this also to evaluate f[] only once, but it does not:

w[_] = 0;
inc @ w[f[]];
2

3

So we may end up chasing our tails trying to pin down special cases, rather than accepting the simple rule inc[a_] := a = (a + 1) and the evaluation it implies.


Rethinking my assertions

This answer has proven unexpectedly popular, and in such cases I try to "channel" Leonid and take it to the next level in an effort to deserve the attention.

While I believe what I wrote above holds if we are using the standard evaluation elements to emulate this functionality it is also true that there is nonstandard evaluation in various parts of the familiar language, one of these cases being Set itself. Consider that the statement v[[ f[] ]] = 1 manages to correctly change a part of the vector assigned to v, rather than generating an error as would happen if the entire LHS were fully evaluated, and yet it does evaluate f[] rather than attempting to assign something to part "f[]" verbatim. This partial LHS evaluation has been discussed before:

It occurs to me that Increment and PreIncrement could potentially use a similar special evaluation in an attempt to prevent exactly the kind of double evaluation under discussion. Unfortunately I cannot think of any simple way to emulate this special LHS evaluation in order to implement this myself. I shall continue to think on the problem, but perhaps WReach or Leonid will have an implementation to offer in the mean time.

share|improve this answer
2  
Technically you have cloned PreIncrement. (Same core issue though) – george2079 Feb 17 at 21:08
    
@george2079 Thanks for pointing that out! – Mr.Wizard Feb 17 at 21:09
    
Thanks for the answer. Once one knows about this, preventing the problem is easy. I think it would be nice a little note of warning in the "Possible issues" of the documentation of Increment, PreIncrement, and also AddTo. – Giovanni Resta Feb 17 at 21:21
1  
@GiovanniResta There's a feedback button at the bottom of each online documentation page. You can use that to suggest it. – Szabolcs Feb 17 at 21:39
1  
@Algohi I do understand your point. (At least I think so.) However I personally find that behavior at least as confusing as the behavior than originated this question. If one is using side-effect code this will be even more bug-like than the original behavior. If you do prefer modifying the behavior of Increment why not avoid the multiple evaluation entirely? Unprotect[Part]; Increment[ a_[[p__]] ] ^:= With[{eval = p}, (a[[eval]] = a[[eval]] + 1) - 1 ] – Mr.Wizard Feb 22 at 17:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.