To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 >>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate
normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, because
there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself, but
the simulation is never able to reach the final state of the simulated
self. The abort is always one cycle too early, so that the simulating
H0 misses the abort. Therefore this results in a false negative.
(Note that H0 should process its input, which includes the H0 that
aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he creates
a H that does not abort, it will not terminate.
*Therefore what I said is correct*
When every input that must be aborted is construed as non-halting
then the input to H0(DDD) is correctly construed as non-halting.
If he creates a H that does abort, he creates a false negative. It
will never be correct.
It would be very stupid to construe this as non-halting criteria,
because it is clear that it will produce false negatives, i.e. false
results.
On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 14:20 schreef olcott:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that
when H0
emulates the machine language of Infinite_Loop, Infinite_Recursion,
and
DDD that it must abort these emulations so that itself can terminate >>>>> normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, because
there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself, but
the simulation is never able to reach the final state of the
simulated self. The abort is always one cycle too early, so that the
simulating H0 misses the abort. Therefore this results in a false
negative.
(Note that H0 should process its input, which includes the H0 that
aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he
creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
No, that is not a logical conclusion.
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
*Too late you have already affirmed the words above*
Affirming the first part necessitates the second part.
On 6/17/2024 9:18 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 15:47 schreef olcott:
On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 14:20 schreef olcott:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions >>>>>>> always slip though the cracks. This is why it must be examined at >>>>>>> the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that >>>>>>> when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate >>>>>>> normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non- >>>>>>> halting.
For Infinite_Loop and Infinite_Recursion that might be true,
because there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself,
but the simulation is never able to reach the final state of the
simulated self. The abort is always one cycle too early, so that
the simulating H0 misses the abort. Therefore this results in a
false negative.
(Note that H0 should process its input, which includes the H0 that >>>>>> aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he
creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
No, that is not a logical conclusion.
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
That might be correct.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
That is wrong. It only shows that H0 is unable to simulate itself. It
tells nothing about the halting of the input.
That is not logical. If a non-aborting program is wrong, it does not
*Too late you have already affirmed the words above*
Affirming the first part necessitates the second part.
follow that a program that aborts is correct.
Please, think before you reply.
So, I repeat:
The logical conclusion if both aborting and not aborting result in
errors, is: a halt-decider cannot be based on such a simulation.
Your view here is merely ignorant of the fact that deciders
must report on the behavior specified by their inputs.
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 >>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate
normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, because
there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself, but
the simulation is never able to reach the final state of the simulated
self. The abort is always one cycle too early, so that the simulating
H0 misses the abort. Therefore this results in a false negative.
(Note that H0 should process its input, which includes the H0 that
aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he creates
a H that does not abort, it will not terminate.
*Therefore what I said is correct*
When every input that must be aborted is construed as non-halting
then the input to H0(DDD) is correctly construed as non-halting.
If he creates a H that does abort, he creates a false negative. It
will never be correct.
It would be very stupid to construe this as non-halting criteria,
because it is clear that it will produce false negatives, i.e. false
results.
On 6/17/2024 5:42 PM, Richard Damon wrote:
On 6/17/24 8:20 AM, olcott wrote:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that
when H0
emulates the machine language of Infinite_Loop, Infinite_Recursion,
and
DDD that it must abort these emulations so that itself can terminate >>>>> normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, because
there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself, but
the simulation is never able to reach the final state of the
simulated self. The abort is always one cycle too early, so that the
simulating H0 misses the abort. Therefore this results in a false
negative.
(Note that H0 should process its input, which includes the H0 that
aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he
creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
When every input that must be aborted is construed as non-halting
then the input to H0(DDD) is correctly construed as non-halting.
In other words, if you allow yourself to LIE, you can claim the wrong
answer is right.
Since your "Needing to abort" is NOT the same as halting, all you are
doing is admitting that your whole logic system is based on the
principle that LIES ARE OK.
"Needing to abort" <is> the same as a NOT halting input.
You are simply too ignorant to understand this.
When I explain this in terms of of mathematical mappings
from finite strings to behaviors this simply leaps over
everyone's head.
On 6/17/2024 8:24 PM, Richard Damon wrote:
On 6/17/24 9:16 PM, olcott wrote:It is ALWAYS the exact same sequence of bytes.
On 6/17/2024 5:42 PM, Richard Damon wrote:
On 6/17/24 8:20 AM, olcott wrote:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions >>>>>>> always slip though the cracks. This is why it must be examined at >>>>>>> the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that >>>>>>> when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate >>>>>>> normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non- >>>>>>> halting.
For Infinite_Loop and Infinite_Recursion that might be true,
because there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself,
but the simulation is never able to reach the final state of the
simulated self. The abort is always one cycle too early, so that
the simulating H0 misses the abort. Therefore this results in a
false negative.
(Note that H0 should process its input, which includes the H0 that >>>>>> aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he
creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
When every input that must be aborted is construed as non-halting
then the input to H0(DDD) is correctly construed as non-halting.
In other words, if you allow yourself to LIE, you can claim the
wrong answer is right.
Since your "Needing to abort" is NOT the same as halting, all you
are doing is admitting that your whole logic system is based on the
principle that LIES ARE OK.
"Needing to abort" <is> the same as a NOT halting input.
You are simply too ignorant to understand this.
Nope, not if you are comparing DIFFERENT version of the input.
When I explain this in terms of of mathematical mappings
from finite strings to behaviors this simply leaps over
everyone's head.
As has been shown, you can apply the input to H0 (when you don't
change it, so the call to H0 still goes to this H0), to a UTM and it
will reach the final end, so *THIS* H0 did not "Need" to abort its
input, but did because it was programmend to.
Not so much.
void DDD()
{
UTM(DDD);
}
On 6/17/2024 9:33 PM, Richard Damon wrote:
On 6/17/24 10:04 PM, olcott wrote:
On 6/17/2024 8:24 PM, Richard Damon wrote:
On 6/17/24 9:16 PM, olcott wrote:It is ALWAYS the exact same sequence of bytes.
On 6/17/2024 5:42 PM, Richard Damon wrote:
On 6/17/24 8:20 AM, olcott wrote:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of >>>>>>>>> the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions >>>>>>>>> always slip though the cracks. This is why it must be examined at >>>>>>>>> the C level before it is examined at the Turing Machine level. >>>>>>>>>
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can
terminate
normally.
When this is construed as non-halting criteria then simulating >>>>>>>>> termination analyzer H0 is correct to reject these inputs as non- >>>>>>>>> halting.
For Infinite_Loop and Infinite_Recursion that might be true,
because there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself, >>>>>>>> but the simulation is never able to reach the final state of the >>>>>>>> simulated self. The abort is always one cycle too early, so that >>>>>>>> the simulating H0 misses the abort. Therefore this results in a >>>>>>>> false negative.
(Note that H0 should process its input, which includes the H0
that aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he >>>>>>>> creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
When every input that must be aborted is construed as non-halting >>>>>>> then the input to H0(DDD) is correctly construed as non-halting.
In other words, if you allow yourself to LIE, you can claim the
wrong answer is right.
Since your "Needing to abort" is NOT the same as halting, all you
are doing is admitting that your whole logic system is based on
the principle that LIES ARE OK.
"Needing to abort" <is> the same as a NOT halting input.
You are simply too ignorant to understand this.
Nope, not if you are comparing DIFFERENT version of the input.
But if it doesn't include the bytes of H,
It is like we know that N > 50 and you can't
see that this also means N > 40.
On 6/17/2024 9:44 PM, Richard Damon wrote:
On 6/17/24 10:36 PM, olcott wrote:
On 6/17/2024 9:33 PM, Richard Damon wrote:
On 6/17/24 10:04 PM, olcott wrote:
On 6/17/2024 8:24 PM, Richard Damon wrote:
On 6/17/24 9:16 PM, olcott wrote:It is ALWAYS the exact same sequence of bytes.
On 6/17/2024 5:42 PM, Richard Damon wrote:
On 6/17/24 8:20 AM, olcott wrote:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:In other words, if you allow yourself to LIE, you can claim the >>>>>>>> wrong answer is right.
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of >>>>>>>>>>> the C programming language and what an x86 emulator does. >>>>>>>>>>>
Unless every single detail is made 100% explicit false
assumptions
always slip though the cracks. This is why it must be
examined at
the C level before it is examined at the Turing Machine level. >>>>>>>>>>>
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows >>>>>>>>>>> that when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can >>>>>>>>>>> terminate
normally.
When this is construed as non-halting criteria then simulating >>>>>>>>>>> termination analyzer H0 is correct to reject these inputs as >>>>>>>>>>> non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, >>>>>>>>>> because there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false >>>>>>>>>> assumption, as you mentioned. Here H0 needs to simulate
itself, but the simulation is never able to reach the final >>>>>>>>>> state of the simulated self. The abort is always one cycle too >>>>>>>>>> early, so that the simulating H0 misses the abort. Therefore >>>>>>>>>> this results in a false negative.
(Note that H0 should process its input, which includes the H0 >>>>>>>>>> that aborts, not a non-input with an H that does not abort.) >>>>>>>>>>
This results in a impossible dilemma for the programmer. It he >>>>>>>>>> creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
When every input that must be aborted is construed as non-halting >>>>>>>>> then the input to H0(DDD) is correctly construed as non-halting. >>>>>>>>
Since your "Needing to abort" is NOT the same as halting, all
you are doing is admitting that your whole logic system is based >>>>>>>> on the principle that LIES ARE OK.
"Needing to abort" <is> the same as a NOT halting input.
You are simply too ignorant to understand this.
Nope, not if you are comparing DIFFERENT version of the input.
But if it doesn't include the bytes of H,
It is like we know that N > 50 and you can't
see that this also means N > 40.
Nope.
How do you simulate something you do not have?
That is like says when the requirement is for N > 50 that you claim 1
is ok, because 50 can be 5*0 just like xy is x*y.
Again, how can you claim a "Correct Simulation" by the exact
definition of the x86 instruction set, when you omit the call H
instruction, and then "jump" to an addres that was never jumped to at
any point later in the program.
You just aren't bright enough to see simple truths that
every programmer can see.
void DDD()
{
H0(DDD);
}
DDD correctly simulated by any H0 cannot possibly halt.
That this truth is so simple lead me to believe that
you were lying about it instead of ordinary cluelessness.
On 6/17/2024 9:49 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 16:34 schreef olcott:
On 6/17/2024 9:18 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 15:47 schreef olcott:
On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 14:20 schreef olcott:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of >>>>>>>>> the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions >>>>>>>>> always slip though the cracks. This is why it must be examined at >>>>>>>>> the C level before it is examined at the Turing Machine level. >>>>>>>>>
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can
terminate
normally.
When this is construed as non-halting criteria then simulating >>>>>>>>> termination analyzer H0 is correct to reject these inputs as non- >>>>>>>>> halting.
For Infinite_Loop and Infinite_Recursion that might be true,
because there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false
assumption, as you mentioned. Here H0 needs to simulate itself, >>>>>>>> but the simulation is never able to reach the final state of the >>>>>>>> simulated self. The abort is always one cycle too early, so that >>>>>>>> the simulating H0 misses the abort. Therefore this results in a >>>>>>>> false negative.
(Note that H0 should process its input, which includes the H0
that aborts, not a non-input with an H that does not abort.)
This results in a impossible dilemma for the programmer. It he >>>>>>>> creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
No, that is not a logical conclusion.
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
That might be correct.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
That is wrong. It only shows that H0 is unable to simulate itself.
It tells nothing about the halting of the input.
That is not logical. If a non-aborting program is wrong, it does not
*Too late you have already affirmed the words above*
Affirming the first part necessitates the second part.
follow that a program that aborts is correct.
Please, think before you reply.
So, I repeat:
The logical conclusion if both aborting and not aborting result in
errors, is: a halt-decider cannot be based on such a simulation.
Your view here is merely ignorant of the fact that deciders
must report on the behavior specified by their inputs.
It is incorrect to assume that a failing simulation is able to report
about its input.
The simulation fails, because H0 is unable to simulate itself.
There is no possible way for the call to H0 by DDD
correctly simulated by any H0 to return to its caller.
_DDD()
[00001fd2] 55 push ebp
[00001fd3] 8bec mov ebp,esp
[00001fd5] 68d21f0000 push 00001fd2 ; push address of DDD [00001fda] e8f3f9ffff call 000019d2 ; call H0
[00001fdf] 83c404 add esp,+04
[00001fe2] 5d pop ebp
[00001fe3] c3 ret
Size in bytes:(0018) [00001fe3]
*THAT THIS IS OVER YOUR HEAD DOES NOT MEAN THAT I AM INCORRECT*
DDD correctly simulated by H0 *is* the behavior that
the finite string of x86 machine code of DDD specifies.
On 6/17/2024 10:15 PM, Richard Damon wrote:...
*Calling me a liar may get you sent to actual Hell*
On 6/17/2024 10:15 PM, Richard Damon wrote:
On 6/17/24 11:01 PM, olcott wrote:
On 6/17/2024 9:44 PM, Richard Damon wrote:
On 6/17/24 10:36 PM, olcott wrote:
On 6/17/2024 9:33 PM, Richard Damon wrote:
On 6/17/24 10:04 PM, olcott wrote:
On 6/17/2024 8:24 PM, Richard Damon wrote:
On 6/17/24 9:16 PM, olcott wrote:It is ALWAYS the exact same sequence of bytes.
On 6/17/2024 5:42 PM, Richard Damon wrote:
On 6/17/24 8:20 AM, olcott wrote:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:In other words, if you allow yourself to LIE, you can claim >>>>>>>>>> the wrong answer is right.
Op 17.jun.2024 om 05:33 schreef olcott:*Therefore what I said is correct*
To understand this analysis requires a sufficient knowledge of >>>>>>>>>>>>> the C programming language and what an x86 emulator does. >>>>>>>>>>>>>
Unless every single detail is made 100% explicit false >>>>>>>>>>>>> assumptions
always slip though the cracks. This is why it must be >>>>>>>>>>>>> examined at
the C level before it is examined at the Turing Machine level. >>>>>>>>>>>>>
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows >>>>>>>>>>>>> that when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can >>>>>>>>>>>>> terminate
normally.
When this is construed as non-halting criteria then simulating >>>>>>>>>>>>> termination analyzer H0 is correct to reject these inputs >>>>>>>>>>>>> as non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, >>>>>>>>>>>> because there the simulator processes the whole input. >>>>>>>>>>>>
The H0 case is very different. For H0 there is indeed a >>>>>>>>>>>> false assumption, as you mentioned. Here H0 needs to
simulate itself, but the simulation is never able to reach >>>>>>>>>>>> the final state of the simulated self. The abort is always >>>>>>>>>>>> one cycle too early, so that the simulating H0 misses the >>>>>>>>>>>> abort. Therefore this results in a false negative.
(Note that H0 should process its input, which includes the >>>>>>>>>>>> H0 that aborts, not a non-input with an H that does not abort.) >>>>>>>>>>>>
This results in a impossible dilemma for the programmer. It >>>>>>>>>>>> he creates a H that does not abort, it will not terminate. >>>>>>>>>>>
When every input that must be aborted is construed as
non-halting
then the input to H0(DDD) is correctly construed as non-halting. >>>>>>>>>>
Since your "Needing to abort" is NOT the same as halting, all >>>>>>>>>> you are doing is admitting that your whole logic system is >>>>>>>>>> based on the principle that LIES ARE OK.
"Needing to abort" <is> the same as a NOT halting input.
You are simply too ignorant to understand this.
Nope, not if you are comparing DIFFERENT version of the input. >>>>>>>>
But if it doesn't include the bytes of H,
It is like we know that N > 50 and you can't
see that this also means N > 40.
Nope.
How do you simulate something you do not have?
That is like says when the requirement is for N > 50 that you claim
1 is ok, because 50 can be 5*0 just like xy is x*y.
Again, how can you claim a "Correct Simulation" by the exact
definition of the x86 instruction set, when you omit the call H
instruction, and then "jump" to an addres that was never jumped to
at any point later in the program.
You just aren't bright enough to see simple truths that
every programmer can see.
void DDD()
{
H0(DDD);
}
DDD correctly simulated by any H0 cannot possibly halt.
That this truth is so simple lead me to believe that
you were lying about it instead of ordinary cluelessness.
But the question isn't DDD correctly simulated by H0, but does DDD
itself, when run halt.
The proof that you are wrong is over your head.
You have been stuck on the wrong question for ages, because you justNo that is not it. I have known the truth for two
belive your own lies, and think you are allowed to change the
definitions of terms.
decades and am just now expressing it in words.
If the halting problem is correct then truth itself
is broken. Since truth itself cannot be broken then
the halting problem cannot be correct.
This is all anchored in the details of truthmaker
maximalism.
Do that just makes you a LIAR, and so that is what you are.
*Calling me a liar may get you sent to actual Hell*
That you have a religious conviction that I am incorrect
is a bias that prevents you from trying to actually
understand what I am saying.
Perhaps you are too ignorant to understand that bias
is a systematic error.
On 6/18/2024 2:57 AM, Fred. Zwarts wrote:...
It is such a simple fact that H0 cannot possibly correct.
Are you pretending to be incompetent about the semantics of the
x86 language or you you actually incompetent?
The C people already agreed that I am correct about this:
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 17:56 schreef olcott:
On 6/17/2024 9:49 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 16:34 schreef olcott:
On 6/17/2024 9:18 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 15:47 schreef olcott:
On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 14:20 schreef olcott:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:
To understand this analysis requires a sufficient knowledge of >>>>>>>>>>> the C programming language and what an x86 emulator does. >>>>>>>>>>>
Unless every single detail is made 100% explicit false
assumptions
always slip though the cracks. This is why it must be
examined at
the C level before it is examined at the Turing Machine level. >>>>>>>>>>>
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows >>>>>>>>>>> that when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can >>>>>>>>>>> terminate
normally.
When this is construed as non-halting criteria then simulating >>>>>>>>>>> termination analyzer H0 is correct to reject these inputs as >>>>>>>>>>> non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, >>>>>>>>>> because there the simulator processes the whole input.
The H0 case is very different. For H0 there is indeed a false >>>>>>>>>> assumption, as you mentioned. Here H0 needs to simulate
itself, but the simulation is never able to reach the final >>>>>>>>>> state of the simulated self. The abort is always one cycle too >>>>>>>>>> early, so that the simulating H0 misses the abort. Therefore >>>>>>>>>> this results in a false negative.
(Note that H0 should process its input, which includes the H0 >>>>>>>>>> that aborts, not a non-input with an H that does not abort.) >>>>>>>>>>
This results in a impossible dilemma for the programmer. It he >>>>>>>>>> creates a H that does not abort, it will not terminate.
*Therefore what I said is correct*
No, that is not a logical conclusion.
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
That might be correct.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non- >>>>>>> halting.
That is wrong. It only shows that H0 is unable to simulate itself. >>>>>> It tells nothing about the halting of the input.
That is not logical. If a non-aborting program is wrong, it does
*Too late you have already affirmed the words above*
Affirming the first part necessitates the second part.
not follow that a program that aborts is correct.
Please, think before you reply.
So, I repeat:
The logical conclusion if both aborting and not aborting result in >>>>>> errors, is: a halt-decider cannot be based on such a simulation.
Your view here is merely ignorant of the fact that deciders
must report on the behavior specified by their inputs.
It is incorrect to assume that a failing simulation is able to
report about its input.
The simulation fails, because H0 is unable to simulate itself.
There is no possible way for the call to H0 by DDD
correctly simulated by any H0 to return to its caller.
We have not seen a proof for this claim and since H0 has contradictory
requirements nobody else has ever provided a proof.
But OK, lets assume your are right. Simulated H0 is unable to simulate
itself op to its final state and return to its caller, because it was
aborted one cycle before it would return to its caller.
_DDD()
[00001fd2] 55 push ebp
[00001fd3] 8bec mov ebp,esp
[00001fd5] 68d21f0000 push 00001fd2 ; push address of DDD
[00001fda] e8f3f9ffff call 000019d2 ; call H0
[00001fdf] 83c404 add esp,+04
[00001fe2] 5d pop ebp
[00001fe3] c3 ret
Size in bytes:(0018) [00001fe3]
*THAT THIS IS OVER YOUR HEAD DOES NOT MEAN THAT I AM INCORRECT*
DDD correctly simulated by H0 *is* the behavior that
the finite string of x86 machine code of DDD specifies.
It is such a simple fact that H0 cannot possibly correct.
Are you pretending to be incompetent about the semantics of the
x86 language or you you actually incompetent?
The C people already agreed that I am correct about this:
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-halting
by returning 0 to its caller.
If it does not abort it does not return. If it does abort, it does not
see the correct behaviour that was specified in the input, because it
aborted its simulation one cycle too early to see the behaviour in the
input.
H0 fails to do a correct simulation, because it does not process all
of its input, but aborts its input before it can process the part of
the input that also specifies behaviour. The final behaviour specified
by the input is unreachable for the simulator, because it is unable to
simulate itself.
If even such simple facts are over your head, you must be stuck in
rebuttal mode very deeply.
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
You either lack this degree of skill in C or are only
interested in playing head games.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
Everything correct, no further questions allowed.
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 14:38 schreef olcott:
On 6/18/2024 2:57 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 17:56 schreef olcott:
On 6/17/2024 9:49 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 16:34 schreef olcott:
On 6/17/2024 9:18 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 15:47 schreef olcott:Your view here is merely ignorant of the fact that deciders
On 6/17/2024 8:30 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 14:20 schreef olcott:
On 6/17/2024 3:31 AM, Fred. Zwarts wrote:
Op 17.jun.2024 om 05:33 schreef olcott:*Therefore what I said is correct*
To understand this analysis requires a sufficient knowledge of >>>>>>>>>>>>> the C programming language and what an x86 emulator does. >>>>>>>>>>>>>
Unless every single detail is made 100% explicit false >>>>>>>>>>>>> assumptions
always slip though the cracks. This is why it must be >>>>>>>>>>>>> examined at
the C level before it is examined at the Turing Machine level. >>>>>>>>>>>>>
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows >>>>>>>>>>>>> that when H0
emulates the machine language of Infinite_Loop,
Infinite_Recursion, and
DDD that it must abort these emulations so that itself can >>>>>>>>>>>>> terminate
normally.
When this is construed as non-halting criteria then simulating >>>>>>>>>>>>> termination analyzer H0 is correct to reject these inputs >>>>>>>>>>>>> as non-
halting.
For Infinite_Loop and Infinite_Recursion that might be true, >>>>>>>>>>>> because there the simulator processes the whole input. >>>>>>>>>>>>
The H0 case is very different. For H0 there is indeed a >>>>>>>>>>>> false assumption, as you mentioned. Here H0 needs to
simulate itself, but the simulation is never able to reach >>>>>>>>>>>> the final state of the simulated self. The abort is always >>>>>>>>>>>> one cycle too early, so that the simulating H0 misses the >>>>>>>>>>>> abort. Therefore this results in a false negative.
(Note that H0 should process its input, which includes the >>>>>>>>>>>> H0 that aborts, not a non-input with an H that does not abort.) >>>>>>>>>>>>
This results in a impossible dilemma for the programmer. It >>>>>>>>>>>> he creates a H that does not abort, it will not terminate. >>>>>>>>>>>
No, that is not a logical conclusion.
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop, >>>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations >>>>>>>>> so that itself can terminate normally.
That might be correct.
When this is construed as non-halting criteria then simulating >>>>>>>>> termination analyzer H0 is correct to reject these inputs as non- >>>>>>>>> halting.
That is wrong. It only shows that H0 is unable to simulate
itself. It tells nothing about the halting of the input.
That is not logical. If a non-aborting program is wrong, it does >>>>>>>> not follow that a program that aborts is correct.
*Too late you have already affirmed the words above*
Affirming the first part necessitates the second part.
Please, think before you reply.
So, I repeat:
The logical conclusion if both aborting and not aborting result >>>>>>>> in errors, is: a halt-decider cannot be based on such a simulation. >>>>>>>
must report on the behavior specified by their inputs.
It is incorrect to assume that a failing simulation is able to
report about its input.
The simulation fails, because H0 is unable to simulate itself.
There is no possible way for the call to H0 by DDD
correctly simulated by any H0 to return to its caller.
We have not seen a proof for this claim and since H0 has
contradictory requirements nobody else has ever provided a proof.
But OK, lets assume your are right. Simulated H0 is unable to
simulate itself op to its final state and return to its caller,
because it was aborted one cycle before it would return to its caller. >>>>
_DDD()
[00001fd2] 55 push ebp
[00001fd3] 8bec mov ebp,esp
[00001fd5] 68d21f0000 push 00001fd2 ; push address of DDD >>>>> [00001fda] e8f3f9ffff call 000019d2 ; call H0
[00001fdf] 83c404 add esp,+04
[00001fe2] 5d pop ebp
[00001fe3] c3 ret
Size in bytes:(0018) [00001fe3]
*THAT THIS IS OVER YOUR HEAD DOES NOT MEAN THAT I AM INCORRECT*
DDD correctly simulated by H0 *is* the behavior that
the finite string of x86 machine code of DDD specifies.
It is such a simple fact that H0 cannot possibly correct.
Are you pretending to be incompetent about the semantics of the
x86 language or you you actually incompetent?
I understand x86, but I am afraid you don't. Because you assume
results that are not there.
The C people already agreed that I am correct about this:
No serious C people have agreed. They can't, because your H0 has
contradictory requirements.
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
You either lack this degree of skill in C or are only
interested in playing head games.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 >>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate
normally.
You are repeating. It seems difficult for you to escape rebuttal mode.
It was shown already to you that the first two examples are very
different from the last one.
The last one is equivalent to:
int main()
{
return H0(main);
}
where your own proved that H reports a false negative. This is the
same case as DDD.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-halting >>> by returning 0 to its caller.
It is incorrect to report the last one as non-halting, because H0
aborts one cycle too early, which makes that it misses the fact that
the simulated self would abort and halt.
If it does not abort it does not return. If it does abort, it does
not see the correct behaviour that was specified in the input,
because it aborted its simulation one cycle too early to see the
behaviour in the input.
H0 fails to do a correct simulation, because it does not process all
of its input, but aborts its input before it can process the part of
the input that also specifies behaviour. The final behaviour
specified by the input is unreachable for the simulator, because it
is unable to simulate itself.
If even such simple facts are over your head, you must be stuck in
rebuttal mode very deeply.
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:...
Op 18.jun.2024 om 17:33 schreef olcott:
I have seen the response. It was most certainly not a serious reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even if
the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
On 6/18/2024 11:21 AM, Mikko wrote:
On 2024-06-17 03:33:50 +0000, olcott said:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 >>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and
DDD that it must abort these emulations so that itself can terminate
normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
The subject line is incorrect. The OP of "Simulating termination analyzers >> for dummies" should tell what a "simulating termination analyzer" is.
The OP of this thread does not.
I state the prerequisites if you don't have them
then you cannot understand. If you have them then
what I say is self-evidently true.
On 6/18/2024 7:42 AM, Python wrote:
Le 18/06/2024 à 14:38, olcott a écrit :I arranged for weekly meetings on repentance with those
On 6/18/2024 2:57 AM, Fred. Zwarts wrote:...
It is such a simple fact that H0 cannot possibly correct.
Are you pretending to be incompetent about the semantics of the
x86 language or you you actually incompetent?
The C people already agreed that I am correct about this:
Definitely NOT. Given that the following code is not an assertion
(and does not even compile, as usual with Peter Olcott productions).
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Have you checked weather forecast in Hell as you are likely
to end up there soon?
delegated with the authority to discuss this with me.
I only have three months left before I will be on medicine that
tends to greatly reduce the levels of several kinds of very
important blood cells. My POD24 diagnosis means that my cancer
came back too soon to try chemotherapy again.
I went though chemo better than average, I only felt really
sick for three days. I had to spend three days in the hospital
three different times because I had a very slight fever of 100.4F
and very low neutrophil counts, AKA Neutropenia. One of these
three times I could not eat or sleep at all for three days.
Validation of POD24 as a robust early clinical end point of
poor survival in FL from 5225 patients on 13 clinical trials https://pubmed.ncbi.nlm.nih.gov/34614146/
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even if
the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest you
would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000020c2][001036c3][00000000] 55 push ebp [000020c3][001036c3][00000000] 8bec mov ebp,esp [000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp [000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp [000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04 [000020d2][001036bf][00000000] 50 push eax [000020d3][001036bb][00000743] 6843070000 push 00000743 [000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08 [000020e0][001036c3][00000000] eb04 jmp 000020e6 [000020e6][001036c3][00000000] 33c0 xor eax,eax [000020e8][001036c7][00000018] 5d pop ebp [000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
On 6/18/2024 11:37 AM, Mikko wrote:
On 2024-06-18 16:30:46 +0000, olcott said:
On 6/18/2024 11:21 AM, Mikko wrote:
On 2024-06-17 03:33:50 +0000, olcott said:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions
always slip though the cracks. This is why it must be examined at
the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0 >>>>> emulates the machine language of Infinite_Loop, Infinite_Recursion, and >>>>> DDD that it must abort these emulations so that itself can terminate >>>>> normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non-
halting.
The subject line is incorrect. The OP of "Simulating termination analyzers >>>> for dummies" should tell what a "simulating termination analyzer" is.
The OP of this thread does not.
I state the prerequisites if you don't have them
then you cannot understand. If you have them then
what I say is self-evidently true.
What you sais ooes not include what the subject line promised.
If all that you know is C and what and x86 emulator does
then you do obtain the gist of what a simulating termination
and analyzer does.
Because most people only glance at a couple of my words before
forming their rebuttal I had to make it overly concise.
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even
if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest
you would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f >>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives,
when used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
On 6/19/2024 8:56 AM, Fred. Zwarts wrote:
Op 19.jun.2024 om 15:00 schreef olcott:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply. >>>>>> But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode,
even if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest >>>>>> you would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f >>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives,
when used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not
possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
Yes, that is your attitude. An example that proves you are wrong are
called 'screwy'. You prefer more complex examples, for which you can
easier hide the essential details.
void DDD()
{
HH0(DDD);
}
int main()
{
HH0(DDD);
}
_DDD()
[00002093] 55 push ebp
[00002094] 8bec mov ebp,esp
[00002096] 6893200000 push 00002093 ; push DDD
[0000209b] e853f4ffff call 000014f3 ; call HH0
[000020a0] 83c404 add esp,+04
[000020a3] 5d pop ebp
[000020a4] c3 ret
Size in bytes:(0018) [000020a4]
_main()
[000020b3] 55 push ebp
[000020b4] 8bec mov ebp,esp
[000020b6] 6893200000 push 00002093 ; push DDD
[000020bb] e833f4ffff call 000014f3 ; call HH0
[000020c0] 83c404 add esp,+04
[000020c3] eb04 jmp 000020c9
[000020c5] 33c0 xor eax,eax
[000020c7] eb02 jmp 000020cb
[000020c9] 33c0 xor eax,eax
[000020cb] 5d pop ebp
[000020cc] c3 ret
Size in bytes:(0026) [000020cc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= [000020b3][00103680][00000000] 55 push ebp ; begin main
[000020b4][00103680][00000000] 8bec mov ebp,esp [000020b6][0010367c][00002093] 6893200000 push 00002093 ; push DDD [000020bb][00103678][000020c0] e833f4ffff call 000014f3 ; call HH0
New slave_stack at:103724
Begin Local Halt Decider Simulation Execution Trace Stored at:11372c [00002093][0011371c][00113720] 55 push ebp ; begin DDD
[00002094][0011371c][00113720] 8bec mov ebp,esp [00002096][00113718][00002093] 6893200000 push 00002093 ; push DDD [0000209b][00113714][000020a0] e853f4ffff call 000014f3 ; call HH0
That call right there to HH0 is fully simulated by the directly
executed HH0 and the 150 pages of steps are not displayed so that
the next four steps of DDD correctly simulated by the correctly
simulated HH0 can be clearly seen and not mixed into the 150 pages
of the instructions of the simulated HH0.
New slave_stack at:14e14c
[00002093][0015e144][0015e148] 55 push ebp ; begin DDD
[00002094][0015e144][0015e148] 8bec mov ebp,esp [00002096][0015e140][00002093] 6893200000 push 00002093 ; push DDD [0000209b][0015e13c][000020a0] e853f4ffff call 000014f3 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020c0][00103680][00000000] 83c404 add esp,+04 ; return to main
[000020c3][00103680][00000000] eb04 jmp 000020c9 [000020c9][00103680][00000000] 33c0 xor eax,eax [000020cb][00103684][00000018] 5d pop ebp [000020cc][00103688][00000000] c3 ret ; end main
Number of Instructions Executed(10067) == 150 Pages
On 6/19/2024 4:30 AM, Mikko wrote:What do you call this, argument from obscurity? You should explain better.
On 2024-06-18 16:45:42 +0000, olcott said:
On 6/18/2024 11:37 AM, Mikko wrote:
On 2024-06-18 16:30:46 +0000, olcott said:
On 6/18/2024 11:21 AM, Mikko wrote:
On 2024-06-17 03:33:50 +0000, olcott said:
The subject line is incorrect. The OP of "Simulating terminationI state the prerequisites if you don't have them then you cannot
analyzers for dummies" should tell what a "simulating termination
analyzer" is.
The OP of this thread does not.
understand. If you have them then what I say is self-evidently true.
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even
if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest
you would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f >>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives,
when used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply. >>>>>> But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode,
even if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest >>>>>> you would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f >>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives,
when used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not
possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here
Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
Why does H0 NEED to be able to correctly simulate its input?
Decider must compute the mapping from their finite string
input to the actual behavior that this finite string specifies.
They are not free to imagine the behavior that the authors of
textbooks expect.
Your question is just a Strawman, replacing the OBJECTIVE criteria of
the behavior of the machine represented by the input (which inlcudes
the code for H0) with the SUBJECTIVE question of what H0 thinks about it.
And, your H0 doesn't correctly simulate the input, as the *ONLY*
correct simulation of that input would be:
simulate the push ebp
simulate the mov ebp,esp
simulate the push 000020a2
simulate the call 00001aa2
simulate the instruction at 00001aa2
I now have a 195 page color-coded execution trace
showing HH0 correctly simulating DDD calling
a simulated HH0 simulating another instance of DDD. https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
since that isn't what you have ever shown as the simulation by H0, you
have lost the right to call its simulation "correct".
Sorry, your argument is just a lie.
*It never has been a falsehood*
On 6/19/2024 8:39 PM, Richard Damon wrote:
On 6/19/24 8:44 PM, olcott wrote:The finite string input does not communicate the behavior
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious
reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, >>>>>>>> even if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were
honest you would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly >>>>>>> address address data code language >>>>>>> ======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main >>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>> New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored
at:11376f
[000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main >>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>> New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main >>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false
negatives, when used to determine halting behaviour, please, stop
to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not
possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here >>>>> Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
Why does H0 NEED to be able to correctly simulate its input?
Decider must compute the mapping from their finite string
input to the actual behavior that this finite string specifies.
They are not free to imagine the behavior that the authors of
textbooks expect.
AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
Yes, the DO need to follow the behavior that the author of the problem
defined.
You are just showing you think it is ok to not follow the REQURIEMENTS
and just LIE about what you are doing.
that the textbook authors expect it to communicate.
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even if >>>> the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest you >>>> would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f >>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives,
when used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not
possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
On 6/19/2024 4:30 AM, Mikko wrote:
On 2024-06-18 16:45:42 +0000, olcott said:
On 6/18/2024 11:37 AM, Mikko wrote:
On 2024-06-18 16:30:46 +0000, olcott said:
On 6/18/2024 11:21 AM, Mikko wrote:
On 2024-06-17 03:33:50 +0000, olcott said:
To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does.
Unless every single detail is made 100% explicit false assumptions >>>>>>> always slip though the cracks. This is why it must be examined at >>>>>>> the C level before it is examined at the Turing Machine level.
typedef void (*ptr)();
int H0(ptr P);
void Infinite_Loop()
{
HERE: goto HERE;
}
void Infinite_Recursion()
{
Infinite_Recursion();
}
void DDD()
{
H0(DDD);
return;
}
int main()
{
H0(Infinite_Loop);
H0(Infinite_Recursion);
H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows that when H0
emulates the machine language of Infinite_Loop, Infinite_Recursion, and >>>>>>> DDD that it must abort these emulations so that itself can terminate >>>>>>> normally.
When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as non- >>>>>>> halting.
The subject line is incorrect. The OP of "Simulating termination analyzers
for dummies" should tell what a "simulating termination analyzer" is. >>>>>> The OP of this thread does not.
I state the prerequisites if you don't have them
then you cannot understand. If you have them then
what I say is self-evidently true.
What you sais ooes not include what the subject line promised.
If all that you know is C and what and x86 emulator does
then you do obtain the gist of what a simulating termination
and analyzer does.
I am not in your target audience (dummies who have good knowledge
of C and x86 emulator) so what I know or understand is outside of
the scope of this discussion.
Because most people only glance at a couple of my words before
forming their rebuttal I had to make it overly concise.
If there is an error in those couple of words then there is no
need to discuss the rest.
OK so if you flat out don't have the mandatory prerequisites
there is no sense continuing our conversion. My impression
was that you understood these things quite well.
On 6/19/2024 10:47 AM, Fred. Zwarts wrote:
Op 19.jun.2024 om 17:01 schreef olcott:
On 6/19/2024 8:56 AM, Fred. Zwarts wrote:Exactly what I said. Ignore simple proofs like:
Op 19.jun.2024 om 15:00 schreef olcott:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious
reply.
But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, >>>>>>>> even if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were
honest you would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly >>>>>>> address address data code language >>>>>>> ======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main >>>>>>> [000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>> New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored
at:11376f
[000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main >>>>>>> [000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>> New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main >>>>>>> [000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false
negatives, when used to determine halting behaviour, please, stop
to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not
possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping
[000020b3] c3 ret ; never gets here >>>>> Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
Yes, that is your attitude. An example that proves you are wrong are
called 'screwy'. You prefer more complex examples, for which you can
easier hide the essential details.
void DDD()
{
HH0(DDD);
}
int main()
{
HH0(DDD);
}
_DDD()
[00002093] 55 push ebp
[00002094] 8bec mov ebp,esp
[00002096] 6893200000 push 00002093 ; push DDD
[0000209b] e853f4ffff call 000014f3 ; call HH0
[000020a0] 83c404 add esp,+04
[000020a3] 5d pop ebp
[000020a4] c3 ret
Size in bytes:(0018) [000020a4]
_main()
[000020b3] 55 push ebp
[000020b4] 8bec mov ebp,esp
[000020b6] 6893200000 push 00002093 ; push DDD
[000020bb] e833f4ffff call 000014f3 ; call HH0
[000020c0] 83c404 add esp,+04
[000020c3] eb04 jmp 000020c9
[000020c5] 33c0 xor eax,eax
[000020c7] eb02 jmp 000020cb
[000020c9] 33c0 xor eax,eax
[000020cb] 5d pop ebp
[000020cc] c3 ret
Size in bytes:(0026) [000020cc]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000020b3][00103680][00000000] 55 push ebp ; begin main
[000020b4][00103680][00000000] 8bec mov ebp,esp
[000020b6][0010367c][00002093] 6893200000 push 00002093 ; push DDD
[000020bb][00103678][000020c0] e833f4ffff call 000014f3 ; call HH0
New slave_stack at:103724
Begin Local Halt Decider Simulation Execution Trace Stored at:11372c >>> [00002093][0011371c][00113720] 55 push ebp ; begin DDD
[00002094][0011371c][00113720] 8bec mov ebp,esp
[00002096][00113718][00002093] 6893200000 push 00002093 ; push DDD
[0000209b][00113714][000020a0] e853f4ffff call 000014f3 ; call HH0
That call right there to HH0 is fully simulated by the directly
executed HH0 and the 150 pages of steps are not displayed so that
the next four steps of DDD correctly simulated by the correctly
simulated HH0 can be clearly seen and not mixed into the 150 pages
of the instructions of the simulated HH0.
New slave_stack at:14e14c
[00002093][0015e144][0015e148] 55 push ebp ; begin DDD
[00002094][0015e144][0015e148] 8bec mov ebp,esp
[00002096][0015e140][00002093] 6893200000 push 00002093 ; push DDD
[0000209b][0015e13c][000020a0] e853f4ffff call 000014f3 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020c0][00103680][00000000] 83c404 add esp,+04 ; return to main
[000020c3][00103680][00000000] eb04 jmp 000020c9
[000020c9][00103680][00000000] 33c0 xor eax,eax
[000020cb][00103684][00000018] 5d pop ebp
[000020cc][00103688][00000000] c3 ret ; end main
Number of Instructions Executed(10067) == 150 Pages
int main()
{
return H(main, 0);
}
For which you proved that it reports a false negative.
The correctly emulated input DOES NOT HALT.
The directly executed main() only seems to halt
because the directly executed main() is essentially
the first call in a recursive chain where the
second call is always aborted.
On 6/19/2024 9:17 PM, Richard Damon wrote:
On 6/19/24 10:02 PM, olcott wrote:
On 6/19/2024 8:39 PM, Richard Damon wrote:
On 6/19/24 8:44 PM, olcott wrote:The finite string input does not communicate the behavior
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently >>>>>>>>>>> agreed to the following verbatim statement in the C group. >>>>>>>>>
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious >>>>>>>>>> reply.
But you know apparently to little of C to understand that. >>>>>>>>>> Probably, because you are unable to escape from rebuttal mode, >>>>>>>>>> even if the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were >>>>>>>>>> honest you would stop claiming that H is correct.
That is merely a more difficult to understand version of this >>>>>>>>> same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly >>>>>>>>> address address data code language >>>>>>>>> ======== ======== ======== ========= ============= >>>>>>>>> [000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push >>>>>>>>> main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>>>> New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored >>>>>>>>> at:11376f
[000020c2][0011375f][00113763] 55 push ebp ; begin
main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push >>>>>>>>> main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>>>> New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin
main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push >>>>>>>>> main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0 >>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6 >>>>>>>>> [000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit
main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added. >>>>>>>> You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false
negatives, when used to determine halting behaviour, please,
stop to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not >>>>>>>> possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
void DDD()
{
H0(DDD);
}
_DDD()
[000020a2] 55 push ebp ; housekeeping
[000020a3] 8bec mov ebp,esp ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404 add esp,+04 ; housekeeping
[000020b2] 5d pop ebp ; housekeeping >>>>>>> [000020b3] c3 ret ; never gets here >>>>>>> Size in bytes:(0018) [000020b3]
Exactly which step of DDD emulated by H0 was emulated
incorrectly such that this emulation would be complete?
AKA DDD emulated by H0 reaches machine address [000020b3]
Why does H0 NEED to be able to correctly simulate its input?
Decider must compute the mapping from their finite string
input to the actual behavior that this finite string specifies.
They are not free to imagine the behavior that the authors of
textbooks expect.
AND THE DEFINITION OF THAT BEHAVIOR IS THE BEHAVIOR OF THE DIRECT
EXECUTION OF THE PROGRAM THE INPUT REPRESENTS.
Yes, the DO need to follow the behavior that the author of the
problem defined.
You are just showing you think it is ok to not follow the
REQURIEMENTS and just LIE about what you are doing.
that the textbook authors expect it to communicate.
The finite string certainly DOES communicate what is needed to
determine the behavior, or it wasn't a correct representation.
There is no sequence of truth preserving operations from the finite
string machine code of DDD that can correctly ignore the pathological relationship between H0 and DDD as an aspect of the behavior that
this finite string specifies.
No one has noticed this before because no one ever thought to make
every single detail 100% concrete, thus leaving huge gaps in all
prior reasoning.
On 6/20/2024 12:17 AM, Mikko wrote:
On 2024-06-19 13:00:57 +0000, olcott said:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is a verified fact that serious C people have recently
agreed to the following verbatim statement in the C group.
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv4pg5p%24morv%241%40raubtier-asyl.eternal-september.org%3E+
You either lack this degree of skill in C or are only
interested in playing head games.
I have seen the response. It was most certainly not a serious reply. >>>>>> But you know apparently to little of C to understand that.
Probably, because you are unable to escape from rebuttal mode, even if >>>>>> the truth is obvious.
I have known C since K&R was the standard and met
Bjarne Stroustrup when he came to our university
to promote his new C++ programming language.
*You seem to be willfully ignorant*
It was your own proof that showed that in
int main()
{
return H(main);
}
main halts, whereas H reported non-halting. So, it you were honest you >>>>>> would stop claiming that H is correct.
That is merely a more difficult to understand version of this
same pathological relationship.
int main()
{
Output("Input_Halts = ", HH0(main));
}
_main()
[000020c2] 55 push ebp
[000020c3] 8bec mov ebp,esp
[000020c5] 68c2200000 push 000020c2 ; push main
[000020ca] e833f4ffff call 00001502 ; call HH0
[000020cf] 83c404 add esp,+04
[000020d2] 50 push eax
[000020d3] 6843070000 push 00000743
[000020d8] e885e6ffff call 00000762
[000020dd] 83c408 add esp,+08
[000020e0] eb04 jmp 000020e6
[000020e2] 33c0 xor eax,eax
[000020e4] eb02 jmp 000020e8
[000020e6] 33c0 xor eax,eax
[000020e8] 5d pop ebp
[000020e9] c3 ret
Size in bytes:(0040) [000020e9]
machine stack stack machine assembly
address address data code language >>>>> ======== ======== ======== ========= =============
[000020c2][001036c3][00000000] 55 push ebp
[000020c3][001036c3][00000000] 8bec mov ebp,esp
[000020c5][001036bf][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][001036bb][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:103767
Begin Local Halt Decider Simulation Execution Trace Stored at:11376f >>>>> [000020c2][0011375f][00113763] 55 push ebp ; begin main
[000020c3][0011375f][00113763] 8bec mov ebp,esp
[000020c5][0011375b][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][00113757][000020cf] e833f4ffff call 00001502 ; call HH0
New slave_stack at:14e18f
[000020c2][0015e187][0015e18b] 55 push ebp ; begin main
[000020c3][0015e187][0015e18b] 8bec mov ebp,esp
[000020c5][0015e183][000020c2] 68c2200000 push 000020c2 ; push main
[000020ca][0015e17f][000020cf] e833f4ffff call 00001502 ; call HH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[000020cf][001036c3][00000000] 83c404 add esp,+04
[000020d2][001036bf][00000000] 50 push eax
[000020d3][001036bb][00000743] 6843070000 push 00000743
[000020d8][001036bb][00000743] e885e6ffff call 00000762
Input_Halts = 0
[000020dd][001036c3][00000000] 83c408 add esp,+08
[000020e0][001036c3][00000000] eb04 jmp 000020e6
[000020e6][001036c3][00000000] 33c0 xor eax,eax
[000020e8][001036c7][00000018] 5d pop ebp
[000020e9][001036cb][00000000] c3 ret ; exit main
Number of Instructions Executed(10070) == 150 Pages
It is easier to understand because a print statement was added.
You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false negatives,
when used to determine halting behaviour, please, stop to call them
halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not
possible.
I don't want to discuss your screwy example because I
can't use screwy examples in my paper.
If you could ever publish a paper there would soon be papers with examples >> (which you may call "screwy") that your method gets wrong.
My whole purpose is to refute the conventional proofs.
On 6/19/2024 9:17 PM, Richard Damon wrote:Yeah, why? That just adds a contradictory requirement. Not that it were possible otherwise.
On 6/19/24 10:02 PM, olcott wrote:
On 6/19/2024 8:39 PM, Richard Damon wrote:
On 6/19/24 8:44 PM, olcott wrote:
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is easier to understand because a print statement was added. >>>>>>>> You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false
negatives, when used to determine halting behaviour, please, stop >>>>>>>> to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the
simulation was correct, when false, the full simulation was not >>>>>>>> possible.
Why does H0 NEED to be able to simulate its input?
If possible.Decider must compute the mapping from their finite string input to
the actual behavior that this finite string specifies.
Nor crackpots.They are not free to imagine the behavior that the authors of
textbooks expect.
Bullshit. Your neither-decider-nor-simulator just can't handle it.The finite string input does not communicate the behavior that the
textbook authors expect it to communicate.
Deflection follows:The finite string certainly DOES communicate what is needed to
determine the behavior, or it wasn't a correct representation.
There is no sequence of truth preserving operations from the finiteMany other simulators or deciders work correctly with DDD, just not the
string machine code of DDD that can correctly ignore the pathological relationship between H0 and DDD as an aspect of the behavior that this
finite string specifies.
No one has noticed this before because no one ever thought to make every single detail 100% concrete, thus leaving huge gaps in all priorWe have a proof.
reasoning.
On 6/20/2024 5:48 PM, joes wrote:Why do you want to decide halting by incomplete simulation?
Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott:
On 6/19/2024 9:17 PM, Richard Damon wrote:
On 6/19/24 10:02 PM, olcott wrote:
On 6/19/2024 8:39 PM, Richard Damon wrote:
On 6/19/24 8:44 PM, olcott wrote:
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
Yeah, why? That just adds a contradictory requirement. Not that it wereWhy does H0 NEED to be able to simulate its input?
possible otherwise.
Which it is not.If possible.Decider must compute the mapping from their finite string input to >>>>>>> the actual behavior that this finite string specifies.
Your "simulator" is wrong.Nor crackpots.They are not free to imagine the behavior that the authors of
textbooks expect.
Bullshit. Your neither-decider-nor-simulator just can't handle it.The finite string input does not communicate the behavior that the
textbook authors expect it to communicate.
The direct execution of DDD is the measure of things. A simulation must
behave identically. Of course you may be able to do analysis on whether
it halts, but that's different. Simulation is dumb.
Your H0 can not derive the behaviour of DDD, because it contradicts itsThe finite string certainly DOES communicate what is needed to
determine the behavior, or it wasn't a correct representation.
There is no sequence of truth preserving operations from the finiteWhat do you mean with "ignore the relationship"?
string machine code of DDD that can correctly ignore the pathological
relationship between H0 and DDD as an aspect of the behavior that this
finite string specifies.
Go ahead, disprove Turing.We have a proof.You have dogmatic false assumptions.
It is an verified fact that the input to H(D,D) cannot be mapped to the behavior of D(D).Yes, H can not decide/simulate D(D). G can that exact D constructed
When I say "mapped" I don't mean look something up in Google maps.Cut the insults.
On 6/20/2024 5:48 PM, joes wrote:
Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott:
On 6/19/2024 9:17 PM, Richard Damon wrote:Yeah, why? That just adds a contradictory requirement. Not that it were
On 6/19/24 10:02 PM, olcott wrote:
On 6/19/2024 8:39 PM, Richard Damon wrote:
On 6/19/24 8:44 PM, olcott wrote:
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is easier to understand because a print statement was added. >>>>>>>>>> You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false
negatives, when used to determine halting behaviour, please, stop >>>>>>>>>> to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the >>>>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>>>> possible.
Why does H0 NEED to be able to simulate its input?
possible otherwise.
If possible.Decider must compute the mapping from their finite string input to >>>>>>> the actual behavior that this finite string specifies.
Nor crackpots.They are not free to imagine the behavior that the authors of
textbooks expect.
Bullshit. Your neither-decider-nor-simulator just can't handle it.The finite string input does not communicate the behavior that the
textbook authors expect it to communicate.
The direct execution of DDD is the measure of things. A simulation
must behave identically. Of course you may be able to do analysis
on whether it halts, but that's different. Simulation is dumb.
Deflection follows:The finite string certainly DOES communicate what is needed to
determine the behavior, or it wasn't a correct representation.
There is no sequence of truth preserving operations from the finiteMany other simulators or deciders work correctly with DDD, just not the
string machine code of DDD that can correctly ignore the pathological
relationship between H0 and DDD as an aspect of the behavior that this
finite string specifies.
one it calls. But they each get a different one wrong.
What do you mean with "ignore the relationship"?
No one has noticed this before because no one ever thought to make every >>> single detail 100% concrete, thus leaving huge gaps in all priorWe have a proof.
reasoning.
You have dogmatic false assumptions.
It is an verified fact that the input to H(D,D) cannot
be mapped to the behavior of D(D).
When I say "mapped" I don't mean look something
up in Google maps.
On 6/20/2024 8:55 PM, Richard Damon wrote:
On 6/20/24 6:52 PM, olcott wrote:
On 6/20/2024 5:48 PM, joes wrote:
Am Wed, 19 Jun 2024 21:25:31 -0500 schrieb olcott:
On 6/19/2024 9:17 PM, Richard Damon wrote:Yeah, why? That just adds a contradictory requirement. Not that it were >>>> possible otherwise.
On 6/19/24 10:02 PM, olcott wrote:
On 6/19/2024 8:39 PM, Richard Damon wrote:
On 6/19/24 8:44 PM, olcott wrote:
On 6/19/2024 7:23 PM, Richard Damon wrote:
On 6/19/24 9:00 AM, olcott wrote:
On 6/19/2024 3:08 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 18:26 schreef olcott:
On 6/18/2024 10:47 AM, Fred. Zwarts wrote:
Op 18.jun.2024 om 17:33 schreef olcott:
On 6/18/2024 10:20 AM, Fred. Zwarts wrote:
It is easier to understand because a print statement was added. >>>>>>>>>>>> You proved that it halts, but H0 reports non-halting.
So, it produces a false negative.
So, now it has been proved that H, H0, etc produce false >>>>>>>>>>>> negatives, when used to determine halting behaviour, please, >>>>>>>>>>>> stop
to call them halt-deciders, or termination-deciders.
They might be "simulation deciders". When returning true, the >>>>>>>>>>>> simulation was correct, when false, the full simulation was not >>>>>>>>>>>> possible.
Why does H0 NEED to be able to simulate its input?
If possible.Decider must compute the mapping from their finite string input to >>>>>>>>> the actual behavior that this finite string specifies.
Nor crackpots.They are not free to imagine the behavior that the authors of >>>>>>>>> textbooks expect.
Bullshit. Your neither-decider-nor-simulator just can't handle it.The finite string input does not communicate the behavior that the >>>>>>> textbook authors expect it to communicate.
The direct execution of DDD is the measure of things. A simulation
must behave identically. Of course you may be able to do analysis
on whether it halts, but that's different. Simulation is dumb.
Deflection follows:The finite string certainly DOES communicate what is needed to
determine the behavior, or it wasn't a correct representation.
There is no sequence of truth preserving operations from the finiteMany other simulators or deciders work correctly with DDD, just not the >>>> one it calls. But they each get a different one wrong.
string machine code of DDD that can correctly ignore the pathological >>>>> relationship between H0 and DDD as an aspect of the behavior that this >>>>> finite string specifies.
What do you mean with "ignore the relationship"?
No one has noticed this before because no one ever thought to makeWe have a proof.
every
single detail 100% concrete, thus leaving huge gaps in all prior
reasoning.
You have dogmatic false assumptions.
It is an verified fact that the input to H(D,D) cannot
be mapped to the behavior of D(D).
????
But the Halting Function does that map.
I ask you to show the detailed steps of that map and
you always dodge. This leads me to believe that you
know you are lying.
_DDD()
[00002093] 55 push ebp
[00002094] 8bec mov ebp,esp
[00002096] 6893200000 push 00002093 ; push DDD
[0000209b] e853f4ffff call 000014f3 ; call HH0
[000020a0] 83c404 add esp,+04
[000020a3] 5d pop ebp
[000020a4] c3 ret
Size in bytes:(0018) [000020a4]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 422 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 184:10:34 |
| Calls: | 8,947 |
| Calls today: | 14 |
| Files: | 13,352 |
| Messages: | 5,991,295 |