@alderwick @d6 @astrid but then that wouldn't be reversible.. you can't decrement 4/3 and get back 2/1..

@alderwick @astrid i don't know why incrementing 2/1 results in 3/1 (except that incrementing 2 results in 3).

@alderwick @astrid if increment means "adding 1" then incrementing 2/3 gives 1+2/3 (i.e. 5/3). if it means something else we have to figure out what rules "incrementing" obeys (if any).

@d6 @alderwick @astrid have you ever seen anything about reversible inc/dec in regards to fractions?

@alderwick @astrid the only two things i can think of are:

- add/subtract 1
- for fixed point (or floating point) find next highest or next lowest value

the second one doesn't work for rational numbers in general (you can always find a rational number between any two rational numbers that aren't equal)

@d6 @alderwick @astrid adding a whole seems like the better way to go, you're right.

5/6 INC, would be 11/6

i guess the other thing too is that i don't think there's much use for an increment of the rationals. if someone really wants it for their own application i guess they could just implement it themselves

@astrid @alderwick @d6 people seem to say it's related to the collatz conjecture, which seems to be a central theme to my morning

@astrid @alderwick haha be careful, that problem eats peoples' souls

@astrid @alderwick i don't believe in basilisks but if i did i would be worried about the collatz basilisk not the one roko talked about

@d6 @astrid @alderwick Haha, thank you. I'll take that warning to heart.

@alderwick @wim_v12e the stack effect could be maintained, and still send "olleH" when ran backward

@wim_v12e We could! I was also using it as a tool to illustrate the constant generation of this data as a program runs, the majority of which we throw away. If a subroutine was called every screen refresh to draw some sprites in a loop, even ignoring device data, the loop values that get POPped off the stack are also not of any value *unless they're caught up in bug hunting*.

It's the last bit where I think retaining data and reversibility is most helpful.

@alderwick I think when people discuss reversible computation, I/O is generally not considered as computation. Basically, I/O will generate entropy, there's nothing you can do about that.

No, you are right. It's easy for INC and DEC and so you can generalise to ADD/SUB and MUL/DIV but then you get into the issues with a*0 and a/0 so it gets a bit more tricky.
But where it gets really tricky is when you add control flow. In particular when you consider recursive function application. Basically, it means you need to be able to follow your path back through all jumps.

@wim_v12e yeah, I'm a bit stumped by this right now, I could add "entry point returns" right before a label so when I run the clock backward I can return, but there has to be a better way - do you have a link on this topic I could have a look at?

I don't have a reference, would need to dig deeper myself.

But the way I see it: if it's not recursion, you can inline the function so no problem.
If it is a recursion across multiple functions, you can still inline until it becomes a single function.
If the recursion is a proper tail recursion, then all you need to keep track of is the total number of iterations.
So the only hard case is non-tail recursion, which you don't want in general anyway as it makes the stack explode.

@wim_v12e Ooh, inlining. Clever

@wim_v12e from what I understand, there's no need for garbage collection with time reversible operations?

@wim_v12e the language name sounds like coming from an msx game! 😀 - https://www.file-hunter.com/MSX/index.php?id=theseus

@nitrofurano @wim_v12e I think it's probably from the ship ;)

@nitrofurano It is named after the ship, yes. The analogy is that computation in this language proceeds by replacing values by apparently equal values.