Is it possible to use PropertyValue to modify properties of Graph objects in a list?

Question

This post can be seen as a follow up to Property assignment on a graph vertex using PropertyValue does not work inside a function.

I have defined a function:

Clear[AddStone];
SetAttributes[AddStone, HoldFirst];
AddStone[board_, v_, s : (white | black | empty)] := (PropertyValue[{board, v}, VertexState] = s)

This function should change the VertexState property of vertex v in a graph board to one of white, black, or empty. It works as expected (credits to @Heike), as the execution of:

 board = GridGraph[{5, 5}];

 AddStone[board, 8, white]

 PropertyValue[{board, 8}, VertexState]

demonstrates.

But now suppose that I need to change the property VertexState of vertices of Graphs in a list. For example:

 list = {CycleGraph[5], KaryTree[8]}

The following code doesn't work as expected:

 AddStone[list[[1]], 3, white]

It returns the error:

Set::setraw: "Cannot assign to raw object PropertyValue[{list[[1]],3},VertexState]=white."

From the discussion here, I have an idea of why this happens (though a clear explanation would be appreciated). So I need an alternative way to change the properties of the graphs in a list, when all I have is the list (instead of references to the graphs themselves). I know I could apply SetProperty to the list and obtain a new list of graphs with the updated properties, but SetProperty is slower than PropertyValue because it creates a new copy of the graph with the property changed instead of modifying the original graph.

Summing up, here is my question: Is there a way to use PropertyValue to modify the properties of graphs in a list?

Answer 1

You could try using SetProperty instead of PropertyValue:

SetAttributes[AddStone2, HoldFirst];
AddStone2[board_, v_, s : (white | black | empty)] :=
   board = SetProperty[{board, v}, VertexState -> s]

list = {CycleGraph[5], KaryTree[8]};
AddStone2[list[[1]], 1, black];

PropertyValue[{list[[1]], 1}, VertexState]

(* out: black *)

Answer 2

Honestly it's not quite clear to me to which extent Graph is to be seen as an internal atomic datatype or rather just an expression with head Graph. AtomicQ returns True which indicates the former, but other than that it behaves a lot like the latter. If it really is an internal datatype, my solution might be inefficient and rather a workaround, but it does the job: Just add the following pattern to your AddStone definitions:

AddStone[list_[[idx__]], v_, s : (white | black | empty)] := 
 Module[{g = list[[idx]]},
  AddStone[g, v, s];
  list[[idx]] = g;
  ]

And you can use something like:

AddStone[listofgraphs[[1]], 3, white]

but also:

AddStone[arrayofgraphs[[1,2]], 3, white]

I would consider it at least an oversight that PropertyValue[{g[[1]],1},prop]=val; doesn't work out of the box, especially since PropertyValue[{g[[1]],1},prop] works as expected. I think this could and should be added to PropertyValue.

Edit: I think Heikes answer is the way to go. I'll leave this here since it might be instructive for similar cases where no better alternative is available.

Edit: Some notes about memory efficiency which my remark about whether Graph is really an internal datatype is all about: If Graph is just a wrapper for a normal expression I'd expect exactly one "real" copy to be made, whichever approach you take. The second copy will actually not cause any extra memory to be used due to the "copy on write" that Mathematica uses for general expressions, AFAIK. If it is an internal datatype it might be possible to change it in place, and that would of course be lost with my above way of doing things. But then, I think you are out of luck if only PropertyValue applies changes in place but SetProperty doesn't. You should also note that if Graph is an internal datatype, SetProperty could in principle make changes in place even without having an Hold attribute. From some superficial tests I think that Graph does behave a lot like a normal expression, though. Since it is quite difficult to make precise forecasts how much extra memory each approach will need and how fast they'd be I'd just try that out. My own tests look like what I did suggest could be worth a try, despite the fact that an extra copy is made.