9
$\begingroup$

I almost never work with Graph in Mathematica but lately I helped someone with it. For this, I tried to make an animation using Dynamic and an issue came up that I don't clearly understand: It seems when changing the state of a given graph using PropertyValue, this is not reflected in a Dynamic setting. Simple example:

g = RandomGraph[{5, 5}];
Dynamic[g]

If you now change for instance the styling of a vertex, the dynamic g is not updated

PropertyValue[{g, 1}, VertexStyle] = Blue

Question: Can someone explain what happens and why this does not work?


Further findings

When I tried to investigate in this behavior, something else came up. First, I used Refresh to force a reload of g which seemed to work

Dynamic[Refresh[g, UpdateInterval -> 1]]

but when I changed the state of g in a loop (or several times), then something mysterious happens

Do[
 Pause[1.3]; 
 PropertyValue[{g, RandomInteger[5]}, VertexStyle] = RandomColor[],
 {20}
]

Eventually, the graph g ends up being displayed as

Mathematica graphics

If you look at the InputForm of g and copy this into a new cell, you get a nice graph again, but it doesn't seem possible to change the representation of g again

$\endgroup$
  • 4
    $\begingroup$ Not by far being en expert in Graph-related stuff, one thing that came to mind is that Graph is a departure from usual Mathematica strategy for objects in that it is a mutable object. And mutation via property changes is a different mechanism than via variable changes etc. I'd just think that the integration of Graphs with Dynamic (concerning their internal state) is probably not as tight as it is between Dynamic and the core language. At least, this behavior doesn't come as a surprise for me, rather I'd be surprised if it worked flawlessly. $\endgroup$ – Leonid Shifrin Oct 22 '14 at 0:11
  • 2
    $\begingroup$ @LeonidShifrin The most unfortunate thing is that it is hard, even for advanced users, to look behind this curtain. One day everything works and you think you know how things are and the next day you cannot replace expressions inside Image or Graph and you have to find out the hard way that it is atomic now. And to say "Graph objects are atomic raw objects" in the very last paragraph of the help page doesn't help either, because it is not obvious what consequences this has. $\endgroup$ – halirutan Oct 22 '14 at 0:39
  • 2
    $\begingroup$ I totally agree. To my mind, this shows the limitations of the current model of the language, where the core is not cleanly separated from the rest, and where the rest can't be implemented using the core, but requires adding more C code for every new piece where performance is important. This certainly adds complexity to the language, and is perhaps on of its most fundamental problems, that eventually needs to be solved, for the language to successfully evolve. $\endgroup$ – Leonid Shifrin Oct 22 '14 at 0:46
  • 2
    $\begingroup$ @LeonidShifrin Graphs are immutable objects. Property only provides an efficient way to emulate mutation. $\endgroup$ – Charles P. Oct 23 '14 at 12:06
  • 2
    $\begingroup$ @CharlesP. Thanks for the comment. Would it be possible that you write up an answer and provide some details about why it goes wrong and how the faked mutability is achieved for Graph objects? I'm especially interested in whether a deep copy of a graph is made or whether (which is surely the case) the graph-data itself is kept and only the properties are created new. I guess this would be a very interesting insight for many of the advanced users here. $\endgroup$ – halirutan Oct 24 '14 at 0:41

Your Answer

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

Browse other questions tagged or ask your own question.