How to define a continuous Cell?

[dakom]

I'm trying to understand some of the nuance of the issues discussed here: https://github.com/SodiumFRP/sodium-typescript/issues/46

Is it possible to define a Cell whose value changes (predictably) when sampled at different times, like make the Cell itself something like a Transaction -> a or Time -> a ?

We can define the value of a Cell to be a function of Time -> a - and I've found that technique to be super awesome, but that function is only changed via discrete events (e.g. the Cell is defined as a hold of Stream, or as a CellSink)

I'm not sure if what I'm asking has any practical relevance - which I guess is why it's not exposed this way in the api... but I'm wondering if Sodium supports this concept somehow?

[dakom]

Also - I was discussing this with someone and wrote the following.... would really like to know if it's right... I keep saying one of these days I'll learn how Sodium is implemented under the hood, but until then I'm sortof just piecing together bits of info from the book and other posts hehe.

---

Whether or not you can define a continuous Cell is different from whether or not Sodium is built on continuous time.

Why does that matter?

Think back to the mouse move example… we have our streams set up like this:

1. sMouseMove - fired whenever the mouse moves, let’s pretend at 300fps
2. sRender - fired on requestAnimationFrame - 60fps

Let’s define Cells which hold those values:

const initialPosition = {x: 0, y: 0};
const cMousePosition = sMouseMove.hold(initialPosition);
const cMouseRender = sRender
                       .snapshot(cMousePosition, identity)
                       .hold(initialPosition); //could also use snapshot1

No matter if we change these to fire at infinite fps, or there are frame tick hiccups, or whatever - everything will be ordered correctly, there’s no tangled mess, and it’s described in a simple declarative composition.

Similarly if they happen to fire at the same exact moment (not possible in JS but is possible elsewhere - and you can force it in JS by wrapping the streamsink sends in a Transaction()) - you are forced to decide what to do with the conflict. There’s no possibility of accidentally missing events due to race conditions.

I believe this is all made possible because the underpinnings of that “declarative graph” are built on the fundamental concept of continuous time. I don’t really know the mechanics of that, and I am curious of the answer [above]… but on a practical day-to-day level, the benefit isn’t so much continuous time as it is more a functional api that lets you compose things with various sampling rates, without getting bitten by the crazy bugs that can happen when trying to DIY. This is made possible by continuous time if I understand correctly.

[dakom]

I don't want to derail from the core question above of how to make a Cell itself vary continuously, but I was thinking more about this:

on a practical day-to-day level, the benefit isn’t so much continuous time as it is more a functional api that lets you compose things with various sampling rates

The classic analogy is to vector vs. bitmap graphics, so I'll give it a shot using that.

The useful thing about vector graphics is not that they can be scaled infinitely without losing information - but rather, that they can be scaled to SD, HD, 2K, 4K, 8K, or whatever you specify at export - without losing information.

In order to support that, the vector format must be capable of scaling to infinite resolution, but that's simply a means to an end.

Internally, the type of a graphic vector is something like Resolution -> Point -> Color. In english "give me a target resolution and a pixel coordinate, and I'll tell you what color it is with perfect precision - no matter how large the resolution"

Similarly, the type of an animation could be represented by a Cell/Behavior which is internally something like Time -> Bone -> Position. In english: "give me a target time and a bone object and I'll tell you its position with perfect precision - no matter how precise the timestamp"

In order to be able to answer a query for any resolution - vector graphics must be defined as continuous functions. In order to be able to answer a query for any timestamp - cells/behaviors must also be defined as continuous functions.

Assuming all that is right - the following is where I'm on shakier ground:

Internally the idea of Transactions (which is Sodium's way of dealing with time) must be mapped over some sort of continuous function...

Is that in the ballpark?

[clinuxrulz]

You have a very difficult question, I'm not sure how to answer it.

My biggest concern with a continuous time model is that the calculus available to us is unable to define an integral for all possible equations, even though such functions should exist, the math toolbox currently available to the human race is lacking. Integrals are required for an exact position over time which you can sample at any rate, its easy with just a few interacting entities, but the moment you add a couple more it becomes too hard to handle.

E.g. write a formula for the movement of 5 planets in orbit as a formula of time with exact positions... insanely hard!... Now write a formula for just 2 planets... easy its basically just cos() and sin() of time.

Generally numerical approximations are good enough to be perceived as real for games. And there is interval analysis available for the numerical methods when a desired accuracy is required.

[clinuxrulz]

I believe your idea is correct, but I could not say how to implement it. My gut says Cell<Time->A>, then snapshot it with Stream<Time> set to the desired frame rate, but I have not tested it.