I wanted to see if "playable simulations" would be possible in Apparatus using a "followed by" feature inspired by Lucid streams.

It's more like the update step in a game loop (as you say) than Lucid streams -- the variables you are manipulating are all scalars (not real streams with history), so you can't do the stream-shifting-and-combining things that Lucid does.

A disadvantage of the "update" model is that it's first-order -- you can only access the values of variables from the immediately previous iteration.   Most dynamic systems are second-order or higher (e.g. a spring model or a digital filter), and you would have to maintain the history by hand.  (It also has the whiff of mutating variables, assigning a "new value" to temp based on the "current value" of temp.)

I like the standard notation of difference equations.

temp[n] = 0.98 * temp[n-1] + 0.04 * flame

This makes it clear that temp is a function of time, and it's easy to reach back further into history:

temp[n] = 0.98 * temp[n-1] + 0.04 * temp[n-2]

(Shorthand, this is written as:

temp = 0.98 * temp' + 0.04 * temp''

where it's less clear that temp is a state variable unless you already know it.  You can probably come up with a more graphical notation that's appropriate for tokens.)

I use the explicit notation in the "Interacting with behavior" part of unthinkable.  The example starts with the magic circle oscillator:

a[n] = a[n-1] – k * b[n-1]

b[n] = b[n-1] + k * a[n]

which would be clumsy to write with "fby" (because of the a[n] on the rhs of the second line, you'd have to "unroll" that, which would further obscure the beautiful topology)

Anyway, I also like the difference-equation model because there's a large amount of mathematical theory behind it (DSP), which isn't the case for imperative-style updating.

(By the way, if anyone wants to look at the Lucid book:

Wadge - Lucid, the Dataflow Programming Language.pdf

It's nice!)

On Dec 1, 2015, at 5:11 PM, Toby Schachman <> wrote:

[I am sending this again because the big attachment might've failed.]

Today I played with doing simulations in Apparatus. I specifically want to make Apparatus more "playable". What I mean is: many of the good explorable explanations start out with a "you try to do this" lead-in.

You try to make all the polygons happy...

You try to make precipitation decrease...

You try to color the map with 3 colors...

etc.

These work well because you get to "play algorithm" (as in Papert's "playing turtle"), so when the algorithm is explained all the motivations fit into place.

I wanted to see if "playable simulations" would be possible in Apparatus using a "followed by" feature inspired by Lucid streams.

The idea is you write an expression for what a variable should become on the next frame. That expression is allowed to reference the variable's current value (and any other variables of course).

<image.png>

I made a few clips of playing with this. Sorry for the sloppy graphic design and implementation. I just wanted to quickly see if the idea would work.

https://dl.dropboxusercontent.com/u/1802603/misc/apparatus%20simulation.mp4

The first clip is a simulation where you're heating up a thing and there's a bar on the right that shows the current temperature. This is the lead-in for an explorable explanation I'd like to do about PID control systems ("You try to get it to the target temperature").

The second clip is a ball that follows another ball (first demo from Dead Fish).

The third clip is the heating simulation where we manually keep a history of the thing's temperature and plot it. The implementation for this is with an array that we update on every frame. But, that is just a stand in because I think Apparatus should have a feature where you can just grab the history of any variable. Right now you can grab the current value of a variable for use in an expression. But you should also be able to grab the history (as a spread) of a variable. "Give me the last 100 values of this variable", "Give me the last 15 seconds of this variable", etc. This feature would also let you easily do "traces", or even make a drawing program (give me the entire history of the x and y positions of the pen object and use it to draw a path).

The "followed by" thing is similar to the update step in a game loop. I think the main difference is that it privileges data flow over control flow. In a traditional game loop, you have a block of code that updates lots of variables on every tick. With "followed by", each update rule lives with its variable (lives with the data). I'm not sure whether this will make programming the behaviors better or not. Maybe there will be both a data-centric mechanism ("this variable evolves according to this expression") and a control-centric mechanism ("when you click this rectangle set this other variable to 0"). We'll see.

Right now you can turn on and off the followed by rules individually with a checkbox. There will need to be a better designed interface for this, perhaps with a universal pause button and scrubber to go back in time.

For those following on Github, there is an experiment-evolve branch. It is hacky, inefficient, and breaks things like reusing symbols. But it works for testing the idea. The examples from the clips are attached.

--
The Dynamic Medium
Bret, Chaim, Dave, Glen, Goetz, Matthias, May-Li, Nagle, Paula, RMO, and Toby
<evolve - temp history.json><evolve - temp.json><evolve - follow ball.json>