Talk:Signal-flow graph

Modify Example 3?

Example 3 is a textbook example on control theory; it does, however, not show the forte of SFGs applied to circuits, nor does it clarify the possibility of cause-effect representation in SFGs.

If nobody speaks up against it, I will replace example 3 by an example that does both in May 2010: the analysis of an opamp circuit with feedback.

Any comments? —Preceding unsigned comment added by Hanspi (talk • contribs) 18:39, 17 April 2010 (UTC)

Notation a standard?

is the signal-flow graph notation based on some sort of authoritative standard? --Abdull (talk) 19:25, 9 October 2010 (UTC)

I don't know, but what is described is exactly what my text book has. That would be Automatic Control Systems by Kuo,1967 Constant314 (talk) 21:06, 9 December 2010 (UTC)

Digital Filters

Signal flow graphs are useful for depicting and analyzing digital filters, especially IIR.

In fact the way they are usually drawn is a signal flow graph with a little stylistic change.Constant314 (talk) 21:09, 9 December 2010 (UTC)

Clarification Needed

What sort of clarification do you need? Every set of linear equations can be represented as a SFG and every SFG can be represented as a set of linear equations.Constant314 (talk) 21:33, 9 December 2010 (UTC)

Okay, here is one of the earlier cites I can find that summarizes this bijection. Even by 1967, this result was already known. See my cite to the SIAM journal article. Vonkje (talk) 18:38, 3 March 2011 (UTC)

Sorry, I still do not know what you are wanting. Constant314 (talk) 22:19, 3 March 2011 (UTC)

Example 2 mismatch

It seems that the text description in Example 2 does not quite match up with the diagram it was supposed to describe. I could guess some corrections but isn't there an EE out there who can help us out? Vonkje (talk) 18:38, 3 March 2011 (UTC)

As far as I can tell, the description is correct, but the example is almost too trivial. What he is saying is that the signal flow graph is for a system where the port voltages (V1 and V2) are the inputs and the port currents are the outputs. This would be the case where the ports were driven by ideal voltage sources which are considered the inputs and the currents sourced by those ideal voltage sources are the outpurts. Usually, a two port is part of a circuit and not a stand alone circuit. I think I could provide a better example. Maybe his weekend. Constant314 (talk) 22:26, 3 March 2011 (UTC)

Also consider that a resister can be modeled as a voltage dependent current source. I.e.its current is proportional to the voltage across it.Constant314 (talk) 22:28, 3 March 2011 (UTC)

Maybe this is better; it shows a two-port in the context of a circuit

Circuit with two-port and equivalent signal flow graph. Notice that there are three loops in the signal flow graph. The larger loop goes from V1 to I2 to V2 to I1 and back to V1.

Constant314 (talk) 05:25, 4 March 2011 (UTC)

Causality

Example's 1 and 2 seem to have incorrect statements about causality.

Figure 1 unequivocally implies that V₂ is directly controlled by V₁. Figure 2 unequivocally implies that I₁ is controlled by a weighted sum of V₁ and V₂.

from Kou page 57 "... the branch directing from node x₁ to node x₂ expresses the dependence of x₂ upon x₁ (but not the reverse).

• Kou, Benjamin C. (1967), Automatic Control Systems, Prentice Hall

Constant314 (talk) 03:45, 13 March 2011 (UTC)

I think what needs to said is that a partial signal flow graph (a portion of s SFG lifted out of a larger SFG) does not express cause and effect but a complete SFG with input nodes specified does express cause and effect.Constant314 (talk) 03:52, 13 March 2011 (UTC)

Software to Solve Signal Flow Graphs

I think links to software that can be used to solve (calculate transfer function) of signal flow graphs should be added to the article, here are a few examples

• Signal Flow Graph Solver client side web page: https://github.com/ahmedkotb/sfg.js
• Signal flow graph solver chrome application: https://chrome.google.com/webstore/detail/signal-flow-graph/cdgiabknpabkdlahjgabbammnjfabkol?hl=en
• Matlab file : http://www.mathworks.com/matlabcentral/fileexchange/22 — Preceding unsigned comment added by 41.46.219.11 (talk) 15:45, 6 March 2013 (UTC)

Example with a non-equality relation?

The introduction paragraph says of an SFG that "its nodes are the variables of a set of linear algebraic relations." Can anybody provide an example application where the relations are, say, inequalities (e.g., less than)? — Preceding unsigned comment added by 74.71.235.237 (talk) 01:16, 28 February 2014 (UTC)

Eliminate Example 3

This seems to be a lot of algebra signifying nothing. At best it shows that you can change the weights on some of the branches and still have the same overall gain. The relationship of the SFG to anything is not defined. Even if you can represent asymptotic gain by a SFG, there is no useful reason to do so. You can represent a voltage divider by a SFG, but it would not bring any insight to the analysis.Constant314 (talk) 17:52, 31 December 2014 (UTC)

The reason that a 2 port's admittance parameters are an unrevealing example is because it should have been transformed to the equivalent scattering parameters. See Mason's 1953 paper, fig 35 page 1196. IIRC a lossless transmission line can't be represented using an admittance matrix, although there's a way to fudge it that's good enough if the application isn't too demanding. Scattering parameters are a relatively direct application of signal flow graphs with more intuitively meaningful results, e.g. S21 is the input to output voltage gain/attenuation of a 2 port. — Preceding unsigned comment added by PolychromePlatypus (talk • contribs) 19:40, 9 April 2019 (UTC)

It was actually example 2 Ideal negative feedback amplifier, figure 3. It was retained. I still think it is a bunch of algebra signifying nothing.

Constant314 (talk) 21:20, 9 April 2019 (UTC)

One-to-one relationship with a system of linear equations. Reason to doubt.

If I have the equation V = kθ there are two possible graphs: an arrow pointing from θ to V with a weight of k, or an arrow pointing from V to θ with a weight of 1/k. If I have other knowledge such as V is the velocity of my car and θ is the deflection of the speedometer, then I know that the arrow should point from V to θ. The SFG has more information than the equation. I do not have access to the reference, but assuming that the reference is correct, there is probably some requirement that the equations be in some sort of canonical form.Constant314 (talk) 19:47, 31 December 2014 (UTC)

Never mind. I found the constraints on the equations and added them to the article. Constant314 (talk) 23:38, 31 December 2014 (UTC)

I replaced by a sentence describing "acausal modeling" and a quote from Robichaud Pierre5018 (talk) 03:12, 14 January 2015 (UTC)

A signal flow graph should model the actual physical process. Note that removing the bezel from a speedometer to directly manipulate the indicator needle has no discernible effect on the forward velocity of the vehicle. (Feel free to insert an analagous humorous reference to a fuel or oil treatment or to the application of flame decals) Conversely altering the forward ground velocity of the vehicle by any available means has a direct and proportional effect on the position of the speedometer's indicator needle. (note that because a modern instrument cluster doesn't have a speedometer the system also has to be powered to permit the microprocessor controlled stepper motor with gear reduction to simulates a speedometer) ... also there is no requirement that a signal flow graph be expressed in a canonical form. A signal flow graph can often be reduced Isee Mason, 1953) and sometimes its pleasant not to cover the page with boxes and arrows, but the validity of the analysis doesn't depend on reducing it.PolychromePlatypus 20:06, 9 April 2019 (UTC) — Preceding unsigned comment added by PolychromePlatypus (talk • contribs)

The issue was settled to everyone's satisfaction long ago. The article talk page is not a forum for discussing the topic. It is a forum for discussing improvements in the article. If you think there is something to improve in the article, its best to just start a new topic rather than responding to long dormant discussions. Constant314 (talk) 21:39, 9 April 2019 (UTC)

Quote by Chen in intro

I did not see anything in the quote that would make me think Chen is referring to anything other than the well known fact that signal flow graphs can be solved by using Mason's gain formula. Constant314 (talk) 02:40, 3 January 2015 (UTC)

Acausal?

Is the word acausal in the introduction intentional or should it be causal?Constant314 (talk) 20:27, 3 January 2015 (UTC)

Kou is unambiguous that the arrows in a signal flow graph represent cause and effect. A directed graph could represent acausal relationships, but it would not be a SFG. For example, in the documentation C++, some authors use the notation A→B to mean A is the child of B. Constant314 (talk) 18:22, 4 January 2015 (UTC)

The new section on causality will show two valid ways of looking at a SFG: causal and acausal.­­­­Pierre5018 (talk) 23:29, 13 January 2015 (UTC)

Solving linear equations using graph transformation rules unclear

This section, as is, is incomplete. It does not show how to solve linear equations using graph transformation rules. To improve the section, please include the following:

• Constraints, if any, on the equations to be solved.
• An example of a set of equations to be solved with at least 3 linearly independent equations with three unknown variables.
• A list of the knowns and the unknowns. Constant314 (talk) 20:28, 3 January 2015 (UTC)

Later this week, I will add details on the rules to construct the sfg for its resolution by these rules. Pierre5018 (talk) 03:57, 7 January 2015 (UTC)

Types of signal-flow graph?

Pierre: Some clarification is needed. The first line of the article seems to say that signal-flow graphs are the same thing as Mason graphs, and the quote from Mason's paper in the history section appears to suggest that Mason thought the graphs he was proposing are what he called signal-flow graphs. But you have now introduced a sub-section called 'Mason signal-flow graphs' under the main header 'Types of signal-flow graphs' suggesting that Mason graphs are a subset of signal flow graphs. Perhaps you could clear up this apparent conflict, and provide requisite sources? Brews ohare (talk) 03:04, 6 January 2015 (UTC)

I have removed this section which appears misleading because of the headers attached to it that suggest a Mason graph and a signal-flow graph can be different things, and because the quote adds nothing new to the content of the article. The source already is cited earlier. Brews ohare (talk) 16:52, 6 January 2015 (UTC)

"Mason" was the first in a section on variants of signal flow graphs. This section would itemize Mason, Robichaud, Coates flow graph, and perhaps more. Another section to come should be the legacy of SFGs in which there would be a short presentation of bond diagrams and their origin in SFGs. Pierre5018 (talk) 12:40, 7 January 2015 (UTC)

