I hope auto can provide a nice environment for exploring different variants of optimization algorithms. It can already serialize state and rerun from a certain point, which should be quite nice, after we find a nice way to manage the memory footprint.
Can we somehow read the serialized state and do stuff with it beyond "play"? for example, compute an arbitrary function (that is not part of the Auto) of the state that IS part of the Auto? or must Auto's be opaque?
hi @daniel-vainsencher :) not sure why, but I missed the notification from gitter about this message
right now the state of an Auto is opaque; it's sort of just added on as a binary blob
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 :)