Liste des Groupes | Revenir à c theory |
On 7/20/24 9:54 PM, olcott wrote:There is never any representing involved when a simulatorOn 7/20/2024 8:51 PM, Richard Damon wrote:In other words, you have just been lying for years about doing the Halting problem, whose input is the reperesentation of the program to be decided.On 7/20/24 9:35 PM, olcott wrote:>On 7/20/2024 8:01 PM, Richard Damon wrote:>On 7/20/24 8:21 PM, olcott wrote:>On 7/20/2024 7:05 PM, Richard Damon wrote:>On 7/20/24 7:06 PM, olcott wrote:>On 7/20/2024 6:00 PM, Richard Damon wrote:>On 7/20/24 6:47 PM, olcott wrote:>On 7/20/2024 5:11 PM, Richard Damon wrote:>On 7/20/24 5:21 PM, olcott wrote:>On 7/20/2024 4:06 PM, joes wrote:>Am Sat, 20 Jul 2024 15:05:53 -0500 schrieb olcott:>On 7/20/2024 2:50 PM, Richard Damon wrote:>On 7/20/24 3:09 PM, olcott wrote:On 7/20/2024 2:00 PM, Fred. Zwarts wrote:Op 20.jul.2024 om 17:28 schreef olcott:You missed a couple details:(a) Termination Analyzers / Partial Halt Deciders must halt this is
a design requirement.
(b) Every simulating termination analyzer HHH either aborts the
simulation of its input or not.
(c) Within the hypothetical case where HHH does not abort the
simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.
This violates the design requirement of (a) therefore HHH must abort
the simulation of its input.
A terminating input shouldn't be aborted, or at least not classified
as not terminating. Terminating inputs needn't be aborted; they and the
simulator halt on their own.
>Pretty much.And when it aborts, the simulation is incorrect. When HHH aborts andSo you are trying to get away with saying that no HHH ever needs to
halts, it is not needed to abort its simulation, because it will halt
of its own.
abort the simulation of its input and HHH will stop running?I thought they all halt after a finite number of steps?It is the fact that HHH DOES abort its simulation that makes it notNo stupid it is not a fact that every HHH that can possibly exist aborts
need to.
its simulation.
>
void DDD()
{
HHH(DDD);
return;
}
>
DDD correctly simulated by pure function HHH cannot
possibly reach its own return instruction.
>
Wrong.
>
You know that you are lying about this as you admit below:
Nope, YOU just don't what the words mean, and reckless disregard the teaching you have been getting, which makes your errors not just honest mistakes but reckless pathological lies.
>>>It may be that the simulation by HHH never reaches that point,>but if HHH aborts its simuliaton and returns (as required for it to be a decider) then the behavior of DDD>
Simulated by HHH is to Die, stop running, no longer function.
Nope, HHH is NOT the "Machine" that determines what the code does, so can not "Kill" it.
>
So you are trying to get away with the lie
that an aborted simulation keeps on running.
>
No, but the BEHAVIOR of the program does, and that is what matters.
So you agree that DDD correctly simulated by any pure function
HHH cannot possibly reach its own return instruction?
>
>
No, I will let you claim (without proof, so we can argue tha later) that the simulation by HHH of DDD does not reach the return, but the behavior of the DDD simuliated by HHH continues, to the return if HHH aborts its simulation and returns, as the behavior of ALL copies of DDD do not "stop" just because some simulator gave up looking at it.
>
In other words you never understood that the input to an x86
emulator is a static finite string of bytes that does not do
anything at all on its own?
>
But it represents a program that does,
There is no representing to it.
It is static data within the x86 emulator process.
>
No program to be decided on, no program to be emulated.
It mean you are just admitting that all you are doing is talking about your POOP.--
Throw away to problems actual definition and all you work that you claim to be ablut it become nothing but LIES.
You can't even connect that string of bytes to you description of it being "DDD" without a concept of representation, as the bytes do not have names on them.
Les messages affichés proviennent d'usenet.