Mason introduced several types of flow graphs in his papers. Most important is the notion of a linear flow graph. He often uses the term Flow Graph (unqualified). It seems that "Mason Flow Graph" is a misnomer, and the qualifier "Mason" should be reserved for his method for solving the gain of a linear FG. In his 1953 paper, he uses the term SFG twice (title and introduction); he uses the term "flow graph" about 48 times. Pierre5018 (talk) 19:00, 10 January 2015 (UTC)

Perhaps a draft section, say ‘Related flow graphs’, could be posted on this talk page for discussion? It should be sourced and linked to the articles on Coates graph, Bond graph and rather than repeat what is in those articles just provide enough information to help the reader decide what might interest them in these articles. Brews ohare (talk) 16:54, 7 January 2015 (UTC)

It appears that the Mason graph is a type of restricted bond graph, and that the Coates graph and the Mason graph are fundamentally the same (one can be mapped into the other). Perhaps you understand where a Mason graph would prove easier to use? For example, see this. Brews ohare (talk) 17:04, 7 January 2015 (UTC)

In any event, my understanding is that the terms Mason graph and signal flow graph are identical, and if one searches for a more inclusive term it is not to be found by redefining 'signal flow graph' to include things other than Mason graphs. More general classifications are digraphs or bond graphs or perhaps some other designation. See this, for instance which says Mason introduced the term signal flow graph, or this. Do you agree? Brews ohare (talk) 17:13, 7 January 2015 (UTC)

There appears to be no doubt that Mason introduced the term 'signal flow graph' and it is now referred to by many authors as he defined it. However, some authors have chosen to use the term in a different sense: see this. This different meaning appears to be a minority usage. Brews ohare (talk) 17:56, 7 January 2015 (UTC)

Possible copyright problems

It looks as though some of the new sections are violations of copyright. In particular History, Domain of application and Types of signal-flow graphs appear to by quoted copyrighted text.Constant314 (talk) 05:58, 6 January 2015 (UTC)

hathitrust.org states:

About this Book

Catalog Record Details

Signal flow graphs and applications / Louis P.A. ... . Robichaud, Louis P. A., 1926-

...

Copyright: Public Domain, Google-digitized.

Pierre5018 (talk) 04:07, 7 January 2015 (UTC)

Good find. Constant314 (talk) 04:58, 7 January 2015 (UTC)

Related flow graphs

Related flow graphs

A definition of a flow graph is:¹

"A signal flow graph is a network of nodes (or points) interconnected by directed branches, representing a set of linear algebraic equations. The nodes in a flow graph are used to represent the variables, or parameters, and the connecting branches represent the coefficients relating these variables to one another. The flow graph is associated with a number of simple rules which enable every possible solution [related to the equations] to be obtained."

If there is a distinction between this definition and that of the digraph, it lies in a connection to a set of linear algebraic equations.² Because of this generality, although the adjective 'signal' has crept into this definition, it is best omitted to allow that "flow graph" has a more general definition than the term "signal flow graph".^Note1 That choice agrees with the common use of the term signal flow graph as referring only to the Mason flow graph, one among many possible flow graphs.^Note2

Among the related diagrams often used in network analysis are the basically equivalent Coates flow graph, and the rather different bond graph that allows bilateral exchange between nodes.⁴ For feedback circuits, the Mason signal-flow graph is preferred to the Coates flow graph because it provides a more direct representation of the feedback process. ⁵

Notes

^Note1The term flow graph has a different meaning in computer science.

^Note2A variety of flow graphs exist, and some authors have chosen to refer to some of them as signal-flow graphs, for instance, Murota.³ This departure of meaning from Mason's signal flow graph appears to be a minority usage.

Sources

¹J. R. Abrahams, G. P. Coverley (2014). "Chapter 1: Elements of a flow graph". Signal flow analysis. Elsevier. p. 1. ISBN 9781483180700.

²Narsingh Deo. Graph Theory with Applications to Engineering and Computer Science. p. 418. A signal-flow graph contains the same information as the equations from which it is derived; but there does not exist a one-to-one correspondence between the system of equations and the digraph.

³Kazuo Murota (2009). Matrices and Matroids for Systems Analysis. Springer Science & Business Media. p. 47. ISBN 9783642039942.

⁴PC Breedveld (2009). "§1.3.3 Bond graph notation". In Vincent Duindam, Alessandro Macchelli, Stefano Stramigioli, Herman Bruyninckx, eds (ed.). Modeling and Control of Complex Physical Systems: The Port-Hamiltonian Approach. Springer Science & Business Media. p. 16. ISBN 9783642031960. {{cite book}}: |editor= has generic name (help)CS1 maint: multiple names: editors list (link)

⁵Wai-Kai Chen (2014). Applied Graph Theory: Graphs and Electrical Networks (2nd ed.). Elsevier. p. 172. ISBN 9781483164151.

Comments

• This is a proposal. Comments and changes are solicited. Brews ohare (talk) 19:11, 7 January 2015 (UTC)

I'm not sure what the proposal is. It is not surprising at a flow graph and a di-graph mean the same thing. For me, a signal flow graph is a di-graph for which Mason's gain formula gives the correct results. If there was no MGF then the SFG would not be of interest to control engineers. Constant314 (talk) 00:35, 8 January 2015 (UTC)

The proposal is to add this subsection. It's purpose is to point out that the most common usage of 'signal flow graph' is as a synonym for 'Mason graph', but that there are other kinds of flow graph that are used, some very similar to Mason graphs. More generally, digraphs are defined independent of linear algebraic equations, but flow graphs are not. Nonetheless, the theorems about digraphs are useful for flow graphs. Brews ohare (talk) 01:57, 8 January 2015 (UTC)

Are you taking flow graph to mean the same thing as signal flow graph. I take flow graph to be less constrained than a signal flow graph. If you want to say that signal flow graph is a synonym for Mason graph, that's fine with me. If you want to add a section on something that is not a signal flow graph, I would suggest that it should have its own article.Constant314 (talk) 04:31, 8 January 2015 (UTC)

Yes, the piece states that 'Mason flow graph' and 'signal flow graph' are synonyms for most authors. One purpose of the piece is to point out that 'flow graph' is more general than 'signal flow graph', intending to avoid an easy confusion in the reader's mind. The piece is not intended to insert a digression explaining a different topic, but to clarify a relationship with the SFG. Brews ohare (talk) 12:43, 8 January 2015 (UTC)

-- Good intro. However, a digraph is not the same thing as a flow graph. A flow graph is a directed graph, but not all directed graphs are flow graphs. A flow graph introduces the meaning of an equation relating source and sink nodes representing variables, and the meaning of a transfer function to an edge. Pierre5018 (talk) 02:03, 8 January 2015 (UTC)

• Mason and Coates should be presented as methods of resolving the gain in a flow graph Thulasiraman paper

• Nathan's representation Nathan paper could be discussed.

