Ready.


Data vs. copycat82

copycat82 commits plagiarism. It is a worse than trivial attempt to merge a few prior art. And it is stuck with the self-contradictory side-effects of its wrong selections (what to cut-and-paste). The case about "data-items" is a grave example.

Why does copycat82 mention data, at all? It is much ado about nothing (with its so-called "single" graph):






data out of control

(ignores control at design, leaning towards data, next, ignores data when verifying)

E-nets (Da80) represent with interpreted-abstraction. That means, at run-time, data is referred to. By contrast, VD78 neglects data, for a pure Petri net verifier, at the first-level. Next, copycat82 attempts to represent as E-nets, but to verify as VD78-level-1. It is not verifiable that way, though.

Although NN73 is a paper by the original E-net authors, it is more about macro-based abstractions. It mentions interpreted (statistical-summary) abstraction, as an alternative-in-representation. Da80 represents more this way, and it is in a verifier, too.

In fact, even Da80 is verifiable, exhaustively, without data, but copycat82 cannot be. It is

The latter case is possible (as NN73 points out) with E-nets, too, although it is again there in copycat82 where in an example, a semaphore is only a "data-item." That means, the verifier would not know any problems about it, although it is critical to the net-flow.

The grave problem is the structural one, though. How would a verifier know what that shape was supposed to do, at all? In Da80 case, the net elements are preserved. Any (two-inputs) X-transition receives its input tokens, and releases its token to its preferred output location. It does not multiply, or swallow any tokens, by itself. But all of this is breached, in copycat82. As a result, copycat82 nets do need some arbitrator to inform the verifier about token-flow, but there is no such thing. As such, it is not verifiable unless with maximal complexity.






lock-places were necessary and sufficient, to share data

Were the data-item rectangles meant to show which transitions share which data-items? e.g: VD78 employs its data-graph (after LOGOS), to verify determinism, and determinacy.

copycat82 does not do any of it, though. And its so-called "single" graph is only unnecessary clutter. To represent any shared-data, the Petri net places (or, E-net transitions with their locations) are necessary, and sufficient.

If only "shared" as read-only, it is not needed to represent the data-links, as the reader-subnets may not influence each other, any way.)


to inform about multiple data-items

If an extra information is needed/wanted, to identify each data item regulated by that (lock-)place, then a list of the names of the data-items, to associate with that place, would tell what it stands for. The E-net token-attributes is such a list.

With Petri nets, this is feasible, too. Although E-nets shift the preference to the transitions, it makes no difference here, because each location is identified with a single inbound-, and/or a single outbound-transition.

With E-nets, an X- or Y-transition shunts the preference, not the locations. The location holds the data, whereas the E-net transition receives the inbound data (from each activated location), and builds the outbound data (in each target location).

It is problematic to associate data with the whole macro, instead of its paths, if it may have multiple unsynchronized in/out paths. The reader must guess which path may use which subset of data-items. Although E-nets keep them separate, copycat82 collapses them. That is a source of vagueness, with those "component"s.






procedures were necessary and sufficient for data-use

The E-net procedures are necessary and sufficient for representing data-manipulation.

For example, next to a bubble with a program fragment in it, there is no sense to paint "data-item" names in rectangles, next to it. The assignment operators, tell already, what is read and what is written. e.g: "next = i;" would mean "next" is written, and "i" is read from.

It is necessary to read the program-fragments, if to know what is assigned to what. Otherwise, only a the readable and/or writable status of a data-item would not tell what goes on, about them. The case is more and more complicated, when there may exist multiple readable and/or writable data-items, and/or more operations than mere assignment. Without reading the text, it is most probably, not guessable.






Further Reading

copycat82 imitates E-nets (NN73, Da80), in many ways - although it never cites Da80.




Forum: . . (Fair Menu . . . . . Fault Report? . . . . . Remedy for your case . . . . . Noticed Plagiarism?)

Referring#: 0
Last-Revised (text) on Oct. 31, 2004 . . . that was http://www.geocities.com/ferzenr/decalun.nodatitem.htm
revised link, on Nov. 6, 2004
mirror to mid80.net, on June 16, 2009
Written by: Ahmed Ferzan/Ferzen R Midyat-Zila (or, Earth)
Copyright (c) 2004, 2009 Ferzan Midyat. All rights reserved.
mirror