5
$\begingroup$

Could someone please explain the following behaviors?

I don't know if it's related to TrackedSymbols, assignment, evaluation of rhs of assignment, or initialization in DynamicModule.

DynamicModule[{x, y},
 Column[{
   Slider[Dynamic[x]],
   Dynamic[Refresh[y = x, TrackedSymbols -> {y}]],
   Dynamic[y]
   }]]

Without the initilization of x and y, only the 2nd Dynamic updates.

And, if y=x is changed to y=x+1, neither Dynamic updates;

y=x++, or RandomReal[], which of course makes Slider pointless, both Dynamic update.

Now if I change the initilization part to e.g. x=0,y=0,

then in the case of y=x, y=x+1, y=x++, neither Dynamic updates;

only those with y=RandomReal[] updates.

I don't know if the above is useful in real life. I just create them to understand better the behavior Refresh wrapped in Dynamic and if it's OK/meaningful to use assignment in Refresh.

Thanks a lot.

=================================

I put my newest questions here for better readability.

I'd like ask regarding #4 of the generic situation.

Q1: Is my understanding correct? when Dynamic@Refresh runs for the 1st time, y's state is changed from no_initial value to y=0, which is passed by x via assignment.

Q1-1: And when y is provided an initial value of 0, in the case of y=x++, y's state doesn't change, when Dynamic@Refresh runs for the 1st time, and therefore, it doesn't run into Infinity, unless use ++x, as you suggested.

Q2: When I drag the slider thumb, why the newest value of x can't be passed to y via assignment? Is it because I set explicit trackedsymbol to {y}. This part is still quite confusing for me. (The situation with x++ or RandomReal[] isn't the same as y=x+1, since neither of them is related to slider).

$\endgroup$
7
$\begingroup$

generic situation

So what happens when you run the code from above:

  1. during evaluation nothing special because Dynamic holds it's arguments till it is displayed

  2. during typesetting all those gui elements are converted to appropriate boxes, rendered and the FrontEnd starts to care about updating DynamicBox or handle SliderBox

  3. there is no guarantee that Slider will give x it's initial 0 before the subsequent Dynamics are rendered. It will be the rat race but here nothing fancy happens.

    so Slider gives x a value 0

  4. Dynamic[Refresh[.. is displayed for the first time and y=x is run. It changes y state so it makes parent Dynamic being refreshed. Next time x is the same so it stays as it was.

  5. Dynamic[y] is displayed showing 0 as expected

  6. From now on nothing fancy should happen. Slider changes x and none of Dynamics below should be updated. The first one has an explicit list of tracked symbols while the second is only y dependent.

You can read more how dependency tree is build in:

https://mathematica.stackexchange.com/a/138455/5478

Now let's talk about your doubts.

specific cases

  • Without the initilization of x and y, only the 2nd Dynamic updates.

    This should not happen and I'd call it a bug, neither of them should be triggered according to what I said above.

    Strange things with crude Dynamic[var] happen more often, read more in:

    What is the difference between Dynamic[x] and Dynamic[ h[x] ] for DynamicModule variables?

    You can confirm that simple change to Dynamic[{y}] makes it behave as expected.

  • And, if y=x is changed to y=x+1, neither Dynamic updates;

    Correct and expected (see 7). But notice what happens at the beginning:

      Refresh[Print[RandomReal[]]; y = x + 1, TrackedSymbols -> {y}]
    

    This shows the Print is called 2-3 times, it is because Slider gives x initial value 0 then when the second dynamic is displayed y gets x+1 which triggers this dynamic again because y was changed. x hasn't changed though so next time y will get the same value, 1, and won't be triggered.

    And the Slider does not matter. Only the very first rendering made that happen.

  • y=x++, or RandomReal[], which of course makes Slider pointless, both Dynamic update

    Unlike the previous case, now x++ changes each time and so does y and so Refresh is triggered and x++ again and so on.

    Related topic:

    Problem with UpdateInterval

  • Now if I change the initilization part to e.g. x=0,y=0, then in the case of y=x, y=x+1, y=x++, neither Dynamic updates;

    y=x, y=x+1 are easy and explained before. The last one is interesting, why doesn't it run into Infinity? Because x++ returns previous value of x which was 0, the same as y's so the outer dynamic wasn't triggered and it won't anymore due to TrackedSymbols.

    But change x++ to ++x :) this returns new value of x so the loop begins.

  • only those with y=RandomReal[] updates.

    again, assignment to y, each time different value makes it being triggered and so on.

  • I don't know if the above is useful in real life. I just create them to understand better the behavior Refresh wrapped in Dynamic and if it's OK/meaningful to use assignment in Refresh.

    Here is a whole topic about usefulness or not of Refresh:

    What is the point of Refresh if Dynamic has an UpdateInterval option?

$\endgroup$
  • $\begingroup$ Thank you very much for your prompt and detailed answer. I'd like to ask about generic situation #4. Q1: you mean, the state of y is changed from no_initial value to y=0, which passed by x via assignment? Q2: why when I drag slider to change the value of x, but its newest value can't be passed to y? Only because the trackedsyombol is explicitly set to {y}, and therefore, doesn't work? Thanks again. $\endgroup$ – Bemtevi77 Apr 30 '17 at 11:18
  • $\begingroup$ @Yaofeng yes, from 'no value' to 0 and yes all those updates are triggered by the Dynamic[Refresh[.., slider here should have no influence. $\endgroup$ – Kuba Apr 30 '17 at 14:34
  • $\begingroup$ sorry, I'm still confused. When slider is dragged, x's value is updated in the kernel, and this newest value won't be passed to y via assignment (y=x)? If not so, how come x++ works, which, I think, is also passing x's value to y ? Thanks again. $\endgroup$ – Bemtevi77 Apr 30 '17 at 16:05
  • $\begingroup$ y = x++ is run from Dynami[Refresh[, it changes y value so Refresh is triggered again. When x is changed via Slider then only x is changed. y=x does not care. Don't be sorry, I'm not the best in explaining stuff :) $\endgroup$ – Kuba Apr 30 '17 at 16:08
  • $\begingroup$ this means: 1. x++ works because the change of x value occurs within Dynamic[Refresh[; it has nothing to do with Slider. 2. There isn't any communication between Slider[Dynamic[ and Dynamic[Refresh[, even though both contain x ? If so, is this due to the HoldFirst attribute of Dynamic or some other reason ? $\endgroup$ – Bemtevi77 Apr 30 '17 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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