Forest Sweeney via agora-discussion [2022-08-16 14:49]: > I do like this, but I have serious doubt it will pass at current-state > Agora: > 1. on discord, the current attitude is "no more subgames pls" > 2. The power level to override some of the other rules (eg liquid assets) > is insane, so that will be a huge hurdle (in addition to the overall > complexity) of gaining Agoran Consent.
Fair enough. But that's up to the people. I'm just a proposer. > Anyhow, my review: > 1. I have a problem with the terminology. Overall. I'd say petriplaces > should be petribags (hold tokens), petransitions should be petrinodes > (nodes can fire), and the petrivalence is the petransition (valence just > seems like a silly word, and the word transitions make it clearer that the > bag changes based on these). I'm basing the terminology on what's standard for Petri Nets. There are some differences, though: usually, transitions in Petri Nets have inputs and outputs. I've just replaced those with negative and positive valence places, respectively. Also, there's no mention of “valence”. Instead, transitions come equiped with two multisets of places. > 2. I think we prefer switches at all times if possible. Even for relating, e.g., places with their respective petri nets? Would we have a place-switch with values on petri nets, their “owners”? Why not have places as assets? > 3. Lockers are an asset, so they can be given, but also, it's unclear how > they can be taken. Assets already have owners, so this poses a problem, > since the attribute is being double defined. I could have defined them to be entities. The point is that they should be something that can own assets and have a player assigned to them, so that players can't hide assets in lockers (like they can in contracts). However, they should not be liquid (much like an actual locker). > 4. Because these are so intricate, I doubt we need more than one petrinet, > so it's a little overkill to allow multiple. However, unfortunately, this > does leave the open question on how you would extend or reduce an existing > petrinet. I would personally only want one to exist. I wanted them to be simple. My idea was for them to be “gadgets” that can be used to perform certain functions in-game. The original motivation was as an alternative to promises for performing trades. But mainly, the reason I'm proposing it is that I love little machines that can be composed to perform more complex functions. Now that I say it, I realize Petrinets are not really composable. > 6. This feels particularly complicated, so I made a diagram of what I think > was intended. It's basically a bipartite graph. If I call this diagram > 'Bobnet' then it is also a machine, if I pay the coins and such. > Now, this is what I garner from the rules on how firings would work: > Example: following the diagram, say we want to fire interface P: > We'd increase the petokens of A by 1, B by 2, and C by 3. We could always > fire P as long as the petokens on each node are >= -1, -2, and -3, > respectively. > > For Firing Q, we need at least 1,2,and 3petokens in A,B,C (respectively), > and then we'd remove 1 petoken from A, 2 petokens from B, and 3 petokens > from C. > > And for firing R, we need at least 1 petoken in B, and when fired, we'd > remove 1 petoken from B. Yeah, that's it. Though usually transitions would have both positive and negative links. Anyway, thanks for the feedback! -- juan
