Review: "Interactive graphical simulation using modified Petri nets" (1975)

Reviewing CroNoe75,

"Interactive graphical simulation using modified Petri nets"
by Charles P. Crowley and Jerre D. Noe
in Proceedings of the 3rd symposium on Simulation of computer systems, IEEE Press, August 1975, pp.177-184.

Its abstract is freely available, through the portal of ACM. But (unless subscribing to their digital library), the .pdf is for US$10. (No appendix, though -- as retrieved in Aug. 2008. That may have been the CroNoe75 (p.182) typo to point at that, or the .pdf was digitized, lacking that appendix.)

what content is new?

Actually, NN73 could list as defining a graphical-simulation system with E-nets, too. But Noe has continued his enterprise with his new Ph.D student (biography in CroNoe75 foretelling his upcoming Ph.D., they hoped in Aug. 1975, but may have been in 1976). The work is expectable to achieve some [usability] finesse, beyond the base level of what we would trivially reflect (for coding the software) from NN73. That is, the new vs. the known.

Noe people followed up the NN73 reflections (p.725), first by coding the graphical E-net editor (Noe, Crowley, Anderson, 1974), that CroNoe75 section IV refers to. Next, CroNoe75 is well into the simulation business

-- for a computer-system simulation, but that is only one immediate example of what is doable with this tool. Their discussion is for a process of simulation, not limited to operating-systems.

what is that good for?

If you appreciate frozen@mid80, you/we would probably appreciate the software of Noe-people, too

-- although we would need to translate that from talking to their old vector-graphics terminal, to some graphics library (Windows GDI, DirectX, OpenGL, etc) that today's platforms work with.

I think, their reflections on the simulation process with E-nets, should not go unnoticed. But, looking into the indexes of two popular simulation books (Banks&Carson, and Law&Kelton), there is no mention of Petri nets, nor E-nets, at all. The formal-nets based simulation, has not caught the popular public attentions, we may infer.


CroNoe75 has seven sections.


Introduction lists almost only what there is in the paper's abstract. The extra is the reference to their previous work. (ACM is listing the references, along with that abstract. Thus, you miss no information from the introductory section.) For me, the new was only the ref 9, that is, their coding of the graphical editor, in 1974.

on "II. E-NETS"

We had known what an E-net is, from NN73. The CroNoe75 format is equivalent. The NN73 attitude is to keep the formal primitives as Nutt had listed in his Ph.D., but provide macro netting, in case we would like to extend that base system. In contrast, CroNoe75 is renaming (& mildly re-defining) the primitives -- how macros had.

No big news, though.

Essentially, no change to E-nets since NN73, that is. (& The title of the section, acknowledges that.)

NN73 abstract was starting with "An extension of Petri nets called evaluation nets (E-nets) has been developed for use in representation of computer systems." CroNoe75 is listing the formalism, first without how to interpret.

"The uninterpreted E-nets described so far can be useful as analytic models for some types of system analysis such as deadlock, mutual exclusion, maximum parallelism, etc. but for E-nets to be useful as a simulation tool an interpretation is needed; that is, the actions of the transitions need to be specified." (CroNoe75, p.178)

They highlight right next, what/how E-nets have beyond Petri nets. The procedures (& associated data).

That is, activity/freezing/rezolving, in the frozen@mid80 fragging terminology.

The versatileness of E-nets (the conserving of all formal-nets tool set), is pointed out well, as a result of first presenting uninterpreted (how Petri net tools test), then defining interpretably (how simulation software run).


The CDC6400 saga of Noe continues. He had first modeled the CDC6400 system, with Petri nets, Noe71

-- the operating-systems modeling example cited by the famous Petri net survey (P77, p.234).

Then, with his first Ph.D. student (Nutt), in NN73, the major example was again CDC6400, with macro-E-nets.

The working of a CDC6400 computer system, with a peripheral processor.

This time, the Noe people sat down to optimize their local computer-center purchase, by first simulating the two proposable systems, with their likely workload. That is cozily causy. Crafting software, to optimize their budget.

The system has two CDC6400 CPUs, and six storage units. If both CPUs have their own storage controller, the parallelism may help go faster, but costs money. Would a single (dual-channel) storage controller accessible from both CPUs, run as fast as the two-controller system?

