limiting recursion as two interdependent values change c#
-
assume you have a simple working social network (I wrote one as an experiment): nodes are class Person ... identity properties edges are class Edge ... FromNode, ToNode, Intensity (nullable double): they are one way following standard graph conventions. both and Node have CRUD methods in place ... working. if Intensity value is null: it means FromNode to ToNode has no connection when Intensity's value changes: it raises a PropertyChanging ... the change can be canceled Iimplemented, working) problem scenario: an Edge Joe has a ToNode Mary and Intensity 50. an Edge Mary has a ToNode Joe and Intensity 50 Joe's Node changes Intensity to 100 and raises PropertyChanging which Joe subscribes Mary to. You see the possibility of runaway recursion if both Edges subscribe PropertyChanging to each other. how to limit recursion ? how to limit recursion when an Edge Intensity wants to raise raises PropertyChanging when a certain magnitude of change occurs ? keep a count ? enforce a limit ? appreciate your thoughts !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
assume you have a simple working social network (I wrote one as an experiment): nodes are class Person ... identity properties edges are class Edge ... FromNode, ToNode, Intensity (nullable double): they are one way following standard graph conventions. both and Node have CRUD methods in place ... working. if Intensity value is null: it means FromNode to ToNode has no connection when Intensity's value changes: it raises a PropertyChanging ... the change can be canceled Iimplemented, working) problem scenario: an Edge Joe has a ToNode Mary and Intensity 50. an Edge Mary has a ToNode Joe and Intensity 50 Joe's Node changes Intensity to 100 and raises PropertyChanging which Joe subscribes Mary to. You see the possibility of runaway recursion if both Edges subscribe PropertyChanging to each other. how to limit recursion ? how to limit recursion when an Edge Intensity wants to raise raises PropertyChanging when a certain magnitude of change occurs ? keep a count ? enforce a limit ? appreciate your thoughts !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
BillWoodruff wrote:
You see the possibility of runaway recursion if both Edges subscribe PropertyChanging to each other.
If they also change their Intensity in response to that event, sure. (if something else then I don't know what you mean)
BillWoodruff wrote:
keep a count ? enforce a limit ?
Sure, I guess? But where do you keep that count and whose responsibility is this etc, idk ultimately it seems like a bit of hack. Reading between the lines, here's what I think is going on: - You have some sparse matrix. - You updated one entry in it. - You need to run some algorithm to restore some property. So here's my proposal: run that algorithm on the matrix. That doesn't sound it means anything, but it does. It means, forget imbuing the individual edges with agency (at least in this context). It's the matrix as a whole that has a property that you want to restore, and the algorithm works on the matrix as a whole (hopefully not every entry needs to be changed). There's no difficulty now in running a limited number of iterations of an incremental algorithm or anything of that nature. You can just do that, explicitly, in one place. Such a zoomed-out view may also help when implementing other matrix-based graph algorithms such as eigenvector centrality or whatever (do social networks use that? I don't know what social networks actually *do* to be honest). But I don't really know what you're doing, maybe none of this applies to your situation.
-
BillWoodruff wrote:
You see the possibility of runaway recursion if both Edges subscribe PropertyChanging to each other.
If they also change their Intensity in response to that event, sure. (if something else then I don't know what you mean)
BillWoodruff wrote:
keep a count ? enforce a limit ?
Sure, I guess? But where do you keep that count and whose responsibility is this etc, idk ultimately it seems like a bit of hack. Reading between the lines, here's what I think is going on: - You have some sparse matrix. - You updated one entry in it. - You need to run some algorithm to restore some property. So here's my proposal: run that algorithm on the matrix. That doesn't sound it means anything, but it does. It means, forget imbuing the individual edges with agency (at least in this context). It's the matrix as a whole that has a property that you want to restore, and the algorithm works on the matrix as a whole (hopefully not every entry needs to be changed). There's no difficulty now in running a limited number of iterations of an incremental algorithm or anything of that nature. You can just do that, explicitly, in one place. Such a zoomed-out view may also help when implementing other matrix-based graph algorithms such as eigenvector centrality or whatever (do social networks use that? I don't know what social networks actually *do* to be honest). But I don't really know what you're doing, maybe none of this applies to your situation.
Thanks, Harold ! I did not explain adequately. Joe and Mary's Edges are reciprocal. Joe changes the intensity value for Mary ... raises OnPropertyChanging. Mary subscribes to Joe's OnPropertyChanging. Joe's change calls Mary's OnPropertyChanging handler. Based on Mary's intensity value and Joe's new value ... Mary changes her value and raises her OnPropertyChanging event that Joe subscribes to. Then, you get runaway recursion, and stack overflow. Right now, i am thinking of writing a ChangeManager class outside Edge. cheers, bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, Harold ! I did not explain adequately. Joe and Mary's Edges are reciprocal. Joe changes the intensity value for Mary ... raises OnPropertyChanging. Mary subscribes to Joe's OnPropertyChanging. Joe's change calls Mary's OnPropertyChanging handler. Based on Mary's intensity value and Joe's new value ... Mary changes her value and raises her OnPropertyChanging event that Joe subscribes to. Then, you get runaway recursion, and stack overflow. Right now, i am thinking of writing a ChangeManager class outside Edge. cheers, bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
This sounds exactly like a good case for making the matrix responsible for the reciprocity invariant.
Or just call "OnPropertyChanged", without a name, once, at the end of the "update" cycle. The binding engine then simply refreshes all bound properties. The issue is that most don't benchmark "PropertyChanged" and "optimize" it when it makes no difference (due to a given scenario's low "frame rate"). Users do not perceive "lag" below 100ms.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Or just call "OnPropertyChanged", without a name, once, at the end of the "update" cycle. The binding engine then simply refreshes all bound properties. The issue is that most don't benchmark "PropertyChanged" and "optimize" it when it makes no difference (due to a given scenario's low "frame rate"). Users do not perceive "lag" below 100ms.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
note: i am using OnPropertyChanging here.
Gerry Schmitz wrote:
The binding engine then simply refreshes all bound properties.
Source of this ? Speed is the issue here: preventing runaway recursion is.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
This sounds exactly like a good case for making the matrix responsible for the reciprocity invariant.
Thanks, Harold, What does "matrix" mean here ? How can you have "reciprocity" and "invariant." i'm dense, and, light-headed, these daze :wtf:
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
Thanks, Harold, What does "matrix" mean here ? How can you have "reciprocity" and "invariant." i'm dense, and, light-headed, these daze :wtf:
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
Your data structure is really a sparse matrix, right? It's a bit hidden behind the domain-specific terminology, but in the end it's a weighted graph represented as a sparse matrix. There's nothing wrong with that, it's a standard way to manipulate weighted (and even unweighted) graphs in both programming and mathematics.
BillWoodruff wrote:
How can you have "reciprocity" and "invariant."
Well I mean, there is some invariant on this matrix that you are maintaining, right? And it has something to do with the reciprocal edge (you called it that, I'm just going with it). If a weight somewhere is changed, then its "mirror image" (the reverse edge) needs to change in some way to restore that invariant. I didn't really get *how* it needs to be changed specifically (or what the invariant is that is being maintained by that change), but I suppose that's largely an implementation detail that doesn't need to affect the overall architecture. So essentially my suggestion is: make the overall matrix responsible for maintaining that invariant, not the edges. And so, the edges would not try to "fix themselves" in response to an event, you would tell the matrix to change an edge weight and it would directly do so in a way that maintains the invariant (by changing the weight of an edge and the corresponding reverse edge), with no events involved (of course you can still raise them, but that wouldn't be the mechanism for maintaining the invariant).
-
Your data structure is really a sparse matrix, right? It's a bit hidden behind the domain-specific terminology, but in the end it's a weighted graph represented as a sparse matrix. There's nothing wrong with that, it's a standard way to manipulate weighted (and even unweighted) graphs in both programming and mathematics.
BillWoodruff wrote:
How can you have "reciprocity" and "invariant."
Well I mean, there is some invariant on this matrix that you are maintaining, right? And it has something to do with the reciprocal edge (you called it that, I'm just going with it). If a weight somewhere is changed, then its "mirror image" (the reverse edge) needs to change in some way to restore that invariant. I didn't really get *how* it needs to be changed specifically (or what the invariant is that is being maintained by that change), but I suppose that's largely an implementation detail that doesn't need to affect the overall architecture. So essentially my suggestion is: make the overall matrix responsible for maintaining that invariant, not the edges. And so, the edges would not try to "fix themselves" in response to an event, you would tell the matrix to change an edge weight and it would directly do so in a way that maintains the invariant (by changing the weight of an edge and the corresponding reverse edge), with no events involved (of course you can still raise them, but that wouldn't be the mechanism for maintaining the invariant).
Thanks, Harold, okay ... for you sparse matrix; for me, node/edge Object graph.
harold aptroot wrote:
make the overall matrix responsible for maintaining that invariant, not the edges.
I'm going to implement that and see how it might work. i hate the idea of removing and readding event handlers. more ? in a while :)
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch