I’m having a hard time with state being time. Time being state seems clear to me. But while you have a “before” and “after” with one call to f(x), if you have a loop like while (true) { x = 1; print(x); f(x); print(x); } there are many before and after f(x). To go from
the time to the state for a program like this you need some kind of frequency / clock speed right? It’s not the same thing as the clock being sampled within a second (or every 12 hours), because the history is on the print out and you can you see how many loop iterations there were, but you don’t know how long it took based just on the state, even though you have the whole of the state.
Think time like vector clocks, not like wall time. It’s a bit idiosyncratic, to be sure! But with the while loop, you’d get a timeline like this:
x = 1
x = 3
x = 1
x = 3
x = 1
...
So each iteration of the while loop leads to two new observable states, advancing time by two epochs, even if each state transition happens almost instantaneously. But you’re right, you certainly couldn’t read a wall time just by looking at the printout.
Thanks. I think am still struggling here. I think maybe there might be something like history (an ordered record of events?) being different than time, and vector clocks seem more related to history than time to me.
On the other hand, what is (solar) time other than the ordered list (history) of the sun’s position in the sky?
But if I go into a cave with a clock I can wait for it to reach a certain time and come back out and expect the sun to be in a particular position, even though the clock doesn’t operate like a sun dial.
But the state (position) of the sun can tell me the state of the clock. So I guess state is time after all?
“Time” as used by the article, especially in the latter section, is something more abstract than “time” in the concrete common sense.
Do you know how parametric equations can be used to generate shapes? For example, the set of parametric equations {x = cos(t), y = sin(t)} generates a circle as the parameter t increases continuously from zero degrees to 360 degrees (or zero radians to 2π radians). That parameter t can be considered as an abstract “time”, and is sometimes called thus (e.g., in the documentation of the Asymptote graphics language), even though “time” in this case is measured in units of angle rather than units of “time” in the common sense.
That parameter t can be considered as an abstract “time”, and is sometimes called thus
This example is in the sense of “time is state” that I am fine with. Whether it’s an abstract parameter or a “real” clock or the advance of the program counter it’s clear to me that time is part of the state.
It’s the other way, “state is time”, that is a problem for me. There are multiple ts for a given x. Given x you can’t tell me which t it is even knowing the function is x = cos(t).
0 is “before” 2pi, but like looking at a clock twice within the same second or 12hrs apart the state (x) isn’t sufficient to discover the time (t).
I think the argument here is 0 isn’t actually before 2pi, 0 and 2pi are the same times, in a similar way to looking at the clock in the same second is the same time.
But if you start printing t and cos(t), t isn’t the time, now the time is the number of steps through the loop as measured by the number of printed lines.
“Time” as used by the article, especially in the latter section
Maybe that’s it, “time is state” and “state is time” is referring to two different senses of time, even when talking about the same process.
t is state
state is observed transitions in the output
But if you have a display that shows the current value of t and x rather than a log your experience of the time of the program is going to be mediated by how often you look just like with the clock.
I’m having a hard time with state being time. Time being state seems clear to me. But while you have a “before” and “after” with one call to
f(x), if you have a loop likewhile (true) { x = 1; print(x); f(x); print(x); }there are many before and afterf(x). To go from the time to the state for a program like this you need some kind of frequency / clock speed right? It’s not the same thing as the clock being sampled within a second (or every 12 hours), because the history is on the print out and you can you see how many loop iterations there were, but you don’t know how long it took based just on the state, even though you have the whole of the state.Think time like vector clocks, not like wall time. It’s a bit idiosyncratic, to be sure! But with the while loop, you’d get a timeline like this:
So each iteration of the while loop leads to two new observable states, advancing time by two epochs, even if each state transition happens almost instantaneously. But you’re right, you certainly couldn’t read a wall time just by looking at the printout.
Thanks. I think am still struggling here. I think maybe there might be something like history (an ordered record of events?) being different than time, and vector clocks seem more related to history than time to me.
On the other hand, what is (solar) time other than the ordered list (history) of the sun’s position in the sky?
But if I go into a cave with a clock I can wait for it to reach a certain time and come back out and expect the sun to be in a particular position, even though the clock doesn’t operate like a sun dial.
But the state (position) of the sun can tell me the state of the clock. So I guess state is time after all?
“Time” as used by the article, especially in the latter section, is something more abstract than “time” in the concrete common sense.
Do you know how parametric equations can be used to generate shapes? For example, the set of parametric equations
{x = cos(t), y = sin(t)}generates a circle as the parametertincreases continuously from zero degrees to 360 degrees (or zero radians to 2π radians). That parametertcan be considered as an abstract “time”, and is sometimes called thus (e.g., in the documentation of the Asymptote graphics language), even though “time” in this case is measured in units of angle rather than units of “time” in the common sense.This example is in the sense of “time is state” that I am fine with. Whether it’s an abstract parameter or a “real” clock or the advance of the program counter it’s clear to me that time is part of the state.
It’s the other way, “state is time”, that is a problem for me. There are multiple ts for a given x. Given x you can’t tell me which t it is even knowing the function is x = cos(t).
0 is “before” 2pi, but like looking at a clock twice within the same second or 12hrs apart the state (x) isn’t sufficient to discover the time (t).
I think the argument here is 0 isn’t actually before 2pi, 0 and 2pi are the same times, in a similar way to looking at the clock in the same second is the same time.
But if you start printing t and cos(t), t isn’t the time, now the time is the number of steps through the loop as measured by the number of printed lines.
Maybe that’s it, “time is state” and “state is time” is referring to two different senses of time, even when talking about the same process.
t is state
state is observed transitions in the output
But if you have a display that shows the current value of t and x rather than a log your experience of the time of the program is going to be mediated by how often you look just like with the clock.