Talk:Your Pong May Minsky

From Esolang
Jump to navigation Jump to search

Continuous waterfalls

I've had my own ideas about a purely continuous version of The Waterfall Model. One of them was a construction where instead of having continuous decreases of waterclocks, each waterclock instead had a velocity, and a zeroing of a waterclock changed the velocity of every waterclock to set values (with the velocity of the zeroed waterclock becoming positive, obviously).

That is, of course, very similar to a subset of Your Pong May Minsky (the only thing preventing it translating directly is that YPMM adds a set amount to each waterclock's velocity, whereas my version sets each waterclock's velocity). The subset in question has axis-aligned walls (i.e. each wall is a half-hyperspace through the origin such that all but one of the dimension's axes runs along the half-hyperspace) and no wall queues, making it rather simpler.

However, I wasn't 100% sure that this construction was Turing-complete (but it seemed very likely). However, while writing this, I just came up with an easy way to show it: add two extra dimensions/waterclocks which have initial value ½, one with velocity 1, one with velocity -1. If either zeroes, it resets the velocity of every other waterclock/dimension to -1 and its own to +1. This means that at every time of the form n+½ for integer n, all the velocities of the "main" part of the program get reset. Then the remaining dimensions/waterclocks set the velocities to twice the desired adjustment minus ½. That lets you directly implement The Waterfall Model. (Note that you also have to double all the values used in the rest of the simulation so that you know what velocity to set the two resetter dimensions/waterclocks to when one of the other dimensions/waterclocks zeroes.)

It's not clear whether you can make this work with added rather than set velocities (it's likely that you can, but I can't think of a way offhand). There's something of a chicken-and-egg problem in trying to reset the resetters. --ais523 12:31, 17 June 2018 (UTC)

I don't think it was a conscious decision at the time, but in hindsight I think having walls add (rather than set) was to make it more like physics, i.e. reversible. I can no longer quite wrap my head around this, but the fact that wall queues are not needed once reversibility is dropped is somehow not surprising. Keeping reversibility and dropping wall queues but retaining TC would surprise and/or impress me. --Chris Pressey (talk) 16:50, 17 December 2018 (UTC)