Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
Daniel Vainsencher
Thanks for the reply!
If I understand correctly, that would not support the workflow I imagine:
  1. Implement an algorithm as an auto combining different auto's.
  1. Run it on some initial state, saving (some or all) states
  1. 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.
Justin Le
@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
Daniel Vainsencher
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.
Daniel Vainsencher
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.
Justin Le
@daniel-vainsencher i'll let you know when i have some sort of proof of concept up :)
Daniel Vainsencher
@mstksg Great, I'd love to play with it :)
Kosyrev Serge
@mstksg, ertes was writing a successor to netwire, do you know anything about that? is it somehow related to auto?
Michael Fox
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?
Nicolas Rolland
It would be very useful in a web workflow to provide a way to have on the fly generated URLs representing the state at various locations. in the spirit of https://pages.lip6.fr/Christian.Queinnec/PDF/www.pdf
have you thought already about such a feature ?
Justin Le
@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 :)
Njagi Mwaniki
Hello @mstksg what do you think about using do notation like this instead http://lpaste.net/4199862654048665600
Is there a reason we are using proc notation because it makes it harder, at least for me, to understand what is going on.
instead of e.g do
Justin Le
@urbanslug in your 'do' example, you're actually sort of unpacking and recreating the arrow every time you combine it
it's sort of...defeating the whole purpose of the arrow/auto abstraction
if you're familiar with 'State', it's like using State, but instead of using fmap/>>=, you manually runState/State every time you want to make a new action
the point of the auto/arrow abstraction is that you can compose them as first-class items
but here, you're breaking them down and recreating them from scratch, outside of the abstraction
if that makes sense
Justin Le
the reason we use proc/do notation is that it lets us view composition of Auto's like a graph
here is an elaboration of my State example, btw
Njagi Mwaniki
OK I just saw this reply. Let me read it and understand it.
Ha Ok wasn't a complicated an example as I expected
Makes sense :smile:
Justin Le
mhm, the whole point of the Auto type is so you don't have to manually unwrap and re-wrap