• Robichaud's representation should have a paragraph Robichaud's notations with half-circles for quadripoles "It is to be noted that the left-hand nodes correspond to the left-hand or input variables, and that the right-hand nodes correspond to the right-hand or output variables, in order to maintain a correspondence between the ports of the network and the nodes of the flow graph. The voltage nodes will always be drawn in the top row and the current nodes in the bottom row of the graph. In order to facilitate the interconnection of these graphs, it will be convenient to show explicitly the source and sink nodes. The source nodes will be drawn as black half-circles and the sink nodes as white half-circles. These flow graphs are in the form of quadri-poles and are therefore called quadripole flow graphs." Robichaud had a very good insight that led to bond diagrams, re [ https://www.me.utexas.edu/~longoria/paynter/hmp/BGprehistory.pdf Paynter's An Epistemic Prehistory of Bond Graphs] in particular section 5.2 where there is a notation for explicit causality check "Another important contributor to SFG theory and applications, Louis ROBICHAUD, ... Here the black half—nodes represent sources or inputs, the white half—nodes, sinks or outputs . Whole—nodes must then be always half-black/half—white to assure causal compatibility during interconnection."Pierre5018 (talk) 02:03, 8 January 2015 (UTC)

If quadri-pole flow graphs are not signal flow graphs then they should not be in this article.Constant314 (talk) 04:40, 8 January 2015 (UTC)

Constant: From Robichaud's presentation, quadripole flow graphs are the application of SFG's to networks comprised of two-ports, an application of the SFG. As such (and assuming that Robichaud means a Mason flow graph by his use of the term SFG, and not some other digraph, which I haven't checked), it seems appropriate to have this application described in this article, although an extensive treatment would require a separate article (not yet present on WP). Brews ohare (talk) 12:23, 8 January 2015 (UTC)

I can see some merit in such additions, but I have no interest in writing it. Brews ohare (talk) 02:17, 8 January 2015 (UTC)

The question for me is: Should this subsection be added as it is for now? Of course, it can be added to or amended by anyone later to be more complete or better sourced. Brews ohare (talk) 12:13, 8 January 2015 (UTC)

Maybe a better idea is a stub, like Flow graph (mathematics), that simply lays out definitions of SFG, Coates graph, and flow graphs and their connections? What do you all say? Brews ohare (talk)

Definitions

It seems to me that you are saying SFG ≠ flow grap = di-graph and Pierre is saying SFG = flow graph ≠ di-graph.Constant314 (talk) 23:23, 8 January 2015 (UTC)

Constant: Speaking for my take on the literature, SFG ≠ flow graph and also SFG ≠ digraph, as you say. However, contrary to your understanding, also flow graph ≠ digraph. SFG ∈ digraph, flow graph ∈ digraph. According to some, SFG ∈ flow graph. My understanding of Pierre is that he also agrees with my assessment of sources that digraphs include both SFG and flow graphs, but also other types of graphs. Specifically, digraphs include graphs that are not necessarily connected to matrices or linear equations (although that possibility might exist), while the SFG and the flow graph are both required to be so-connected. As for the connection between flow graphs and the SFG, there is some confusion in the literature. The predominant usage is that SFG ≡ Mason graph, while there is one set of authors that take flow graph ≡ Coates graph (W-K Chen and RF Hoskins, for example) and another that takes flow graph ≡ {subset of digraphs necessarily related to matrices or linear algebraic equations} so flow graphs include both Mason graphs and Coates graphs, and Murota's graphs, and perhaps others. What is your view of the literature? Brews ohare (talk) 14:16, 9 January 2015 (UTC)

Chartrand uses a different vocabulary. A digraph is a set of vertices with a non-reflexive relation between pairs of vertices, named an 'arc' or 'edge'. (page 16) A digraph becomes a 'graph' if the directionality is removed. A network is a graph or digraph that associates a real number with each arc or edge. If the network is related to a graph, it is undirected and if to a digraph it is a directed network. (p. 19) Graphs can be described by matrices, but the mapping of matrices to graphs is many to one. (p. 218) Also, see first paragraph in Hurary Brews ohare (talk) 16:23, 9 January 2015 (UTC)

Henley says "The nomenclature is far from standardized, and...no standardization can be expected in the foreseeable future." He uses 'flow graph' and 'signal flow graph' interchangeably (more often 'flow graph' as it is more compact, I guess) and defines the 'flow graph' like this:(p. 2)

"Flow graphs are a graphic representation of sets of linear algebraic or linear differential equations. Each vertex of a graph represents a variable of the equation...The coefficients a_ij written alongside the branches are referred to as gains, branch gains or transmittances. They are the operators that map node x_i into node x_j, i.e. x_i=a_ijx_j. The term transfer function is frequently used if x_i, x_j are functions of the Laplace operator s."

Evidently, Henley's 'flow graph' is not restricted to either the Mason or the Coates graph, but includes both. Abrahams & Coverley are in the same boat. Brews ohare (talk) 17:41, 9 January 2015 (UTC)

There is also this withdrawn standard : 155-1960 - IEEE Standards on Circuits: Definitions of Terms for Linear Signal Flow Graphs , 1960 DOI: 10.1109/IEEESTD.1960.81088 [1]. Notice "linear SFG" in the title Pierre5018 (talk) 00:56, 14 January 2015 (UTC)

I've made a stub Flow graph (mathematics) which needs some examples. Please take a look. Brews ohare (talk) 19:09, 9 January 2015 (UTC)

Linear flow graphs

Urgent: need to treat under a common heading all topicss pertaining to linear flow graphs from the rest. Why was this separation of concerns undone?Pierre5018 (talk) 22:58, 10 January 2015 (UTC)

Pierre, it is not clear what you refer to. Is it something in a different article? Constant314 (talk) 03:51, 11 January 2015 (UTC)

I was referring to this update [2] which I see as a step back in the wrong direction. My intention was to expand on block diagrams and causality, and to keep linear flow graph discussions very separate from other types of flow graphs.

Sorry, I'm still not sure what you mean. Wikipedia Article naming has some fuzzy rules, but my interpretation is that the commonest name goes with the most common use rather than the most general use. So, this article named Signal-flow graph should be about the linear signal flow graph. It might then have a paragraph about non-linear signal flow graphs and/or a link to an article called non-linear signal-flow graph. This article might have a note at the top saying that this article is about linear signal flow graphs. For non-linear signal flow graphs see <link>. For other flow graphs see <different link> etc. Constant314 (talk) 23:45, 12 January 2015 (UTC)

I can relate to what you say Constant, given the state of inconsistencies in the papers and books. In his 1953 paper, Mason talks about flow graphs, and only qualifies them twice with signal. Even Mason defines SFGs (unqualified) under a heading Linear SFGs:

A BRIEF STATEMENT OF SOME ELEMENTARY PROPERTIES OF LINEAR SIGNAL FLOW GRAPHS -- A signal flow graph is a network of directed branches which connect at nodes. Branch jk originates at node j and terminates upon node k, the direction from j to k being indicated by an arrowhead on the branch. Each branch jk has associated with it a quantity called the branch gain gik and each node j has an associated quantity called the node signal xj.

— Mason, 1955 Technical Report 303 July 20, 1955

My opinion is that an article under a heading signal-flow graphs should treat all types of SFGs; since most content is about linear SFGs, a separate page on non-linear SFG would be near-empty. If the article becomes huge in the end, we should then consider creating one or more separate pages. If there is a separate page for linear SFGs, it should be reflected in the title. Pierre5018 (talk) 01:20, 14 January 2015 (UTC)

Time-invariant linear SFGs

All editors: please make sure that time-invariance is specified where relevant. Pierre5018 (talk) 23:39, 13 January 2015 (UTC)

Pierre's Note

Pierre has added this note:

NOTE: Building a signal-flow graph from equations is compatible with an acausal modeling approach: the signal flow graph, causal in nature, is only used as an artefact to solve the set of equations, not to imply a particular sequence of computation.

This note probably is clear to Pierre, but as non-expert in this area, I find it confusing rather than helpful. It seems to say that the goal of solving a set of equations is aided by the use of signal-flow graphs, but that they introduce causality unnecessarily. That seems to suggest that a a simple graph rather than a digraph would work just as well. Is that the case? Mason doesn't seem to think so, saying "In accounting for branch directions it is necessary to take an entirely different line of approach from that adopted in electrical network topology." However, he doesn't explicitly state the reason why directionality is significant, and one has to deduce that it is by looking at how he uses the signal flow graph.

I will add some notes on the meaning of causality. Some research needed, but I think it is related to finding a proper sequence of assignments or analog computation when the SFG is simulated (the order of computation is defined by the SFG causality). Papers on Modelica and Bond graph address this issue.Pierre5018 (talk) 00:25, 10 January 2015 (UTC)

So, does Pierre's Note mean that the idea of causality is simply a crutch used to introduce directionality, and isn't really of any importance? Can this matter be explained more carefully? Brews ohare (talk) 16:02, 8 January 2015 (UTC)

will improve the note Pierre5018 (talk) 00:25, 10 January 2015 (UTC)

That section desperately needs an example of at least three equations and three unknowns. I do not understand what is written in that section. Constant314 (talk) 23:21, 8 January 2015 (UTC)

Within a few days I should be able to find time for this; Pierre5018 (talk) 00:25, 10 January 2015 (UTC)

Constant: Would you like to do that? It would help. Brews ohare (talk) 14:56, 9 January 2015 (UTC)

I can't do it because I don't understand what has been written.Constant314 (talk) 21:54, 9 January 2015 (UTC)

It appears that this section intends to show how to construct a signal flow graph that corresponds to a system of equations. You have suggested that an example would be the way to go. There is an example in the cited source that seems to fit your suggestion. Brews ohare (talk) 22:41, 9 January 2015 (UTC)

Yes, it is a lucid example. Thank-you for pointing that out. I also read about the graph transformation rules. In particular the author said "Some elementary reductions of a signal flow graph are shown". In other words he is not asserting that the five reductions shown are a complete set that allows any SFG to be solved. Constant314 (talk) 03:36, 10 January 2015 (UTC)

I just had another look at the example. I counted eight loops. With that many loops, it is easy to miss one. The system matrix for a typical control system is relatively sparse compared to a general set of linear equations. Going back to the example in Deo, which has three knowns and three unknowns, I presume that for the general solution you would have to write MGF from each input to each output (nine in all) and use superposition to get the full expression for each unknown variables. It would be something like

X_j = MGF(Y₁ to X_j) * Y₁ + MGF(Y₂ to X_j) * Y₂ + MGF(Y₃ to X_j) * Y₃

With this much complexity you lose the simplicity of the typical control system SFG. It looks to me like in the general form, it is about the same amount of work as solving the system by determinants. The complexity and the likelihood of making an error probably accounts for the method being somewhat obscure. Constant314 (talk) 17:00, 10 January 2015 (UTC)

I will add a section on Mason's explanation of SFGs as purely causal Pierre5018 (talk) 00:25, 10 January 2015 (UTC)

I will add to the section on solving simultaneous linear equations in two blocks. The first will give setup and justification. The second will discuss computation.Constant314 (talk) 17:31, 10 January 2015 (UTC)

Pierre: Your note remains a mystery to me. Maybe you can explain your use of 'artifact' here, and just what your causal-acausal concerns are about? Brews ohare (talk) 20:40, 10 January 2015 (UTC)

Pierre, did you perhaps mean artifice instead of artifact?Constant314 (talk) 03:46, 11 January 2015 (UTC)

I meant artifact/artefact : a document produced along the way (an engineering work product -- this could be CMMI jargon, sorry if it confused some )

can this whole Pierre's Note section be deleted now?

Pierre5018 (talk) 23:08, 25 January 2015 (UTC)

Solving simultaneous linear equations moved to Examples section

Solving simultaneous linear equations is an example of the use of a signal flow graph. I moving it to the Examples section.Constant314 (talk) 15:04, 11 January 2015 (UTC)

this is *not* an example, it is part of SFG theory Pierre5018 (talk) 21:58, 11 January 2015 (UTC)

I agree with Pierre - See this explanation of my reasoning. Brews ohare (talk) 23:38, 11 January 2015 (UTC)

I acquiesce to the majority.Constant314 (talk) 04:04, 12 January 2015 (UTC)

One-to-one correspondence between SFG and associated equation set

The claim is made in the article several times that a SFG topology is in one-to-one correspondence with its associated set of equations. Besides being unsourced, the concept of the topology of a set of equations is not explained or linked. In addition, we know there are multiple SFGs that can represent the same equations, so we need some theorem such as all such SFGs can be mapped into one another. We also need to relate this statement to the simplifications of SFGs that modify their topology in the course of using them to solve the equations, Brews ohare (talk) 14:53, 12 January 2015 (UTC)

It would seem that every signal flow graph has a topology, and maybe a particular signal flow graph defines what is meant by one particular topology of its equation set??? Now we need to show that all these signal flow graphs have the identical topology??? Brews ohare (talk) 15:46, 12 January 2015 (UTC)

Can we agree that a given SFG yields a unique set of equations not withstanding the order of the terms and order of the equations?Constant314 (talk) 22:55, 12 January 2015 (UTC)

• Perhaps the confusion comes from the fact that there are equations representing the SFG (one-to-one correspondence) and system equations representing the system (to be modeled in SFG form).
• A SFG can literally be transformed into a set of SFG equations of the form Xj = Fj(X1 .. Xn); equations in that form are easily mapped to a SFG.
• In a system analysis workflow, the SFG is usually derived from system equations (perhaps representing a physical system). Many valid SFGs could be derived from such set of system equations. The process of building a SFG from system equations requires deriving each node function from one system equation. A system equation can only be used once. This process was described in an earlier version of the page, but was deleted. Pierre5018 (talk) 05:33, 13 January 2015 (UTC)

Folks, these comments, whatever their merit, do not bear on the issue of topology and one-to-one mapping between SFG topology and the topology of a set of equations. For that matter, does any source suggest that 'topology' is a property of an equation set? Does any source say all of the many SFGs that lead to the same equation set share the same topology? I am inclined to think that these statements of correspondence between SFG topology and that of its equation sets is a mistaken use of terminology. Brews ohare (talk) 06:41, 13 January 2015 (UTC)

The assertion of the text that needs a source for support is equivalent to: "Every SFG that leads to a particular equation set shares the same topology". Or something equivalent. Then the wording of the claims in the text needs adjustment so that it unambiguously states what the source supports. Brews ohare (talk) 14:51, 13 January 2015 (UTC)

The assertion seems obvious to me. If we have an equation X₃ = C₃₁X₁ + C₃₂X₂ + C₃₃X₃ then any flow graph based on a set of equations that include that equation must have nodes X₁, X₂ and X₃ and a branch with gain C₃₁ from X₁ to X₃, a branch C₃₂ from X₂ to X₃ and a branch C₃₃ from X₃ to itself. Every equation in the set makes assertions about the existence of nodes and branches between them. To me this is like a "the sky is blue" statement. Going the other way the SFG could imply both X₃ = C₃₁X₁ + C₃₂X₂ + C₃₃X₃ and X₃ = C₃₂X₂ + C₃₃X₃ + C₃₁X₁ with the difference being the order of the terms. Of course if the variables are numbered like these, you can always insist the the terms be ascending order.Constant314 (talk) 23:09, 13 January 2015 (UTC)

Or is the problem about the meaning of topology? Two SFGs have the same topology if he have the same nodes and the same branch gains.Constant314 (talk) 23:10, 13 January 2015 (UTC)

Constant: WP does not aim at explaining what WP editors find obvious, but rather what sources have to say. So we need sourced commentary, not editors' views. If you wish to engage in what is likely to be long technical discussion over whether every SFG leading to an equivalent set of equations shares the same topology as all the other SFGs related to the same set, that discussion is useless without sources. Brews ohare (talk) 01:52, 14 January 2015 (UTC)

You are right. Let's have a source or remove it.Constant314 (talk) 02:21, 14 January 2015 (UTC)

Mason's Graph, Coates Graph, Flow Graph, Signal flowgraph ...

These references present Mason's graphs as a specific type of signal flow graphs (i.e. Mason Graph and SFG are not synonyms).

• The Optimum Formula for the Gain of a Flow Graph or a Simple Derivation of Coates' Formula* C. A. DESOER
• Chan, Shu-Park “Section I – Circuits”, The Electrical Engineering Handbook, Ed. Richard C. Dorf, Boca Raton: CRC Press
• GRAPHS: THEORY AND ALGORITHMS K. THULASIRAMAN Ì. N. S. SWAMY

Pierre5018 (talk) 05:50, 13 January 2015 (UTC)

Chen uses SFG and Mason graph as synonyms, and refers to Coates graph as simply flow graph. Others have other views. Maybe you disagree with the intro to Flow graph (mathematics) that tries to reach a balanced presentation of this mish-mash? Brews ohare (talk) 06:33, 13 January 2015 (UTC)

indeed what a mishmash! Shu-Park Chan published in the American Math Society : "Graph Theory and Some of its Applications in Electrical Network Theory" isbn:0821813226 this is probably an authoritative source on terminology (mathematics).Pierre5018 (talk) 04:43, 15 January 2015 (UTC)

Pierre: Authority is not an issue. The trouble is that there is no standard. So the best that can be done is to adopt one approach and point out that there is confusion. That is done in Flow graph (mathematics). Brews ohare (talk) 09:30, 16 January 2015 (UTC)

I think that the solution for this article is to declare the mish mash out of scope for this article with a note at the top that says this article is about xxx. Where xxx might be "signal flow graphs as described by Mason in 1953." Add a few lines about non-linearity and time dependent and then stick to the linear time-invariant SFG.Constant314 (talk) 22:53, 16 January 2015 (UTC)

Yes, this article is about Mason graphs (whether some do and some don"t call them signal flow graphs). And from the standpoint of WP:Undue the space devoted to nonlinear versions should be small, with the focus on the linear case. Because the nonlinear case has so little presence in the literature, I'd say it is not worthwhile to try to form the article for the general case, and just leave the general case to its own subsection. I don't support massive adjustments to achieve a general formulation from the outset. That kind of rewrite is massive, and for almost no audience. Brews ohare (talk) 00:59, 17 January 2015 (UTC)

I agree. The most common user of the article will be looking for the linear time-invariant SFG. He should not have to scroll through pages of text about obscure generalizations.Constant314 (talk) 23:24, 17 January 2015 (UTC)

Let's keep in mind that this article's title is SFG, not linear SFG. I could support a split to a separate article "Linear SFG" if useful, but the SFG article should be kept broad in scope. I suggest waiting until this article has more materials in it (full example, formal methods, simulation). Could we wait a few weeks before making that move?Pierre5018 (talk) 14:58, 17 January 2015 (UTC)

I have been looking at WP:COMMONNAME. There are many guidelines and some of them are in conflict, but I have focused on this sentence: Wikipedia does not necessarily use the subject's "official" name as an article title; it prefers to use the name that is most frequently used to refer to the subject in English-language reliable sources. Thus, if most English-language reliable sources use Signal Flow Graph to refer to the linear time invariant signal flow graph, then an article named Signal flow graph should be about the linear time invariant signal flow graph. Also in WP:NC the sentence Naturalness – The title is one that readers are likely to look or search for and that editors would naturally use to link to the article from other articles. Such titles usually convey what the subject is actually called in English. To me that means that people who are actually looking for the linear time-invariant SFG although they don't know that there are non-linear and time varying versions are going to search for Signal flow graph.Constant314 (talk) 23:38, 17 January 2015 (UTC)

Most readers will be interested in the linear case, and in fact many published works assume the linear case, and some even restrict the subject to the linear case. So the linear case should be the focus, and the nonlinear case is an aside. Brews ohare (talk) 11:58, 18 January 2015 (UTC)

Recent addition of section "Basic flow graph concepts"

The new section on "concepts" is not clear nor sourced. It doesn't clarify anything, and doesn't guide the reader to published discussions. I recommend its deletion. Brews ohare (talk) 15:03, 13 January 2015 (UTC)

Although no purpose for this section has been presented on this talk page, I'm guessing that the goal is to generalize the presentation to go beyond linear systems. Perhaps a way forward would include sources for examples where this generalization is used? Brews ohare (talk) 15:27, 13 January 2015 (UTC)

Maybe this article could help? Brews ohare (talk) 15:36, 13 January 2015 (UTC)

The purpose of this section is to introduce SFGs in general, not separately from linear time-invariant SFGs. Some definitions currently defined in the section Linear flow graphs should be moved here, and a new figure should present the basics . For example, source, sink, node, signal belong upfront. (separation of concerns)

Pierre5018 (talk) 23:27, 13 January 2015 (UTC)

I'd like to see sourced commentary. I suggested one possible source. Brews ohare (talk) 02:05, 14 January 2015 (UTC)

Brews, thanks. Will add as an example of a non-linear flowgraphPierre5018 (talk) 04:54, 15 January 2015 (UTC)

Pierre: This subsection should be merged with any examples added into the subsection on nonlinear flow graphs. A general reformulation of the entire article isn't necessary. Brews ohare (talk) 01:35, 17 January 2015 (UTC)

The argument for an introductory section on basic concepts is to start with terminology that is not specific to either linear or non-linear flow graphs. The title should perhaps be rephrased as "general concepts" or "common concepts". All concerns related to topology of the signal flow is really independent of linearity. These terms that do not depend on linearity of the flow graph need to be presented first anyway (ex. node, sink, source, path, etc...) Presenting these common concepts in the non-linear section would be awkward.Pierre5018 (talk) — Preceding undated comment added 14:45, 17 January 2015 (UTC)

A revised approach is possible, of course. However, already a pretty good presentation is made for the linear case and it connects easily to the linear equations without much explanation. In a separate section on nonlinear applications the commonality can be identified and the differences from linear equations to treat more general coonections between nodes. That way the reader who is starting out can get their feet under them with the linear case, and for those few that wish the more general approach, well, they can be guided to build upon the linear case. I am afraid that beginning with the general case will prove too abstract for the novice and they will find such a beginning abstruse, an issue already raised even before this added abstraction. Brews ohare (talk) 15:41, 17 January 2015 (UTC)

Electrical engineering: step-by-step construction of a signal-flow graph from physical model's equations needs to be condensed

This should be limited to the circuit and the SFG. See WP:NOTHOWTO. It should be placed after the telescope servo example.Constant314 (talk) 23:57, 17 January 2015 (UTC)

This section is not needed at all. A simple example that shows the relation between the signal flow graph and a simple 3 equations with nimerical coefficient suffices. See the simple case in Flow graph (mathematics). Brews ohare (talk) 02:03, 18 January 2015 (UTC)

Agreed, will move and expand this in Wikibook.Pierre5018 (talk) 13:25, 18 January 2015 (UTC)

Linear Signal Flow Graph, Long Quote needs to be paraphrased and explaind

The Long quote from Chen needs context and should probably be paraphrased. See WP:QUOTEFARM and WP:LONGQUOTE. Constant314 (talk) 02:26, 21 January 2015 (UTC)

How about deleting Choma and Chen's quotes; with the paragraphs above, they seem redundant (no more useful).Pierre5018 (talk) 02:38, 21 January 2015 (UTC)

Try it and we'll see how it goes.Constant314 (talk) 03:16, 23 January 2015 (UTC)

Domain of application needs to be paraphrased.

See WP:LONGQUOTE. Constant314 (talk) 02:30, 21 January 2015 (UTC)

Recent additions

Pierre: the new subsections you have introduced are premature and should be deleted until something of value to the reader can be produced. Please remove them and present these half-formed ideas on the talk page here until they have been improved and commented upon 113.160.67.198 (talk) 09:15, 22 January 2015 (UTC)

willing to discuss; please be more precise about which section. Pierre5018 (talk) 01:52, 23 January 2015 (UTC)

Shannon-Happ

OK: For a start let's look at the new section on the Shannon-Happ formula. Several points need to be clarified:

•Why does it belong in this article? Apparently signal flow graphs can be used to derive it, but is it proper topic to explore in an introduction? How come we need to bring up 'stability' etc, etc?

•What on Earth does the theorem say? The mathematical statement of the formula in the source is incomprehensible, of course. There is inadequate background here.

•What is the theorem's value?

Answering these questions requires a long discussion. Your source has many pages about it. I think all we need here is a See also link to a separate article that could handle the details. 203.189.142.124 (talk) 05:44, 23 January 2015 (UTC)

this is in the section history. I will add references and slight rework to show historical significance. Full treatment is not intended here.Pierre5018 (talk) 23:03, 25 January 2015 (UTC)

the page belongs in the history section. Why did you move it, anonymous?Pierre5018 (talk) 02:25, 27 January 2015 (UTC)

The bulleted points have yet to receive your attention. A full discussion isn't required. Just the general points of what the formula says and why it is useful and where the reader who finds these answers interesting can find more about them. 36.37.236.63 (talk) 03:06, 30 January 2015 (UTC)

Agreed . Will add more in the next few days.Pierre5018 (talk) 04:03, 30 January 2015 (UTC)

Dynamic systems analysis

For me, the two subsections under this topic are mumbo jumbo. They don' t explain how signal flow graphs help design. It seems the procedure would be the same without them 203.189.142.124 (talk) 07:08, 23 January 2015 (UTC)

Thanks for the comments; I reworked the section on synthesis. Is the intent clear now ? The section on analysis is very close to the cited source. Does it need improvement? Pierre5018 (talk) 02:42, 28 January 2015 (UTC)

Linear signal-flow graphs: Long Quote by Robichaud needs to be explained.

Robichaud et al. wrote: "The signal flow graph contains the same information as the equations from which it is derived; but there does not exist a one-to-one correspondence between the graph and the system of equations. One system will give different graphs according to the order in which the equations are used to define the variable written on the left-hand side.” This quote is, of course, out of context. Its meaning is unclear without access to the contextual document. It is incumbent on the person contributing a quote to explain its meaning. Robichaud seems to be saying that if there is a SFG in which node A has an arrow to node B and A is to the left of B then a SFG in which node A has an arrow to node B and A is to the right of B is a different SFG. Or is he saying that a system of simultaneous equations in one order is different from the same equations written in a different order? Either way, if that is what he is saying, it’s specious. He must have meant something else, but what is it? Constant314 (talk) 23:42, 23 January 2015 (UTC)

it goes with the statement that there are n! SFGs for a given system of equation. I beleive it does not need context, maybe an example. Regards Pierre5018 (talk) 00:49, 24 January 2015 (UTC)

The 'standard' form for a linear set of equations described above always results in self-loops. Other forms for the equations do not always lead to self-loops. A diagram with self-loops is different from one without. See Flow graph (mathematics) for flow graph for a simple set of 3 equations without self-loops. Then put these equations in standard form and make a new flow graph with self-loops. 203.189.142.124 (talk) 07:07, 24 January 2015 (UTC)

I do not that is it. He explicitly refers to a signal flow graph, not a flow graph and he says the SFG will be different it the equations are used in a different order. Constant314 (talk) 17:24, 24 January 2015 (UTC)

Constant: Indeed Robichaud uses a different example, but his is not the only example that demonstrates the point: algebraically identical sets of equations can be represented by different SFGs. 203.189.142.124 (talk) 00:58, 25 January 2015 (UTC)

I understand that a system of equations can be manipulated into a different system that is equivalent in the sense that that it has the same solution. After putting these equations into standard SFG form, they would have different SFGs. If that is it what the quote means, it needs to be explained in the article. If the quote is not explained and put in context, in the article, then it needs to come out of the article. Constant314 (talk) 17:04, 25 January 2015 (UTC)

Constant: I see no ambiguity in the leading sentences of the quote. What ambiguity is there? 203.189.142.161 (talk) 01:09, 26 January 2015 (UTC)

Nowhere is it explained what "One system will give different graphs according to the order in which the equations are used" means. How does the order in which the equations are used change the graph? Constant314 (talk) 04:00, 26 January 2015 (UTC)

I hope that the new example provides the answer you are looking for. Have a look at the wikibook too Pierre5018 (talk) 03:04, 27 January 2015 (UTC)

Constant: Thank you for the clarification. The phrase "according to the order..." is indeed ambiguous in that simply permuting the equations makes no difference to the SFG. However, altering the terms in an equation by substituting say an equivalent for one variable into one of the equations will change the SFG. 36.37.237.170 (talk) 01:01, 28 January 2015 (UTC)

For example, putting an equation in 'standard' form by adding the variable x_j to both sides of the j-th equation introduces a self- loop. 36.37.237.170 (talk) 04:43, 28 January 2015 (UTC)

The citation needs a page number.Constant314 (talk) 17:14, 1 February 2015 (UTC)

Page number is already there (page=x, i.e. roman 10)Pierre5018 (talk) 01:00, 5 February 2015 (UTC)

Systematic reduction of a linear flow graph to solve its gain - Disputed

This section continues to suggest that general signal-flow graphs can be solved by repeated application of the simplification rules. This is not true. If it were true then there would be no need for Mason’s gain formula. Mason makes it clear that the only graphs that can be solved in this manner are forward cascades with no feedback. As a simple case, look at the example of a signal flow graph created by a system of three linear equations in three unknowns. The simplification rules cannot be applied to this case to connect inputs directly to outputs. Constant314 (talk) 04:01, 30 January 2015 (UTC)

I added additional quotes from severay authors. The Mason formula is an alternative to systemic reduction. Both methods are taught as ways to solve SFGs. Mason did not write that systemic reduction doesn't work. I will include how to solve the three linear equations in the wiki book.Pierre5018 (talk) 00:11, 31 January 2015 (UTC)

If you read few sentences in Robichaud beyond your quote, on page 10, just above fig 1-5 he says "These transformations are sufficient for the reduction of a cascade graph." It is not a statement about a general graph. On page 12 he says "An index-residual graph containing only sources and sinks besides index nodes cannot be reduced further without the elimination of a loop." If you cannot eliminate the index nodes then you cannot solve the SFG with graph transformations. Constant314 (talk) 16:21, 1 February 2015 (UTC)

Here is an example of a SFG that cannot be reduced to a single edge from input to output by elementary graph transformations.

. Constant314 (talk) 16:47, 1 February 2015 (UTC)

Constant, please have a look in {{Wikibooks|Control Systems|Signal Flow Diagrams|Examples of systematic reduction}}Pierre5018 (talk) 04:17, 3 February 2015 (UTC)

I had a look. I can verify that all your intermediate results had the same gain. But, you clearly reduced the index of the flow graph which your own reference says cannot be done. One or more of your steps must be more than an elementary transformation. I don't know which one. Perhaps if you listed each transformation rule at each step it would be clearer. Constant314 (talk) 02:26, 4 February 2015 (UTC)

The definition of an elementary transformation varies from author to author:

(1) Some authors only consider as elementary transformations the summation of parallel-edges gains and the multiplication of series-edges gains, but not the elimination of loops¹ (2) Other authors also include the elimination of self-loops as elementary transformations.²

Sources

¹ Louis P. A. Robichaud (1962). "§1.5 Reduction of the signal flow graph". Signal Flow Graphs and Applications. Prentice Hall. pp. 12, 137.

²Mauro Sonatros, Nuna Horta (2012). "Chapter 16: §4.1.2 Signal flow graphs algebra". In Mourad Fakhfakh, Esteban Tlelo-Cuautle, Francisco V. Fernández, eds (ed.). Design of Analog Circuits Through Symbolic Analysis. Bentham Science Publishers. pp. 418 ff. ISBN 9781608050956. {{cite book}}: |editor= has generic name (help)CS1 maint: multiple names: editors list (link)

Pierre5018 (talk) 03:36, 5 February 2015 (UTC)

See also Narsingh Deo (2004). "Reduction of signal-flow graphs". Graph Theory with Applications to Engineering and Computer Science. PHI Learning Pvt. Ltd. pp. 419 ff. ISBN 9788120301450. Brews ohare (talk) 14:58, 8 February 2015 (UTC)

I've seen elimination of self loops as an elementary transformation but not interlocked loops where neither contains the other.Constant314 (talk) 19:09, 7 February 2015 (UTC)

Question: If two equivalent sets of equations lead to (say) x=1, y=2, z=3, but correspond to different SFGs, isn't it obvious that these SFGs are related, and moreover, that a transformation process exists that will map one SFG into the other? in fact, isn't the algebraic translation mapping one set of equations into an equivalent set one procedure used to justify valid transformations of SFGs, and the source of many of these allowed graph transformations? Brews ohare (talk) 13:54, 8 February 2015 (UTC)

For me, the best explanation is the equivalence of these topological reductions to Gauss-Jordan reduction of linear equations.Pierre5018 (talk) 17:34, 8 February 2015 (UTC)

You can erase the whole SFG and replace it with one edge and put the gain on the edge equal to Mason's Gain Formula and it would be equivalent to Gauss-Jordin. But you cannot make up a transformation rule just becasue it can be prooved mathemetically. That would be WP:SYN. We need the same thing here that we need on the statement about the mapping of SFG equations in standard form to SFG topology. We need a reliable source that says unambiguously that all SFG's can be solved by elementary transformations and unambiguously what those transformations are. I doubt that such a reference exists because Mason and Robichaud say you cannot reduce the index with elementary operations (Mason calls them explicit transformations). Robichau expressly distinguishes between elementary transformations and elimination of a loop. Constant314 (talk) 18:04, 8 February 2015 (UTC)

The remark that "you can't make up a transformation rule just because it can be proved mathematically" makes no sense to me. If a rule is " proved" it isn't "made up". The division of transformations into "elementary" and "other" transformations has not been explained here nor what is the purpose of this division. In any event quarreling over whether a transformation is elementary or not seems pointless. The real issue is how SFGs can aid in understanding the equations and presumably the simpler the SFG the clearer this understanding will be, so we want to arrive systematically at the simple forms. Brews ohare (talk) 19:42, 8 February 2015 (UTC)

The issue is that if, as claimed in the article, all SFG's can be solved with elementary transformations alone, then the claim needs a credible, unambiguous citation.Constant314 (talk) 21:52, 8 February 2015 (UTC)

I've attempted to resolve this issue by quoting Robichaud more carefully, indicating that he does not suggest that elementary operations are all that are needed. I have removed the template indicating a difference of opinion anticipating this matter is now resolved. Brews ohare (talk) 17:31, 10 February 2015 (UTC)

That is an improvment but the sentence before it, "The rules presented below are applied over and over until the signal flow graph directly connects the sink nodes representing the dependent variables to the source nodes representing the independent variables. By using elementary equivalences, any transfer function can be derived from a signal-flow graph by successively collapsing internal nodes until only the input and output nodes remain" is still misleading. I'll make my own attempt to make it correct and see how that sits.Constant314 (talk) 22:22, 10 February 2015 (UTC)

I've made some minor additional changes and clarified that Robichaud's algorithmic reduction applies to his generalized flow graph. Brews ohare (talk) 13:51, 11 February 2015 (UTC)

Constant's claim that it is misleading needs to be supported by a counterexample.Pierre5018 (talk) 15:57, 11 February 2015 (UTC)

Pierre: I believe the article now states Robichaud's position accurately, which I believe Constant agrees with. Brews ohare (talk) 02:03, 12 February 2015 (UTC)

I apologize for only being here on weekends. I agree with Brews that the section, at this moment, has no factual errors or misleading statements. If we all agree with that, then let's stop this topic and start a new one about improving the section.Constant314 (talk) 20:51, 14 February 2015 (UTC)

Criticism of SFGs

This section presents the view that SFGs are somehow tied to an interpretation using causality. These views are erroneous, at least for the SFG that is simply an expression of a system of algebraic equations. If the content of this subsection is to be retained it should be placed as a controversial view in the parts of the article dealing with causality as only an interpretation of the SFG useful in some specific, limited applications. Brews ohare (talk) 15:09, 13 February 2015 (UTC)

I've rearranged the sections and subsections to put the causality-acausality issues all in one place. Brews ohare (talk) 15:52, 13 February 2015 (UTC)

Relation to block diagrams

This subsection is incomplete and erroneous as it stands. Block diagrams are more general than signal flow graphs and are not subject to the same rigorous mathematical requirements. I have removed the inaccurate lead sentence. Brews ohare (talk) 16:13, 13 February 2015 (UTC)

There are many types of block diagrams. The block diagram type that is illustrated in this section is as rigourous as SFGs. The lead sentence was actually representative of some authors. See for example [3] Pierre5018 (talk) 02:28, 18 February 2015 (UTC)

The removed sentence appeared to be a general statement, and therefore was misleading. Brews ohare (talk) 03:44, 18 February 2015 (UTC)

Changes made

I've done some reorganization and rewording and added a few sources. No changes in substance, I believe. Brews ohare (talk) 15:56, 14 February 2015 (UTC)

Some rearrangement of the sections

4.3.4 Implementations refers to “the above procedure” which I think means 4.3.1 Putting the equations in "standard form". 4.3.3 Systematic reduction ... is in between those sections. Also, Systematic reduction applies to all of linear flow graphs and not just to solving linear equations, so I propose to promote Systematic reduction up one level so that it is a sub-topic of Linear Flow Graphs. Constant314 (talk) 21:17, 14 February 2015 (UTC)

I think your change works. Brews ohare (talk) 16:57, 15 February 2015 (UTC)

State of the article

This article is much better than it was a month or two ago, but it contains a lot of repetition and is poorly organized. Brews ohare (talk) 18:36, 15 February 2015 (UTC)

Causality

I think the section on causality can be reduced to a couple of sentences in the introduction. Since a system of simultaneous linear equations can be made equivalent to a SFG, the SFG inherets the ability of linear equations to represent both causal and acausal; the is no controversy. Constant314 (talk) 21:38, 17 February 2015 (UTC)

I'd say there should be no controversy, but several sources muddy the water, so a clear statement is useful. Brews ohare (talk) 03:43, 18 February 2015 (UTC)

I favour keeping the extended critisism of SFG causality, since causality is a major point of differentiation from bond graphs (in which causality is explicit)Pierre5018 (talk) 12:18, 18 February 2015 (UTC)

Brews, I have no objection to a clear statement; I just don't think it needs a section. Pierre, I don't see anything that could be criticized. I think bringing in bond graphs is extraneous to this article, but a single sentence would be sufficient to say something like "The SFG may represent both causal and acausal relationships, unlike the bond graph in which causality is explicit."

Constant: I am with Pierre on this one for a different reason. That reason is that Kuo (a very influential text), Mason himself, Paynter, and Willems stress causality, which means confusion reigns without a clear disclaimer that SFG has no necessary connection to causality. Brews ohare (talk) 16:02, 18 February 2015 (UTC)

Are you trying to say that an arrow from node A to node B in a SFG does not guarantee that A is cause of B?Constant314 (talk) 22:19, 18 February 2015 (UTC)

Yes. The SFG is a mathematical device, and just as Newton's law F=ma could be interpreted as saying force causes acceleration, it can be interpreted as saying acceleration is an indication of the presence of a force, or interpreted as how much acceleration corresponds to how much force. The math is neutral on the causal interpretation. Brews ohare (talk) 16:36, 19 February 2015 (UTC)

Brews ohare is right, see Shannon's or Mason's original works. Example:

(a) Before path inversion

(b) After path inversion

The first graph corresponds to the equation $z=ax+by$, the second graph to the equation $x={\frac {z}{a}}-{\frac {by}{a}}$. I suggest we remove the whole philosophy discussion, and replace it by the simple statement that sfgs do not contain causal information, but can under some circumstances be drawn in a way such that the way they are drawn does convey it. This is then not a mathematical property of the graph, but a meta-property of the way to draw the equations system. I think it is sufficient to cite Mason56 on this. Hanspi (talk) 06:00, 24 September 2020 (UTC)

I agree. The section is not remotely encyclopedic. It reads like a conversation. It could probably be reduced to one sentence in another section. The arrow does not imply causality. Constant314 (talk) 06:27, 24 September 2020 (UTC)

Causality

It has taken a while, but I think I see it now.

Acausal relationships cause loops in the SFG. Lots of acausal relationships cause lots of loops. SFG’s are lousy when there are a lot of loops. They are not obvious. Its easy to make an error when computing MGF.

Most circuits have lots of acausal relationships. SFG’s are lousy for solving most circuits.

Most systems of general simultaneous linear equations have lots of acausal relationships. SFG’s are lousy for solving most systems of general simultaneous linear equations.

SFG's can represent acausal relationships, but there are better tools. SFG's work best when most of the relationships are causal.Constant314 (talk) 02:20, 19 February 2015 (UTC)

It is simpler than that. Mason and others construct SFGs using intuition about the systems they are interested in. So a node 'broadcasts' its output along emanating branches, and these signals are received by other nodes (cause a reaction there). The emanating node causes an effect at the receiving node.

All well and good and maybe helpful in setting up an SFG for some kinds of system. But completely unnecessary. The equation set determines the SFG (or SFGs), and whether a causal argument can do it too is incidental. Brews ohare (talk) 03:03, 19 February 2015 (UTC)

Angular position servo and signal flow graph. θ_C = desired angle command, θ_L = actual load angle, K_P = position loop gain, V_ωC = velocity command, V_ωM = motor velocity sense voltage, K_V = velocity loop gain, V_IC = current command, V_IM = current sense voltage, K_C = current loop gain, V_A = power amplifier output voltage, L_M = motor inductance, V_M = voltage across motor inductance, I_M = motor current, R_M = motor resistance, R_S = current sense resistance, K_M = motor torque constant (Nm/amp), T = torque, M = moment of inertia of all rotating components α = angular acceleration, ω = angular velocity, β = mechanical damping, G_M = motor back EMF constant, G_T = tachometer conversion gain constant,. There is one forward path (shown in a different color) and six feedback loops. The drive shaft assumed to be stiff enough to not treat as a spring. Constants are shown in black and variables in purple.

The equations do determine the SFG, but sometimes the equations are not in SFG form and have to be manipulated. This ties into the solving linear equations section. The importance of that section is not that you can solve linear equations with SFGs but it tells you how to convert acausal relationships into quasi-causal relationships. Using SFGs to solve a general system of linear equations is numerically similar to Kramer’s rule and probably has the same numerical problems.

I’m looking for a reason to include a section on causality and something to say about it that the general non-expert can understand and use. After reading through the various criticisms and those papers that are available I came up with what I wrote at the top of this section. SFGs, even when constructed by Kou’s rules do not guarantee causal relationships. SFGs force non-causal relationships into quasi-causal forms that are complicated. The only reason to force these non-causal relationships into SFG form is because the system is made up of mostly causal relationships. The telescope servo illustrates this point. It is made up of mostly causal relationships, except the relationship between V_M, the voltage across the motor inductance and I_M the motor current. We see a loop between these nodes which says in effect V_M is a cause of I_M and I_M is a cause of V_M. The SFG is made up of mostly unidirectional components such as amplifiers and sensors, but it has a little bit of circuitry involving the motor winding, its resistance and the current sense resistance. The reason to represent the circuitry as a SFG is because the SFG is so darn useful representing the rest of the system. Constant314 (talk) 12:04, 19 February 2015 (UTC)

It might help me to understand your remarks if I attempt to paraphrase them.

One of your points is:

The equation set one derives naturally for some systems using causality are not in SFG form.

See Response 1 at the bottom.

Inasmuch as the SFG is readily representative of even the most general set of consistent algebraic relations between a set of n variables, I need an example of a set of consistent equations that are outside the reach of this most general formulation.

See Response 2 at the bottom.

A second point is:

SFGs may not provide a system interpretation that satisfies causal requirements.

A simple example would help the imagination. You seem to suggest a feedback loop is an example - maybe you could refer to the SFGs provided for the negative feedback amplifer? It is hardly surprising that the acausal nature of an SFG results in a noncausal formulation of system behavior. However, as a counterpoint, Newton's laws are causal and govern many systems. Their causality does not preclude a formulation in terms of ordinary algebraic equations where causality doesn't show up. In fact, numerical algorithms for solving most problems end up in matrix form.

See Response 3 at the bottom.

So there are a couple of points here that you raise concerning the utility and the applicability of SFGs that might be valid, although you haven't clearly expressed or sourced them. Have I got them straight? On the other hand, even with granting these points and their value (only an assumption at this point), they are not at all contradictory of what is said in the article so far. Do you agree? Brews ohare (talk) 15:57, 19 February 2015 (UTC)

See Response 4 at the bottom.

Continued

Comments: (I hope this will help)

Causality can refer to two distinct concepts: (1) physical causality inherent in the system being modeled by equations. For example, if you connect a resistor across a voltage source, the current flowing in the resistor is caused by the physical voltage across the resistor. (2) implementation causality in a simulation on an analog or digital computer. Implementation causality is a concern when implementing a computer simulation based on a SFG, whereby the input-output of the computer implementation blocks will follow the causality of the reference SFG (used as a blueprint for implementation).

In an analysis workflow, after the n equations to be solved have been identified, any derived SFG will depend on the chosen association of equations to each of the dependent variables. There could be up to n! SFG possibilities. Loops represent cyclic dependencies in the set of equations.Pierre5018 (talk) 00:10, 21 February 2015 (UTC)

Well, Pierre, your distinction of two types of causality is a bit obscure to me, so let me try to restate what might possibly be your points.

I understand physical causality, which in your example is simply the observation that when one thing consistently happens subsequent to another, the first is a "cause" of the latter. Closing a switch "causes" the current to flow. (Or, is the "cause" the desire for light? ◔̯◔ )

The causality in this discussion is simply a reference to the Input-Output representation inherent in an SFG or a block diagram: an input signal is processed by a block or a branch and produces an output signal. In the resistor example, if the resistor is connected to a current source, the voltage produced at the terminals of the resistor is a function of the source's current signal. Thus, there is no SFG model that can accommodate both usages of the same resistor (connected to a current source or connected to a voltage source). On the other hand, other modeling notations can capture an acausal equation such as $V-RI=0$. A stated benefit of acausal modeling is better reuse of models since equations do not specify Inputs and Outputs (explicit signal flow direction). Pierre5018 (talk) 01:15, 24 February 2015 (UTC)

The idea of "implementation causality" is new to me. Supposing, as I think you agree, that the SFG is a representation of some set of algebraic and noncausal relations between n variables, I take the term "implementation causality" as a way to introduce the term "causality" into a description of the noncausal SFG without any suggestion of physical causality.

This discussion of causality is meaningful when an SFG is used for the purpose of implementing an analog or digital computer simulation. The SFG is a causal representation derived from causal or acausal relationships.Pierre5018 (talk) 01:15, 24 February 2015 (UTC)

It occurs to me that your "implementation causality" describes how a computer program or algorithm can be arranged to solve a set of equations using various strategies. They differ in how they prioritize finding some of the variables in terms of the others, and these algorithmic decisions, which are simply about solution strategy, then make the variables eliminated earlier in the solution "effects" of the remaining variables that are now "causes".

The discussion is referring to implementation by analog or digital computer simulations (not an analytical solver).

So the SFG identifies "causes" (the "fundamental" variables of a particular strategy) without implying any physical causation. As a clarification intended for Constant, it can be said that the processing at a node that sums various incident branches is "caused" by those inputs, which is an "implementation" causality without any suggestion of physical causation. Different SFGs for the same system will identify different "causes", simply as a result of corresponding to different solution strategies.

Is this what you are saying? Brews ohare (talk) 18:14, 21 February 2015 (UTC)

This is my understanding Pierre5018 (talk) 01:15, 24 February 2015 (UTC)

I'm not sure what Pierre means by causality but I also see two uses. In one case it means that effects never precede their cause. In this sense, all the voltages and currents in a circuit are caused by the inputs. The other usage is cause and effect. A force on a mass causes acceleration. A current forced through a resister causes a voltage across that resister. A voltage held across a resister causes a current through the resister. More commonly, in a circuit, neither causes the other, but they are related by ohms law. Whatever causes the voltage and current causes them in such a way that ohms law is not violated. In this case, ohm's law is an acausal relationship in which the neither voltage nor current strictly causes the other. SFG's can represent acausal relationships in both senses.Constant314 (talk) 22:26, 21 February 2015 (UTC)

Constant: I thought you had some disagreement with what had been said here, and I don't see how this remark bears upon that. Brews ohare (talk) 09:28, 22 February 2015 (UTC)

See Response 5 at the bottom.

Gathered comments by Constant

I gathered my scattered comments so that they are all here at the bottom.

Response 1. In response to Brew’s comment “One of your points is: The equation set one derives naturally for some systems using causality are not in SFG form.”

Yes.

Response 2. In response to Brew’s comment “I need an example of a set of consistent equations that are outside the reach of this most general formulation.”

I'm not suggesting that any such set of equations is outside the reach of a SFG. I'm suggesting that the SFG for many sets of equations is complicated beyond the point of being useful. Your own example of converting three equations in three unknowns is an example. It is not completely useless in the sense that you could compute MGF just as you could use Kramer's rule. But neither give you any intuitive feel for the real flow of cause and effect. When you look at that SFG, there is a branch from every node to every non-input node.

Response 3. In response to Brew’s comment “...Newton's laws are causal...”

Looking at Newton's laws in an atmosphere. Gravity (force) on a mass causes acceleration which causes velocity which causes drag which reduces the force on the mass. The relationship is acausal (not strictly cause and effect), in the sense that acceleration pushes back against the force.

Response 4. In response to Brew’s comment “...you raise concerning the utility and the applicability of SFGs that might be valid... ”

Thanks for your comments. I am trying to understand the section on causality. Why is it there and what does it mean in plain language. It appears to be just a random collection of quotes and facts out of context that are hard to understand without the rest of the context. For example, what does Karnopp mean by "Some perfectly reasonable physical models simply will not compute because of causal problems." Probably what I haven't clearly expressed is that I'm asking what the section means and expressing what the section seems to mean to me which is this: there are implementation problems that arise when attempting to use SFG's to represent systems with many acausal relationships. Given the age of many of these sources and the advance of computers and computer science, the criticisms may be insignificant. We have SPICE for analysis of circuits and all their acausal relationships. Is it meaningful to criticize a SFG because it is not very convenient for solving circuits? This is what the section seems to be saying to me.

Response 5. In response to Brew’s comment “I thought you had some disagreement with what had been said here”

I don't disagree with what is written there. I am concerned with what is missing. A clear statement as to which meaning of causality is being used is an example. What is there is so incomplete and out of context that it could be summarized in a couple of sentences. I made responses to some of your comments in-line instead of at the bottom. Did you see them? Perhaps I should move them to the bottom.

• Follow-up by brews ohare:

1. The notion of "SFG form" is vague. As the SFG corresponding to a set of n equations can have n! forms, there is no special form. The article's "standard form" is just a construct that shows an SFG always is possible (but clumsy), and all authors agree a "useful" SFG is one that displays only key relationships. It is obvious that one may have to struggle with many possible diagrams to find the best one. Your view might be that some approaches based on personal intuitions about causality will lead one to the most useful forms quickly. That, of course, depends upon the efficacy of those particular intuitions. Undoubtedly, some engineers will grasp key relationships intuitively, and get to a valuable SFG in a hurry, whether that intuition involves causal understandings or something else. Is it worthwhile to suggest "causality" has some role in arriving at a useful SFG? Not unless there are some pointers that generally are accepted.

2. Seems to be the same point.

3. Your notion of "causal" doesn't fit with philosophy or science Maybe the clearest example of its use is in the Kramers-Kronig relations. The simplest statement of causality is to say a causal theory professes that future events can be predicted using only present and past events. (A more general formulation is here.) However (and irrelevant here, I surmise), this idea has limited value today in view of the known formulations based upon minimizing functions of system variables and avoiding the concepts of past, present, and future and what exactly is an 'event'. (Each theory identifies its own set of 'events' it wants to deal with, and doesn't try to include everything.)

4. At the moment, the section on causality is primarily an attempt to correct misinformation about SFGs that they are somehow less useful because they don't express causality according to the "bond graph" people, or SFGs are limited because they are restricted to constructions based upon causality, as per Kuo. These claims contradict each other and both are false or at least misleading. That is the purpose of the section. You might have some ideas to make it clearer?

5. You say this section is incomplete, in part from a failure to discuss "causality". I don't regard that as an issue - see point 3. However, you also have mentioned elsewhere it doesn't discuss utility of the SFG or how useful SFGs can be found efficiently instead of dealing with clumsy ones like the "standard" form. That info is indeed missing here, although part of the article elsewhere describes how to reduce clumsy SFGs. This omission doesn't make the section useless or easy to summarize in asides elsewhere in the article. Brews ohare (talk) 15:56, 22 February 2015 (UTC)

By SFG form I mean the form as defined by Kou. I agree that one meaning of the word causality is that future events can be predicted using only present and past events. Actually, I would say it means that future events do not affect the present. However, that is not the meaning that it is being used in the causality section of this article. If that were the meaning in use then there would be nothing to discuss. SFG's modeling real real physical systems would always be causal in that sense if they were an accurate representation of the physical system.Constant314 (talk) 20:01, 22 February 2015 (UTC)

What meaning do you think is being used? And, no, SFGs are acausal, regardless of causality in the system modeled. Because algebraic equations relating n variables simply have no causal connections. Possibly, if the gains are Laplace transforms of response functions these functions reflect causality, but not the SFG itself. Brews ohare (talk) 21:36, 22 February 2015 (UTC)

Brews, causal and acausal is being used in the sense that ohms law, V = IR, is an acausal relationship. It says that V and I have this relationship without saying that either is the cause or the effect. They could both be effects from some other cause. Constant314 (talk) 11:32, 24 February 2015 (UTC)

What does Kuo mean when he says an SFG depicts a cause-and-effect relationship?

Here is one quote from Kuo:

"The transmissions t_kj by directed branches, (7-7) implies that the system equations may be portrayed by a signal flow graph. The construction of the signal flow graph is basically a matter of following the cause-and-efect relationships through the system relating each variable to itself and to the others, using the basic building blocks of Fig. 7-1."

Another quote is:

"The SFG was introduced by SJ Mason for the cause-and-effect representation of linear systems that are modeled by algebraic equations." Automatic Control Systems, p.48

What does Kuo mean by "cause-and-effect"? I submit that it is what Pierre has called "implementation causality".

If there is any controversy on this point, I'll discuss it further. Is there any? Brews ohare (talk) 02:26, 23 February 2015 (UTC)

Kuo suggests Mason introduced 'cause and effect', and in this paper, Mason says:

"The process of constructing a graph is one of tracing a succession of cause and effects through the physical system. One variable is expressed as an explicit effect due to certain causes; they in turn, are recognized as effects due to still other causes." (Section IV: Illustrative applications of flow graph technique)

This passage can be taken as just heuristic, or a possible technique, for guiding a reader in the rapid construction of a signal-flow graph. As such it is not intended to suggest that physical cause and effect are part of the conception of a signal flow graph - only an interpretation sometimes useful for making a graph.

Mason also refers to the graph as a transmission system:

"The flow graph may be interpreted as a signal transmission system in which each node is a tiny repeater station. The station receives signals via the incoming branches, combines the information in some manner, and then transmits the result along each outpoint branch."

In this quote it can be taken that Mason is suggesting a suitable but not a necessary or required perspective, and he proceeds to show how equations are related to this interpretation. The reader is free to assume that any interpretation that leads to these equations is satisfactory.

The connection of Mason to cause and effect is open to discussion, but this entire paper is about the connections of flow graphs to equations, so the physical "cause and effect" connection seems to me to be more or less intended as an example of a construction process that leads to certain equations, and hence, to certain flow graphs.

As an alternative description we have Choudhury: Networks and Systems:

"An alternate approach to find the relationships among the system variables of a complicated network or system is the signal flow graph approach by SJ Mason. A signal-flow graph is a diagram which represents a set of simultaneous linear algebraic equations. It consists of a network in which nodes are connected by directed branches. Each node represents a system variable, and each branch connected between two nodes acts as a signal multiplier. A signal flow graph contains, essentially, the same information as a block-diagram representation...(p. 757)

It is noteworthy that no mention is made of cause and effect.

We have also Dorf & Bishop: Modern Control Systems:

"A signal-flow graph is a diagram consisting of nodes that are connected by directed branches and is a graphical representation of a set of linear relations...The flow graph is simply a pictorial method of writing a system of algebraic equations so as to indicate the interdependence of the variables." (9th edition, p. 67)

Again no reference to "cause and effect". And we have Borutsky:

"Like block diagrams, signal flow graphs represent the computational, not the physical structure of a system." [ Wolfgang Borutzky, p. 10]

The present intro uses the approach of Choudhury, of Dorf & Bishop, and of Borutsky, and seems appropriate. The question arises whether the "cause and effect" comments that appear in the literature and are (IMO) misleading, need to be mentioned and put into perspective as attempted here. Brews ohare (talk) 16:09, 23 February 2015 (UTC)

It can be noted that Janschek has introduced two types of "causality" along the lines suggested by Pierre: "system causality" describing systems for which outputs at a given time are unaffected by inputs at future times, and "computational causality", a sequencing of equations for their sequential solution. Brews ohare (talk) 00:31, 24 February 2015 (UTC)

Vichnevetsky & Miller say: "Bond-graph literature uses the term computational causality, indicating the order of calculation in a simulation, in order to avoid any interpretation in the sense of intuitive causality." Brews ohare (talk) 00:36, 24 February 2015 (UTC)

An example is provided by Cellier:

"The computational causality of physical laws can therefore not be predetermined, but depends upon the particular use of that law. We cannot conclude whether it is the current flowing through a resistor that causes a voltage drop, or whether it is the difference in potentials at the two ends of the resistor that cause current to flow. Physically these are simply two concurrent aspects of one and the same physical phenomenon. Computationally, we may have to assume at times one position, and at other times the other." François Cellier & Ernesto Kofman: §1.5 Simulation software today and tomorrow, p. 15

Brews ohare (talk) 01:43, 24 February 2015 (UTC)

It's clear that Mason and Kuo did not use the term "computational causality" as it had not been coined when their work was written, but it seems their notion of causality fits "computational causality" inasmuch as the signal-flow graph does have a connection to this form of causality but has no connection with physical causality. Brews ohare (talk) 03:13, 24 February 2015 (UTC)

I agree with your interpretations. In particular, I have reread Kou, sixth edition p. 77, he says “ A SGF may be defined ...” rather than ”A SFG is defined ... “. I think he is using cause and effect as a way of describing the construction process. I also agree that none of the uses is connected to physical causality. I think that yes, computational causality is equivalent in every case. And I conclude that there is no controversy and the section ought to be greatly compacted by eliminating most of the quotes (but keeping them internal to the citation would be fine) and rewriting the section in plain declarative language that does not leave the reader with the need to infer all this for himself.Constant314 (talk) 11:48, 24 February 2015 (UTC)

I have rewritten the material on causality in the subsection now titled Interpreting 'causality'. It is now clearer, though perhaps not a short as you would like to see it. Brews ohare (talk) 18:08, 24 February 2015 (UTC)

Satisfactory. Thank-you. Clarity is more important than brevity.Constant314 (talk) 21:26, 24 February 2015 (UTC)

It might be worthwhile to note computation includes analog computation. An amplifier may be said to compute its output from its input. A motor may be said to compute its position from its velocity. Or maybe not.Constant314 (talk) 21:41, 24 February 2015 (UTC)

Constant: I haven't any ideas about how to introduce analog solutions to a set of equations into a discussion about "computational causality". And a source would be necessary. Brews ohare (talk) 15:52, 25 February 2015 (UTC)

I think this discussion is hopelessly entangled by Kou's choice of words. Its best to consider this particular choice of idioms to be an unfortunate but risible error. (details below separately rather than as a reply) If you sample a few IEEE journals you'll find that E.E.'s who write well are the exception, not the rule. As a practicing art with significant commercial value only a small fraction of Ph.D. E.E.'s are willing to engage in the incessant intramural warfare of the academy for 1/3 pay or less. Consequently, the combination of the two should probably be listed an endangered species to protect them from being harassed for minor transgressions. PolychromePlatypus 00:33, 9 April 2019 (UTC)

"Causal" is clearly a distracting substitute for "linear, time invariant" to non-engineers. Signal flow graph analysis assumes that the time domain response and spectral domain response of the system transfer function are freely convertible. That requires the Laplace transform of the system transfer function to be valid, and therefore requires that the system's transfer function is linear (i.e. independent of amplitude) and time invariant (i.e. the same at all times). An analysis of a time varying, non-linear, or unstable system may not be valid, and usually isn't in proportion to the extent that it exhibits those traits. For example, a BJT amplifier with a particular feedback network may behave as indicated by signal flow graph analysis for small signals but at some sufficiently large signal level increased Miller effect delay may increase its phase delay enough to cause the amplifier's feedback to become reinforcing and it becomes a bistable, a square wave oscillator. When operating as a bistable it no longer exhibits any small signal gain and its output is no longer related to the input. Signal flow graph analysis won't be able to model the behavior of such a system, even though it's causal in the usual sense. PolychromePlatypus 00:33, 9 April 2019 (UTC) — Preceding unsigned comment added by PolychromePlatypus (talk • contribs)

So, what do you want to change? Constant314 (talk) 02:01, 9 April 2019 (UTC)

Systematic re-write of the whole article

I think this article is way too bloated. A wikipedia article should be nuch more concise. I suggest to rework it systematically, starting from the centre, Signal-flow_graph#Linear_signal-flow_graphs and afterwards working outwards.Hanspi (talk) 06:23, 24 September 2020 (UTC)

Linear signal-flow graphs

The re-write I suggest is to massively abbreviate "Systematic reduction to sources and sinks" by giving one reference to reduction rules and obe example, rewrite "Basic components" to the much shorter description originally used by Mason, and changing "Solving linear equations" to a correspondence between the matrix notation of a linear equation systemm instead of the Kronecker delta notation. My estimate is that the section will then be a third of the length. Opinions?Hanspi (talk) 06:23, 24 September 2020 (UTC)

Yes, I agree with greatly reducing the ""Systematic reduction to sources and sinks" section. And the section should probably be renamed "simplification."Constant314 (talk) 06:34, 24 September 2020 (UTC)

Sorry to ask a noob question: where is the proper place to write down the suggested new content for review? This page here?Hanspi (talk) 14:28, 24 September 2020 (UTC)

I think most people would write the content in their sandbox and then transfer it here. You have your own sandbox which you access by clicking the "Sandbox" link in the upper right corner of the page. Once you have it like you want it, you could invite us to view your sandbox; but in this case I'm going to suggest that you be bold WP:BB and simply replace the sections that we have discussed recently here. Some other editor may disagree and revert it. Don't let that bother you. It happens frequently. It means that we come back here to the talk page and find a consensus. Constant314 (talk) 15:16, 24 September 2020 (UTC)