Merge pull request #15 from TakSuyu/ghc-7.6 (0c0df708678764a894ba72115560237c81ae66c6 by Justin Le)
the ordering of the components of the state depend on the compositional structure of the auto
as soon as you absorb a state the auto then it becomes sort of locked away
however, you can write your Auto's using a state monad and that sort of lets you manipulate a first-class state before you absorb it into an Auto
Hi @mstksg, I didn't get a notification either
Thanks for the reply!
If I understand correctly, that would not support the workflow I imagine:
Implement an algorithm as an auto combining different auto's.
Run it on some initial state, saving (some or all) states
Decide that I want to plot some function of the state, and compute that based on the saved (and possibly interpolated) states
(ach, should have numbered with #)
Because IIUC, the serialized state cannot be turned back into the state monad, right?
This seems like a pretty useful thing to have in many contexts, including for debugging UIs etc.
@daniel-vainsencher at the moment, it's not quite easy to do
but that's the first time i've heard a really convincing workflow convincing me about concrete benefits to gain
actually, i think I can think of a way to implement some form of that to be able to do that in a meaningful way :)
i'll think about it, but i see a direct benefit and a direct use case now
One way to think about it is that the "components are completely encapsulated, composable only through their inputs and outputs" is a very useful way to compose, but not the only one. A completely different one is "DAG of X can read any part of Y, but not vice versa". And these can be useful together. For example:
Suppose we have an "interactive plotting auto", which gets a stream of values, and shows a plot which changes over time (all values so far, or the last 100, or a summary, whatever).
And also some random autos (game UI, stochastic optimization, etc).
Then the natural way to adapt these two kinds of components without designing either one to work with the other is an auto which reads arbitrary fields of the process, and outputs a stream of numbers, which the plotter is designed to process.
My interest in autos, btw, comes out of banging my head against this difficulty for a long time, and I haven't seen a good solution in any language yet: how to write iterative numerical algorithms cleanly and efficiently (ideally, nothing but the recursive relations), and yet retain the ability to compose with functionality that is critical like: sampling, saving, stopping conditions (maybe but not always based on the natural output), visualization (plotting, printing to output, often not of the natural output), exploration ("what happened right before the first time we got a NaN in this field").
Autos already deal with saving quite nicely; the ability to restart is not obvious. Being able to compose based on inputs/output is also tantalizing. But the ability to also look in, in a read only manner, would be totally awesome.
@daniel-vainsencher i'll let you know when i have some sort of proof of concept up :)
@mstksg Great, I'd love to play with it :)
@mstksg, ertes was writing a successor to netwire, do you know anything about that? is it somehow related to auto?
Hi. Question: How could you put more events out than events in? For example, input = [1,2,3]; output=[1,1,2,2,3,3]. Is it possible?
@deepfire The two are actually implemented in similar ways (netwire/auto/wires), but their domain and API/semantics are very different :) wires/netwire focuses on continuous time semantics, and auto has discrete-time semantics
@gitfoxi hi michael! it's not directly possible, but you can output lists and concat their results, or use "time slowing" autos to turn [1,2,3] into [Blip 1, NoBlip, Blip 2, NoBlip, Blip 3], etc. :)
@nrolland that's pretty interesting. it's very similar to other things i've been working on, actually! thanks for another paper to check out, though :)