R: Resolution about Token-Flow Conflicts

With E-nets, a resolution token is an index, to resolve conflicts. A conflict exists, when there are alternative paths. That is, the interpreter needs a resolution to tell it whether the first, or the second path is active, next.

A resolution token may reside at a resolution location, and informs the interpreter about the (ordinary-)token flow, through its associated (adjacent) transition.

The X- and Y-transitions of E-nets, are examples of net-elements that employ such resolution-locations, to shunt for paths. With Petri nets, this is left non-deterministic.

In other words, a resolution-location flags the preference between inbound (or, outbound) arcs, when there is a conflict, probably reflecting on the state of the resources (token-attributes and/or environment variables). That is, the E-net interpreter resolves/manages conflicts through resolution-locations. Another formalism, SARA, has the similar, as a variable/setting, @output_arcs, in its interpretation-domain, per each node.

As such, the SARA statement "@output_arcs = ..." corresponds to a resolution procedure in E-nets. (They have differing flexibilities vs. restrictions - as we discuss, about resprocs vs. interpretation domain. SARA does not decide at entrance, but lets resproc-decision to be set anywhere within the interp.domain. SARA does not allow res-token-flow, from within the net, either. It always needs a programmed-statement, if not altogether non-deteministic, with multi-arcs.)

Tracking plagiarism: R-to-R.
R (E-nets) ==> R (copycat82)

The corresponding formal letter, is similar to E-nets, with the letter "R," albeit with the definition as "a set of arcs," which is imitative of SARA. Although, copycat82 is vague about it, as those arcs point to both data and control nodes, in a merged (cluttered, even possibly explosive) graph, the net effect is the same, when we notice that, "R" manages the data-control relationships, as a resolution-location in E-nets, and an "@output_arcs = " statement in SARA do. As a conclusion, then, copycat82 has only cut-and-pasted between E-nets, and SARA, the two-parts formal structure being from E-nets.

In copycat82, it is the section "3.2.4. Interconnection of Components."

R=(R1,R2). How is that not Da80?

Da80 introduces X-transition of E-nets to time Petri nets. This entails the resolution-location, as its central feature. R₁ corresponds to the op-code, and R₂ corresponds to the parameter-vector, whether for input, or output. The op-code is about the control-state, the parameter-vector tells more. The copycat82 does not transcribe all of what Da80 discusses, and it is left vague. The structural-plagiarism is noticeable, though. Compare 2nd column of Da80, p.640, with p.58 of copycat82 (i.e., the cartesian product of two sets, saving from combined space...)"

section IV.E, too, where an X-transition of E-nets is discu a

For example, the "R" in E-nets structure stands for the "resolution locations," whereas the matching letter, again "R," in the copycat82, is defined as "a set of arcs." The exact-match would not be obvious. But When you notice that "R=(R1,R2)" in the copycat82 is exactly what Da80 calls "X=(X1,X2)," the match is indicated. The "R" in E-nets is that net element (index), at the intersection of (net) tokens and (internal) resources. i.e: It is cut-and-paste from Da80, where Da80 discusses the X-transition of E-nets. (NN73, p.719, refers to a transition as "nodes in the net at which the determination of token flow and modification takes place" The "R" is that determination.)

A Resolution is not only its Resources

Both E-nets, and SARA, have fine-tuned their variables, to fit their own architectures. We appreciate theirs, especially, when we observe how copycat82 fails, when it repaints this aspect of E-nets, imitative of SARA.

In copycat82, this exactly corresponds to "R: a set of arcs," written in the section "3.2.4. Interconnection of Components." There are no explicit variables to set/read resolution-indexes at.

But, a decision is more than its ingredients. It is a result, too (i.e: the resolution). Only showing the referred data-items, does not represent the decision, visually. e.g: What could you guess you wld eat, if you only learn that it has sugar, flour, eggs, butter, and milk in it? Cake? Pie? Crepe?

Note: In this case, the "wld" is "would" as you might have guessed, with your knowledge of English texts. But how consistently may you go on guessing? If you bother telling sth., unless in an interactive-chat, where you may repeat, it is helpful if you express what you mean, precisely. For example, reflect on the varieties of Arabic interpretations, when the consonants are omitted. Read the program fragments, the full formal listing, if you mean to learn and reflect about, what a transition/subnet is meant to do.)

A resolution token is the standardized-index that a path-selection-preference sets, and path-selection-query gets. i.e: When there are alternative (whether inbound, or outgoing) paths, the value of the resolution token is consulted. That value/preference is an abstraction, that standardizes the path selection results, as an index. It is, possibly, latched. (i.e: Set at a constant value)

And, as a result, the only way to resolve conflicts, in copycat82, is always, to employ a resolution-procedure (or, a "data-dependent-control-transfer-specification," as copycat82 calls it). See Psi: Resolving with environmental/peripheral knowledge

In copycat82, there are no explicit locations, or variables for this. It is only implicit, in a resolution-procedure, with a resulting loss of, both E-nets, and SARA flexibilities, and without any gain.

Visual Similarity

And that does suggest the origin of placing those little data-boxes everywhere around the graph, just where, in the E-nets case, stays the resolution location, pointing to the data-dependency.

In fact, similar to the data-item boxes that only dump the list of token-attributes, associated with a token, within the graph, the case is similar about resolution-locations/tokens, too. In this case, the to-be-dumped is the data-type boxes, which correspond to the resolution-procedure that is associated with that resloc, as implicit in that resolution-token, when a decison is made with a resolution-procedure. But next, we find in the graphs, only the data-item boxes. Except a single example-figure, with a dummy tpe of "T", in ts vagueness, in all of copycat82, the data-type boxes are not drawn. That is why, in the figures, we see the data-item boxes, instead of data-type boxes, that correspond to the resolution-location. A data-type is associated with a data-item, any way. (The vagueness in that single example is noticeable, though...)

i.e: The pattern of graph-clutter is, similar in both cases:
1) E-nets location harbors a token with token-attributes ==> copycat82 draws data-item boxes
2) E-nets resolution location harbors a resolution token with the asssociated/implicit resolution-procedure ==> data-type boxes (those types used by the procedure(s) of that transition. Simply read the text. Even copycat82 does not use it for any type, any way.

Appendix: The section "3.2.4. Interconnection of Components" of copycat82.

First paragraph in section 3.2.4. is ...