First, let me apologize if I came off as rude before - I didn't mean to, was just in an aggressive mood.
The picture Alejandro drew of System B used the CRT notation developed by Dr > Goldratt [...] An arrow between two processes shows that the tail process > must first complete before the head process can commence. A 'banana' > operator between two arrows shows that all the tail processes so joined must > complete before the head process can commence. Cool! I'd never heard of CRT before. Thanks for explaining it. Just to make sure I understand, it's a two-color directed graph (the "bananas" are one color, the "normal" nodes are another), with the restriction that each banana node must have exactly one outgoing edge into a normal node? I have found it to be a powerful tool for modeling program execution. It's certainly a neat way to look at large programs. I'm not quite sure how accurate it could be at describing biological systems or the like. On Thu, Mar 4, 2010 at 8:20 PM, Alejandro Garcia <[email protected]> wrote: > > On Thu, Mar 4, 2010 at 3:09 PM, Andrey Fedorov <[email protected]> > wrote: > >> The picture you gave isn't a system, it's a directed graph. I guess you're >> implying anything you imagine to be a "system" can be represented as a graph >> - but what *is* a system? > > > Well it isn't a system in the same sense that a map isn't the terrain. I > think people call those things a representation. > Precisely! So we *are* on the same page. It's a representation which doesn't always preserve a system's "complexity" (without defining "complexity"). So all I'm getting from your earlier point is that the CRT representation of a system can't be used to define "complexity". So it's a crappy representation, after all. If we *do** *want to define "complexity", we could put a constraint on these CRT graphs, like "nodes have no state"? This is starting to smell like the classical argument against OOP. Cheers, Andrey On Fri, Mar 5, 2010 at 3:28 AM, Antoine van Gelder <[email protected]>wrote: > On 05 Mar 2010, at 03:20 , Alejandro Garcia wrote: > > On Thu, Mar 4, 2010 at 3:09 PM, Andrey Fedorov <[email protected]> > wrote: > > The picture you gave isn't a system, it's a directed graph. > > > Andrey Fedorov! > > You have failed to observe the bananas in System B! > > Directed graphs do not have bananas you dumbass! > > Don't you know anything? > > ;-) > > > > I guess you're implying anything you imagine to be a "system" can be > represented as a graph - but what is a system? > > > Processes in living creatures, social organizations or other phenomena that > are operating synchronously in respect of one another are usually what we > mean when we speak of systems. > > Which I wouldn't know today if it weren't for a philosophy major with his > regulation-issue bong. > > Specifically: > > The picture Alejandro drew of System B used the CRT notation developed by > Dr Goldratt. > > > Where there are multiple tail processes feeding into a head process without > a banana operator joining them, the head entity will commence upon _any_ > tail entity reaching completion. > > > > > > Well it isn't a system in the same sense that a map isn't the terrain. > > A blue print isn't a building > > a paint isn't the object being painted. > > > > I think peoplo call those things a representation. Maybe I'm mistaken. > > > You're not mistaken Alejandro. > > I understood exactly what you meant. > > > > > Also, you can define the "complexity" of a graph in any way you like. > Until you show that this definition is somehow representative of the real > world, you're just masturbating. > > > > > > Ok for example in the real world the realization that is possible to know > how a system with several interactions will behave in a predictible way is > the basis of Systems Thinking and the Theory of Constraints. Both with huge > impact in systems from manufacturing to epidemic distribution. > > > _IF_ you'd have to walk him through CRT's first to explain what you mean > _AND_ he has already made up his mind that you don't know what you're > talking about about _THEN_ he's unlikely to sit still for the two or three > days it would take for him to realize his mistake. > > ;-) > > Are you actively busy with any research or applications of TOC & Systems > Thinking to hardware design or programming Alejandro? > > Also of interest: > > Akyil - "How The Theory of Constraints Can Help Software Optimization" > http://www.drdobbs.com/development-tools/218101302 > > Rippenhagen, Krishnaswamy - "Implementing the theory of constraints > philosophy in highly reentrant systems" > http://portal.acm.org/citation.cfm?id=293172.293397 > (*cough* > http://www.2shared.com/file/11859475/5abe015c/p993-rippenhagen.html) > > - antoine > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
