Indeed. Put a hyperbolic time chamber inside another hyperbolic time chamber, and you get a speedup factor of 365 squared.
I think the characters in Primer may have done something like this, getting around a limitation of their time machine by putting a second time machine inside of the first. Then again, the movie isn’t always clear as to what’s happening, so it’s hard to tell...
Yeah, it would be interesting, but it’s not doable in either the original DBZ scenario, or in upload scenarios: you can’t emulate an emulator and get a speedup like that—the buckpassing doesn’t work, the computations still have to be done somewhere.
(Any optimization you could apply to emulating an emulation, like some sort of Futamura projection collapsing the emulated program and the emulated hardware, could be done at the original emulation level, so all it leaves you with is possible programming convenience and constant factors of inefficiency and indirection.)
You can have an arbitrarily deep sequence of speeding-up optimized nested emulations, with each subsequent emulation running faster by its container’s clock than the otherwise identical container would run by itself (by its own clock).
(The catch is that n obk gung’f ehaavat na rzhyngvba znl or fybjre ol vgf pbagnvare’f pybpx guna vs vg vfa’g.)
Indeed. Put a hyperbolic time chamber inside another hyperbolic time chamber, and you get a speedup factor of 365 squared.
I think the characters in Primer may have done something like this, getting around a limitation of their time machine by putting a second time machine inside of the first. Then again, the movie isn’t always clear as to what’s happening, so it’s hard to tell...
Yeah, it would be interesting, but it’s not doable in either the original DBZ scenario, or in upload scenarios: you can’t emulate an emulator and get a speedup like that—the buckpassing doesn’t work, the computations still have to be done somewhere.
(Any optimization you could apply to emulating an emulation, like some sort of Futamura projection collapsing the emulated program and the emulated hardware, could be done at the original emulation level, so all it leaves you with is possible programming convenience and constant factors of inefficiency and indirection.)
You can have an arbitrarily deep sequence of speeding-up optimized nested emulations, with each subsequent emulation running faster by its container’s clock than the otherwise identical container would run by itself (by its own clock).
(The catch is that n obk gung’f ehaavat na rzhyngvba znl or fybjre ol vgf pbagnvare’f pybpx guna vs vg vfa’g.)