They send/receive messages to/from a controller, first for permission-to-access, then to access.

CroNoe75 is not vague. People who know our trouble with copycat82 (& 83), would appreciate CroNoe75.

CroNoe75 paints & explains how they reflect their computer system (pp.178-181/182) with E-nets. That is straightforward, for facilitating your DIY work. Programmable. That is what makes a publication truly published. NN73 has the formal listings, too. Therefore, programmable to their formal notation, too. This endorses the straightforward, honest work in NN73 / CroNoe75.

Because of the plagiarist copycat82/83 claiming "Guttag Abstract Data Types" as a part of the copycat82/83, I have to keep away from anything that may resemble the Guttag-style of ADTs.

That is, while I am reconstructing the mid80 literature, I have the special "paranoia," not to be researching what that valueless plagiarist could claim "that was what we had/would." :-))


The editor for graphical E-net construction (with 2D vector graphics) is from their 1974 paper.

For running the net, the simulator is with the same (style) graphical front-end (like that of the editor).

Not running together, in memory. The editor wrote the net to a file. The simulator is processing.

They correspond to the frozen@mid80 forms for representing and monitoring, respectively.

But, frozen@mid80 is working with only fixed-structure net modules, linkable to build hierarchies.

Their non-interactive mode runs start to finish, then reporting the summary statistics -- like simulation languages.

That is resembling invoking a formal net through the " \F* " facility of form@fix.


Reflecting how simulating (interpreting) E-nets as E-nets is better than, interpreting E-nets as a simula program.

When they had no E-net simulator, they were running their E-nets, by converting to Simula.

The chore of translating one system to the other is obvious. Furthermore, CroNoe75 reflect that,

"The debugging was easier for the E-net model for two reasons: locality and interaction. The procedures in the E-net exhibit a much stronger locality than the SIMULA code, since the global coordination which must be worked out in the SIMULA code is expressed in the net structure by the E-net model. E-net procedures normally reference only local tokens; in a few cases resolution procedures sense the status of non-neighboring locations."
CroNoe75, p.183

This "locality" is how token-attributes travel with the tokens. Local to the transition working with that token.

In contrast to the modularity/hiding of the net structure, through reduction. Token-attributes provide this flexible (interpreting) strategy for travel safety -- that is, without hiding the net.

That interactiveness is almost similar to your looking into frozen@mid80 tabs/menues while monitoring.

Letting the software run until they stopped that at critical points (on pre-wired condition? improvised? both are straightforward). The frozen@mid80 style (so far) is supporting only stepwise walking. That is run-until-stopped vs. walk-a-step-if-told. Essentially equivalent, because we keep the space bar pressed, thus running until we stop pressing the space bar.


E-net vs. well-known simulation systems -- SIMULA, GPSS, SIMSCRIPT. What advantages may E-nets have?

"The separation of control and data in the E-net model structures the design effort in an advantageous way. The control flow is planned first and is represented in the form of an uninterpreted E-net with no data or decision schemes. The net at this stage simply shows what control paths are possible and at what points the subsystems will communicate. When this is firmly established the interpretation is developed to add time, data and decision algorithms. The interpretation can also be developed in stages. The decision making will probably be decided first thereby completing the control structure of the net. This is done by writing the resolution procedures. Then the data manipulation can be added by writing the transition procedures. The time procedures are added last since they don't affect the proper functioning of the net."
CroNoe75, p.183

CroNoe75 is reporting from their work with this simulation case study that,

"In the development of the disk system model described above, the net structure was developed and debugged before any procedures were written, and once it was set, it never needed to be altered during the course of debugging the procedures."
CroNoe75, p.183

Good news for frozen@mid80, that separation is allowing illiterate people (children or otherwise) to see what is running there (the control structure of the net and the token travel), and they may contribute to building, too.

"... not necessary to be a programmer to check the control flow in the net; anyone with a knowledge of the system and a basic knowledge of E-nets can do this. The programming part, which is the most subject to subtle errors, is restricted mainly to localized data manipulation. "
CroNoe75, pp.183-184

That co-op is presumably a field-expert who is not able (or, not interested) in the frag coding.

That case is lovely for young kids (as well as other illiterate people), too. The control-structure of the net is settable up, by a kid. For frag coding, daddy or mommy may help the kid, just as they would, for baking the cake, following a cake mix-up session (or, for wiping down the fudge pan).

