Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification of Continuous Time #155

Open
dakom opened this issue May 28, 2018 · 6 comments
Open

Clarification of Continuous Time #155

dakom opened this issue May 28, 2018 · 6 comments

Comments

@dakom
Copy link

dakom commented May 28, 2018

I was chatting with @paldepind, who's also developing a Typescript FRP framework (https://github.com/funkia/hareactive) and he had some questions about the Semantics

I hope I get this right (if not feel free to correct), but I believe his concern was that a Cell does not allow continuous time since C a = (a, [(T, a)]) is discrete.

Might be helpful for everyone researching this space to have some clarification of this - how do we see from the semantics that a Cell is indeed continuous?

@the-real-blackh
Copy link

the-real-blackh commented May 29, 2018

The cell for current time (called sys.time) is C T = (T0, [(T, T)]) where T is an element of the infinite set [T0...]. Its value is continuous in that for any T >= T0, it has a value T. The continuousness is simulated on a discrete machine by means of making it so you can sample it at any time and get a value. It's akin to describing something using vector graphics. In order to actually see the image, it has to be rasterized, and that's how a finite machine can simulate an infinite variance over space. We do the same thing, except with time instead of space.

Using map, lift and snapshot, you can easily construct a new cell that is a function of time and it will have the same conceptual continuousness.

To make it a true behavior in the FRP sense, Operational.updates() and Operational.value() have to be illegal.

@jam40jeff
Copy link
Contributor

The C# 2.0 implementation (which I believe has been ported to some other languages now) has both the Behavior and Cell types. Behavior can be continuous as it does not have the Updates or Values methods. Cell is by definition a discrete Behavior.

@dakom
Copy link
Author

dakom commented May 29, 2018

Thanks!

@the-real-blackh - it seems to me that your point about C T is made in the doc itself, is that right? e.g.

We can derive Conal's B a from C a with an at function...

I'm also wondering if the implementation choice of splitting Behavior and Cell should be mentioned in the semantics itself? E.g. there's more than only Cell, and Stream- there's also Behavior?

@the-real-blackh
Copy link

Yes, it should be mentioned in the semantics. I'll do it all when I can find the time.

@paldepind
Copy link

paldepind commented May 29, 2018

@the-real-blackh

Its value is continuous in that for any T >= T0, it has a value T.

That is not what I understand as being continuous. From Wikipedia:

In mathematics, a continuous function is a function for which sufficiently small changes in the input result in arbitrarily small changes in the output.

In other words, a continuous function changes infinitely often. Consider the following two functions.

Both of these have a value for any T, but only the function on the right is continuous.

To make it a true behavior in the FRP sense, Operational.updates() and Operational.value() have to be illegal.

Not necessarily. Hareactive supports updates (with the name changes) on its behaviors even though they can be continuous. The only caveat is that calling changes on a behavior that changes infinitely often will give a run-time error.

@the-real-blackh
Copy link

Both of these have a value for any T, but only the function on the right is continuous.

As my teenage daughter would say, OH MY GOD!!!! You're right. I didn't state my assumption that T was continuous.

Hareactive supports updates (with the name changes) on its behaviors even though they can be continuous.

That's possibly reasonable, although isn't one of the reasons for having a Behaviour type so that these things come up as compile-time errors?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants