Ready.
Reviewing CroNoe75,
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.)
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.
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.
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.
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.
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,
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?
CroNoe75 is reporting from their work with this simulation case study that,
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.
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,
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,
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,
Next, similarly,
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.
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.
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.