What CroNoe75 is referring to as "programming" is "textual" (frag) programming. Presumably, they (as well as lots of other people) think the graphical/structural aspects as similar to building a model of a system with toys.

Like Tinker Toys, K'nex, arhitectural magnet toys, toy train tracks, etc.

Their "faux pas" is re-inforcing my expectations from kindergarteners. See formal-nets as toys.


This section is the normal conclusions-and-the-future portion of the paper. But is that too normal? Somehow, the pattern of the last section of copycat83 is also like CroNoe75. Either copycat83 was copying the last section (only obfuscating the sentences with equivalents), or there may be some trade standard they both subscribe to.

The lack of vagueness is refreshing, especially in contrast to copycat82/83, in the theoretical talk. First see,

" Because only one token can exist on a location an uninterpreted E-net is a finite-state machine and hence all properties of interest are decidable. Of course, most nets will be large enough so that more efficient decision procedures are a necessity. "
CroNoe75, p.184

See? They straightforwardly tell why the thing is decidable. (That is, because that is a finite-state machine!)

Thus, nothing left to guessing some extra -- let alone the need to "trust" through ignorance!

The good news is that, CroNoe75 is well-thought throughout the text. Furthermore, not needing your trust in that.

In contrast, that (same issue) becomes in the words of copycat82/83,

"Although certain analysis problems for Petri nets are known to be undecidable, the limitation of boundedness enforced through the transformation process results in the removal of any undesirable problems. Still, the exponential complexity of boundedness and liveness problems makes the analysis quite difficult."
copycat83, p.744

First of all, there is no such "transformation process" neither in copycat83, nor in copycat82! At great lengths, what copycat82/83 is telling is that they presume the net would be (like E-nets, or VD78) 1-bounded, or else that is a "design error" (term was in VD78, too, thus probably copied from there). But even the standard of copycat82/83 macro-gate (how and/or/xor macros translate to raw Petri net) naturally causes unboundedness

Not to mention that some of those contain inhibitor arcs. (Is that, thus, Turing-equivalent or finite-machine?) Thus, yet again, copycat82/83 has plagiarized something from some source, but in the context of copycat82/83, the thing has become out-of-function, mostly, or totally.

The copycat83 discussion section is in a total of four paragraphs. The first two summarize the representation, that is copying and renaming the prior art. The portion I just quoted is in the third paragraph, telling about test. The final paragraph is the "future work" which "copycat83 is proposing," but that resembles CroNoe75's, too.

That is a customary style to finish one published paper, while/if your work is continuing. The Crowley Ph.D. was pending (1975 to 1976). Thus, presumably, that Ph.D. is the referrable target.

In contrast, copycat83 was published a year after copycat82 (their "Ph.D.")!! Thus, the "future" was no pending Ph.D. Who published that "study?" A quarter century has passed, worthlessly.

For example, first,

"Also, since the E-net is so heavily dependent on its interpretation it is desirable to include the interpretation in the analysis. Both of these areas are the subject of current research."
CroNoe75, p.184

Next, similarly,

"Using this technique, we are limited to .... control flow analysis. Thus, direct analysis of the modified Petri nets both from control and data flow points of view is also being studied."
copycat83, p.744

The list of the "future" was

With traveling-token-attributes (the traveling messages of distributedness), that is almost (or, exactly) trivial to allow (for example, frozen@mid80 or form@fix) to vary the net structure (for example, by VD78 style, refinement/abstraction at run-time). Token-travel would not have trouble.

CroNoe75 is not referring to itself as a study of "distributed systems," and is not studying the major issues of such systems (security, availability, recovery, "mash up" (or, database view), load balancing, etc), but no such study is in copycat82/83, either. If you were looking for a mid80 example of a (message-based!) decentralized system (potentially distributed, remotely-working-able, if CPU number is replaced with TCP/IP addressing), CroNoe75 may be one (working) example -- in contrast to copycat82 which is supposedly a "Ph.D." of "distributed systems."

Constraints are surely imposable, that is what rezolving reflects about (see Da80). What is funny about all that "future" plus how I try to guess what sort of "constraint" they were wish-listing (rezolving? temporal-logic? what?), is that, chances are, maybe copycat83 thought nothing, or just looking at a prior art paper, and wishing to copy that in the future. Was nothing there, "yet."

