3 ms·

Surprisingly there is prior work on this! https://www.scottaaronson.com/papers/ctchalt.pdf https://www.scottaaronson.com/papers/ctchalt.pdf . Apparently a Turin

Surprisingly there is prior work on this! https://www.scottaaronson.com/papers/ctchalt.pdf https://www.scottaaronson.com/papers/ctchalt.pdf . Apparently a Turing Machine with time travel can solve the halting problem

fragmede 2y ago
With time travel, isn't the halting problem trivially solvable? You start the program, and then just jump to after the end of forever and see if the program terminated.
- PittleyDunkin 2y ago
  Surely we already have this: the jump just takes forever.
- HeliumHydride 2y ago
  I think you can only time travel a finite time.
  - MadnessASAP 2y ago
    That's why you instead specify that if & when the program halts it travels back in time to let you know it has. Thus you would know immediately after starting the computation if it's going to halt, how long it'll take, and what the result is. Of course you should still carry out the computation to prevent a paradox.
- JadeNB 2y ago
  > With time travel, isn't the halting problem trivially solvable? You start the program, and then just jump to after the end of forever and see if the program terminated. Some programs won't halt even after forever, in the sense of an infinite number of time stops. For example, if you want to test properties of (possibly infinite) sets of natural numbers, there's no search strategy that will go through them even in infinite time. (Footnote that I'm assuming, I think reasonably but who knows what CSists have been up to?, a model of computation that allows the performance of countably, but not uncountably, many steps.)
  - eddd-ddde 2y ago
    But if you are at the present, and dont receive a future result immediately, can't you assume it never halts? Otherwise you would have received a result.
    - mgsouth 2y ago
      I don't think so. That's assuming the program will always be in a frame of reference which is temporally unbounded. If, for example, it fell into a black hole it would, IIUC, never progress (even locally) beyond the moment of intercepting the event horizon.
      - eddd-ddde 2y ago
        Hmmm, couldn't you, as long as there's a fixed period of time that supports time travel, keep execution working by travelling to the start of the period again and again (/with/ the current program state) to avoid the program from going beyond the working time period?
        mgsouth 2y ago
        Ooh, clever. Vaguely envision entropy problems, that some mash-up of Godel's Incompleteness theorem, Maxwell's Demon, and Bell's Inequality, and Newton's laws conspires against it. Maybe sending changes back add entropy, or moves it around? Would make a good old-school SF story, with backwater multi-verse dumps for waste entropy, a free-lance troubleshooter uncovering a secret corporate scandal regarding deleterious effects, etc.
  - pino999 2y ago
    It goes like this: We have two observers with a computer. A is outside a black hole. B goes over the event horizon. B is infinitely time dilated seen from A. It takes forever for B to reach the singularity from A standpoint. B reaches the middle in a finite time. A starts computation. If it halts A sends a result, otherwise it won't. B sees the result in a finite time. If it doesn't, the program didn't halt. If time is discrete, it won't fly I think. This works because there is no smallest time unit in gr. We are working with different types of infinities. A's computational steps take, the further B goes in, less time. Sort of Zeno's paradox. It is easy to map all natural numbers between 0 and 1 on the real line. Just not 1 to 1. There are more problems. How to get the information out and how to survive the divergent blue shift, it is somewhat unclear. B cannot talk back. But still a cool find.

fragmede 2y ago

With time travel, isn't the halting problem trivially solvable? You start the program, and then just jump to after the end of forever and see if the program terminated.

PittleyDunkin 2y ago
Surely we already have this: the jump just takes forever.
HeliumHydride 2y ago
I think you can only time travel a finite time.
- MadnessASAP 2y ago
  That's why you instead specify that if & when the program halts it travels back in time to let you know it has. Thus you would know immediately after starting the computation if it's going to halt, how long it'll take, and what the result is. Of course you should still carry out the computation to prevent a paradox.
JadeNB 2y ago
> With time travel, isn't the halting problem trivially solvable? You start the program, and then just jump to after the end of forever and see if the program terminated. Some programs won't halt even after forever, in the sense of an infinite number of time stops. For example, if you want to test properties of (possibly infinite) sets of natural numbers, there's no search strategy that will go through them even in infinite time. (Footnote that I'm assuming, I think reasonably but who knows what CSists have been up to?, a model of computation that allows the performance of countably, but not uncountably, many steps.)
- eddd-ddde 2y ago
  But if you are at the present, and dont receive a future result immediately, can't you assume it never halts? Otherwise you would have received a result.
  - mgsouth 2y ago
    I don't think so. That's assuming the program will always be in a frame of reference which is temporally unbounded. If, for example, it fell into a black hole it would, IIUC, never progress (even locally) beyond the moment of intercepting the event horizon.
    - eddd-ddde 2y ago
      Hmmm, couldn't you, as long as there's a fixed period of time that supports time travel, keep execution working by travelling to the start of the period again and again (/with/ the current program state) to avoid the program from going beyond the working time period?
      - mgsouth 2y ago
        Ooh, clever. Vaguely envision entropy problems, that some mash-up of Godel's Incompleteness theorem, Maxwell's Demon, and Bell's Inequality, and Newton's laws conspires against it. Maybe sending changes back add entropy, or moves it around? Would make a good old-school SF story, with backwater multi-verse dumps for waste entropy, a free-lance troubleshooter uncovering a secret corporate scandal regarding deleterious effects, etc.
- pino999 2y ago
  It goes like this: We have two observers with a computer. A is outside a black hole. B goes over the event horizon. B is infinitely time dilated seen from A. It takes forever for B to reach the singularity from A standpoint. B reaches the middle in a finite time. A starts computation. If it halts A sends a result, otherwise it won't. B sees the result in a finite time. If it doesn't, the program didn't halt. If time is discrete, it won't fly I think. This works because there is no smallest time unit in gr. We are working with different types of infinities. A's computational steps take, the further B goes in, less time. Sort of Zeno's paradox. It is easy to map all natural numbers between 0 and 1 on the real line. Just not 1 to 1. There are more problems. How to get the information out and how to survive the divergent blue shift, it is somewhat unclear. B cannot talk back. But still a cool find.