Sarbajit, Thanks for your comments/questions about my Fed suggestion. I'm not an engineer and wasn't thinking about a PID control mechanism. (In fact, I had to look it up <http://en.wikipedia.org/wiki/PID_controller>!) I was leaving the decision about how to move the levers/dials to FED personnel and wasn't thinking about whether there would be a nice algorithm that gave correction values in terms of current error, past accumulated error, and predicted future error. I suspect that macro economics is not yet up to that. But perhaps I underestimate it. I would like to see a futures market in predicted corrections, which might do a good job.
Nick, Saying that the light is green is reporting an observation. Saying the light is in a green state is making a statement about the light as a mechanism. As I said, I think of the notion of state as identifying a collection of functionalities. So attributing a "green state" to the light implies that when in that state it has a specific set of functional attributes. Saying that the light is green doesn't say anything like that. So I'd say that there is a big difference. "The light is green" is an observation; "the light is in a green state" claims that when in that state the light acts and is capable of acting in certain ways that may be distinct from how it acts and is capable of acting when in other states. (I say "may be" because a mechanism may have two distinct states that are indistinguishable wrt their operational characteristics. Have two such states would suggest design redundancy, but I can't deny the possibility. In software one generally doesn't want such states. In engineering systems such redundancy is often created for the sake of safety.) *-- Russ Abbott* *_____________________________________________* *** Professor, Computer Science* * California State University, Los Angeles* * My paper on how the Fed can fix the economy: ssrn.com/abstract=1977688* * Google voice: 747-*999-5105 Google+: plus.google.com/114865618166480775623/ * vita: *sites.google.com/site/russabbott/ CS Wiki <http://cs.calstatela.edu/wiki/> and the courses I teach *_____________________________________________* On Sun, Apr 14, 2013 at 9:36 AM, Nicholas Thompson < nickthomp...@earthlink.net> wrote: > Russ, **** > > ** ** > > Ok. So, the question is, what is the “value added” of saying “green > state” rather than just saying that the “light is green”. Something comes > through the gate with the camel, so to speak. What is it? N**** > > ** ** > > *From:* Friam [mailto:friam-boun...@redfish.com] *On Behalf Of *Russ > Abbott > *Sent:* Saturday, April 13, 2013 10:03 PM > > *To:* The Friday Morning Applied Complexity Coffee Group > *Subject:* Re: [FRIAM] Systems, State, Recursion, Iteration.**** > > ** ** > > Never beaten over the head with “hypothetical construct” or “intervening > variable”. My notion of state is basic theoretical computer science. How > an automaton (a formally defined mechanism such as a Turing Machine, Finite > Automaton, etc.) reacts to its input depends on its state. This isn't > intended to be particularly sophisticated. It's just a technique used when > specifying how things interact with their environments. **** > > ** ** > > When a traffic light that controls a crosswalk is in the green state (in > your direction) and you press the cross button, it ignores that input. When > it's in its red state (in your direction) and you press the cross > button, it starts counting down to turning green. How long the countdown > will be depends on another element of its state: how much time has passed > since the most recent green.**** > > > **** > > **** > > *-- Russ Abbott* > *_____________________________________________***** > > * Professor, Computer Science* > * California State University, Los Angeles***** > > ** ** > > * My paper on how the Fed can fix the economy: ssrn.com/abstract=1977688* > * Google voice: 747-999-5105***** > > Google+: plus.google.com/114865618166480775623/**** > > * vita: > **sites.google.com/site/russabbott/*<http://sites.google.com/site/russabbott/> > **** > > CS Wiki <http://cs.calstatela.edu/wiki/> and the courses I teach > *_____________________________________________* **** > > ** ** > > On Sat, Apr 13, 2013 at 8:48 PM, Nicholas Thompson < > nickthomp...@earthlink.net> wrote:**** > > Thanks, Steve. Will ponder all of this. Nick **** > > **** > > *From:* Friam [mailto:friam-boun...@redfish.com] *On Behalf Of *Steve > Smith > *Sent:* Saturday, April 13, 2013 8:47 PM**** > > > *To:* The Friday Morning Applied Complexity Coffee Group**** > > *Subject:* [FRIAM] Systems, State, Recursion, Iteration.**** > > **** > > Nick - > > It would be difficult to explain this (Marcus' definition of iteration vs > recursion) to you without teaching you several key computer science > concepts which are not necessarily difficult but are very *specific*. > > The first step would be to answer your question of days ago about what a > "System" is. Physicists define System the same way Biologists (or even > Social Scientists) do, just using different components and processes. It > involves the relationship between the "thing" itself (a subset of the > universe) and a model that represents it. > > Therein lies two lossy compressions: 1) Reductionism is at best a > convenient approximation... no subset or subsystem is completely isolated > (unless perhaps somehow what is inside a black hole is isolated from what > is outside, but that might be an uninteresting, degenerate case?); 2) The > model is not the thing... we've been all over this, right? Another lossy > compression/projection of reality. oh and a *third*; 3) We can only measure > these quantities to some degree of precision. > > In a system, a simultaneous measure every quantity of every aspect of the > system is it's "state". In practice, we can only measure some of the > quantities to some precision of some of the aspects, and in fact, that is > pretty much what modeling is about... choosing that subset according to > various limited qualities such as what we *can* measure and with what > level of precision and with a goal in mind of answering specific questions > with said model. > > At this point, we are confronted with "what means State?" > > Your preference for "Analytical Output" vs "State" I think reflects your > attempt to think in terms of the implementation of a model (in a computer > program, or human executed logic/algorithm). The problems with "Analytical > Output" in this context arise from both "Analytical" and "Output". > "Analytical" implies that the only or main value of the "state" is to do > analysis on it. In Marcus example, it's main use is to feed it right back > into an iterated model... no human may ever look at this "state". "Output" > suggests (also) that the state is visible *outside* the system. While > (for analytical purposes) we might choose to capture a snapshot of the > state, it is not an "output", it is just the STATE of the system (see > above). > > Marcus point was that in a recursive *program* (roughly a deterministic > implementation rooted in formal symbol processing, of a model of some > "system"), the "system" is nominally subdivided into physical or logical > subsets or "subsystems" and executed *recursively* (to wit, by subdividing > again until an answer can be obtained without further subdivision). In an > iterative *program*, the entire (sub) system model is executed with initial > conditions (state) one time, then the resulting state of that iteration is > used as the initial conditions for the *next* iteration until some > convergence criteria (the state of the system ceases to change above some > epsilon) is met. > > I hope this helps... and doesn't muddy the water yet more? > > - Steve**** > > I don't know, I don't speak Haskell. **** > > **** > > --Doug**** > > On Sat, Apr 13, 2013 at 3:29 PM, Nicholas Thompson < > nickthomp...@earthlink.net> wrote:**** > > Could be!**** > > **** > > Ok. Now that that is behind us, what did the message mean? **** > > **** > > N**** > > **** > > *From:* Friam [mailto:friam-boun...@redfish.com] *On Behalf Of *Douglas > Roberts > *Sent:* Saturday, April 13, 2013 3:02 PM**** > > > *To:* The Friday Morning Applied Complexity Coffee Group**** > > *Subject:* Re: [FRIAM] Tautologies and other forms of circular reasoning.* > *** > > **** > > Nick,**** > > **** > > I surprised that you are not more conversant in computer languages. > You're always, well, niggling about the meaning of this word, or that one > in the context of this or that conversation.**** > > **** > > With computer languages, there are very few ambiguities, contextual or > other wise. Kind of like mathematics. For one as worried as you often > appear to be about the true meaning of the written word, I would have > thought that you would positively revel at the ability to express yourself > with nearly absolute crystal clarity, no ambiguities whatsoever.**** > > **** > > Could it be that you seek out the ambiguities that are ever present in > human languages to give yourself something to pounce upon and worry over, > and to provide the opportunity to engage in nearly endless conversations?* > *** > > **** > > --Doug**** > > On Sat, Apr 13, 2013 at 2:05 PM, Nicholas Thompson < > nickthomp...@earthlink.net> wrote:**** > > Can anybody translate this for a non programmer person? > > N**** > > > -----Original Message----- > From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Marcus G. > Daniels > Sent: Saturday, April 13, 2013 1:10 PM > To: friam@redfish.com > Subject: Re: [FRIAM] Tautologies and other forms of circular reasoning.*** > * > > On 4/12/13 5:40 PM, glen wrote: > > Iteration is most aligned with stateful repetition. Recursion is most > > aligned with stateless repetition. > Purely functional constructs can capture iteration, though. > > $ cat foo.hs > import Control.Monad.State > import Control.Monad.Loops > > inc :: State Int Bool > inc = do i <- get > put (i + 1) > return (i < 10) > > main = do > putStrLn (show (runState (whileM inc get) 5)) $ ghc --make foo.hs $ > ./foo > ([6,7,8,9,10],11) > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe > http://redfish.com/mailman/listinfo/friam_redfish.com > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com**** > > > > **** > > **** > > -- **** > > *Doug Roberts > d...@parrot-farm.net***** > > *http://parrot-farm.net/Second-Cousins*<http://parrot-farm.net/Second-Cousins> > **** > > * > 505-455-7333 - Office > 505-672-8213 - Mobile***** > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com**** > > > > **** > > **** > > -- **** > > *Doug Roberts > d...@parrot-farm.net* **** > > *http://parrot-farm.net/Second-Cousins*<http://parrot-farm.net/Second-Cousins> > **** > > * > 505-455-7333 - Office > 505-672-8213 - Mobile***** > > > > **** > > ============================================================**** > > FRIAM Applied Complexity Group listserv**** > > Meets Fridays 9a-11:30 at cafe at St. John's College**** > > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com**** > > **** > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com**** > > ** ** >
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