In summary, CroNoe75 is a refreshing Noe-people work. Working, valuable, understood.

In contrast, if copycat82/83 told something, that is false somehow -- and/or plagiarism.

toward frozen@mid80

Listing a wish-list for what to modify -- the work toward the Ph.D. title, that Crowley was working for, at that point in time. Surely, some of that list relate to frozen@mid80, too. For example, the last (third) suggestion (that is, allowing the modifying of procedures while monitoring) is trivial, but that is just not how frozen@mid80 is preferring. For a programming system, I may think that again, but for frozen@mid80, the style of stating your model in representing, then see that work out or not, is the valuable scientific (& a honest puzzle-crunching) method. (By scientific method, the point is to list your hypotheses first, test, then report failure or success, then may reformulate new, no data-spoofing/polishing on-the-fly, no modifying of probability levels, etc.) The CroNoe75 suggestion is cozy for developing a program, for example, not needing to go back to representing, if only for a minor typo. Well, actually, frozen@mid80 is allowing modifying the data (the second suggestion that CroNoe75 wish) to some extent, but I have told in the documentation that, that is not good netly attitude to hack your net, while monitoring. As etiquette, I may suggest depositing tokens (& set their attributes) only at the peripheral-input locations, and get rid of some token, only at a peripheral-output location. So far, frozen@mid80 is not actively restricting thus, though. Therefore, the wish-2 that CroNoe75 lists, is there. Their first wish is probably valuable for simulation business, that is, the priority queues and statistics. But again, we may need to weigh the purist approach (of NN73) vs. the primitives-building approach that CroNoe75 opts for. That is a tension in all of programming. Minimalism vs. unnecessary-but-quickening. Neither is wrong, but one is needing the good judgment not to stretch unnecessarily. In this case, though, the issue of simulation-business, is presumably considered a valuable metaphor/business to contain in primitives -- or, maybe just specializing one subdialect of E-nets for simulation-business. The modeling nature of formal-netting is friendly, presumably, thus, we may find the hard-core-simulation-business primitives, to fit well as regular primitives.

Further Information

Crowley&Noe vs. neo-Crowley?

I'm not only interested in formal nets. I'm a massive enemy of witch trouble. People would probably look for a comment on that "Crowley" surname, because there is a long-dead but widely known witch (Aleister Crowley).

That is, a witchness-probability weighing is probably what you would expect from me..

First of all, CroNoe75 is well written. Thus, the pattern is not a stupid witch passing as if something. Therefore, we may at most (if almost truly paranoid), suspect whether Mr. Crowley had all of the project thought by Noe, then signed his own name, on that. The well-thought, cozy style of the Noe enterprise is there, just as in NN73. If suspicious thus, we may look further into the works through the research & writing lifetime of professor Crowley, as he went on. CroNoe75 is not conclusive, because most of the content is following the path openings from NN73, that Noe might have been exerting. The Crowley Ph.D. is more likely to contain Crowley content, less all-Noe content. Then, look into the works (publications, and the student achievements) of professor Crowley.

To summarize, I think the title "neo-Crowley" would most suit the worst -- copycat82/83, the "success" mystery.

The massive failure of copycat82/83 is way more suiting the title of neo-Crowley -- if to link to Aleister Crowley -- the "wickedest." If some were to blindly apply the "method" how/which copycat82/83 falsely copied, the evil of copycat82/83 would have cost lots of lives even merely by being published by some "trustable" institution/publication. (Good news is that, Leveson and most other people have just ignored copycat82/83 when studying Petri nets for systems safety.)

So, is copycat82/83 a true witch, lobbying into people's minds? Well, if you have your tool or method to test that, I would happily like to receive the test results, after you would check that out.

I think a few methods (& tools) to fight witch contagion. Good for freedom -- and game software.

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

Referring#: 0.0.1
Last-Revised (text) on Feb. 27, 2009
refreshing URLs & looks on, Sept. 7, 2009
Written by: Ahmed Ferzan/Ferzen R Midyat-Zila (or, Earth)
Copyright (c) 2009 Ferzan Midyat. All rights reserved.