This is meant for Mike, Joes and Fred don't have the technicalFuck you too.
competence to understand it.
Mike: It seems that HHH has been a pure function of its inputs and neverThe indirectly called HHH's most certainly make a decision.
has provided data downward to its slaves that corrupts their halt status decision. They don't even make a halt status decision thus cannot make a corrupted one.
I could change the code so that the slave instances can and do try toThat's kinda the point.
form a halt status decision on the basis of the execution trace that
they do have.
There is no sense in doing that because they can't possibly have enough
data, they will always be one whole execution trace behind the next
outer instance of HHH.
u32 Decide_Halting_HH(u32** Aborted,There it is.
u32** execution_trace,
Decoded_Line_Of_Code** decoded,
u32 code_end,
u32 End_Of_Code, Registers**
master_state, Registers**
slave_state, u32** slave_stack,
u32 Root)
{
u32 aborted_temp = 0; // 2024-06-05 u32
Current_Length_Of_Execution_Trace = 0;
while (aborted_temp == 0) // 2024-06-05 {
if (Root) // Master UTM halt decider {
if (aborted_temp == 1) // 2021-01-26 Must be aborted
return 0;
return 1; // 2021-01-26 Need not be aborted
}
This is meant for Mike, Joes and Fred don't have the technical competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
I could change the code so that the slave instances can and doYour concept of master/slaves simulators is broken. There are outer/inner simulators but that is
try to form a halt status decision on the basis of the execution
trace that they do have.
There is no sense in doing that because they can't possibly have
enough data, they will always be one whole execution trace behind
the next outer instance of HHH.
As they are the slaves perform their proper function of showing
the actual behavior of DDD correctly emulated by HHH.
u32 Decide_Halting_HH(u32** Aborted,
u32** execution_trace,
Decoded_Line_Of_Code** decoded,
u32 code_end,
u32 End_Of_Code,
Registers** master_state,
Registers** slave_state,
u32** slave_stack,
u32 Root)
{
u32 aborted_temp = 0; // 2024-06-05
u32 Current_Length_Of_Execution_Trace = 0;
while (aborted_temp == 0) // 2024-06-05
{
u32 EIP = (*slave_state)->EIP; // Save EIP of this instruction
DebugStep(*master_state, *slave_state, *decoded); // Execute it
if (EIP > Last_Address_Of_Operating_System()) // Ignore OS code
{
PushBack(**execution_trace, (u32)*decoded,
sizeof(Decoded_Line_Of_Code));
}
if (EIP == code_end)
return 1;
if (Root) // Master UTM halt decider
{
u32* address = (u32*)**execution_trace;
u32 size = (u32)*(address-1);
// Detects slave appended an instruction to its execution_trace
if (size > Current_Length_Of_Execution_Trace)
{
Current_Length_Of_Execution_Trace = size;
aborted_temp = // 2024-06-05
Needs_To_Be_Aborted_HH
((Decoded_Line_Of_Code*)**execution_trace);
}
}
}
if (aborted_temp == 1) // 2021-01-26 Must be aborted
return 0;
return 1; // 2021-01-26 Need not be aborted
}
Am Fri, 26 Jul 2024 10:56:55 -0500 schrieb olcott:
This is meant for Mike, Joes and Fred don't have the technicalFuck you too.
competence to understand it.
Mike: It seems that HHH has been a pure function of its inputs and neverThe indirectly called HHH's most certainly make a decision.
has provided data downward to its slaves that corrupts their halt status
decision. They don't even make a halt status decision thus cannot make a
corrupted one.
I could change the code so that the slave instances can and do try toThat's kinda the point.
form a halt status decision on the basis of the execution trace that
they do have.
There is no sense in doing that because they can't possibly have enough
data, they will always be one whole execution trace behind the next
outer instance of HHH.
u32 Decide_Halting_HH(u32** Aborted,
u32** execution_trace,
Decoded_Line_Of_Code** decoded,
u32 code_end,
u32 End_Of_Code, Registers**
master_state, Registers**
slave_state, u32** slave_stack,
u32 Root)
{
u32 aborted_temp = 0; // 2024-06-05 u32
Current_Length_Of_Execution_Trace = 0;
while (aborted_temp == 0) // 2024-06-05 {
if (Root) // Master UTM halt decider {There it is.
Where is this passed from?
if (aborted_temp == 1) // 2021-01-26 Must be aborted
return 0;
return 1; // 2021-01-26 Need not be aborted
}
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
I could change the code so that the slave instances can and do
try to form a halt status decision on the basis of the execution
trace that they do have.
There is no sense in doing that because they can't possibly have
enough data, they will always be one whole execution trace behind
the next outer instance of HHH.
As they are the slaves perform their proper function of showing
the actual behavior of DDD correctly emulated by HHH.
u32 Decide_Halting_HH(u32**Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Aborted,
                     u32**                  execution_trace,
                     Decoded_Line_Of_Code** decoded,
                     u32                    code_end,
                     u32                    End_Of_Code,
                     Registers**            master_state,
                     Registers**            slave_state,
                     u32**                  slave_stack,
                     u32                    Root)
{
 u32 aborted_temp = 0; // 2024-06-05
 u32 Current_Length_Of_Execution_Trace = 0;
 while (aborted_temp == 0) // 2024-06-05
 {
   u32 EIP = (*slave_state)->EIP; // Save EIP of this instruction
   DebugStep(*master_state, *slave_state, *decoded); // Execute it
   if (EIP > Last_Address_Of_Operating_System())    // Ignore OS code
   {
     PushBack(**execution_trace, (u32)*decoded,
              sizeof(Decoded_Line_Of_Code));
   }
   if (EIP == code_end)
     return 1;
   if (Root) // Master UTM halt decider
   {
     u32* address = (u32*)**execution_trace;
     u32 size = (u32)*(address-1);
     // Detects slave appended an instruction to its execution_trace
     if (size > Current_Length_Of_Execution_Trace)
     {
       Current_Length_Of_Execution_Trace = size;
       aborted_temp =    // 2024-06-05
       Needs_To_Be_Aborted_HH
       ((Decoded_Line_Of_Code*)**execution_trace);
     }
   }
 }
 if (aborted_temp == 1) // 2021-01-26 Must be aborted
   return 0;
 return 1;          // 2021-01-26 Need not be aborted
}
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH effectively
uses the static mutable data to pass flags to the inner HHH that modify
its behaviour. The Root flag below is derived from the actual static
data and causes inner HHH to totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for various
reasons, because whatever mistakes you are making, what finally gets
printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
The problem with this attitude is that when you describe your ideas and
present the printed output, you say that HHH is "simulating" DDD, and
people know what simulating means, and everyone has expectations of
what that implies. You are happy to use those expectations when it
goes along with what you want to claim, but try to conceal that those
expectations are unjustified because what you are doing is not "proper
simulation" as everybody would understand it.
It does not have any effect on the simulation. It only gets
the non-halting results that we can all see is correct in an
impure way. Each instruction of DDD is emulated precisely
according to the semantics that it specifies.
You can't have it both ways.
It may seem that way if you are not paying close enough attention
or have insufficient skill with the semantics of the x86 language.
The way to avoid all such concerns is to implement simulation
correctly, like you claim to have done. Simulation is not /just/ the
step by step simulation provided by libx86emu(sp?) -
Yes it is. That *is* what simulation is.
The only thing that is added to this is termination analysis that
can be verified as correct even if this correct result was not
derived in a pure way.
your entire computation environment needs to correctly work together so
that the end-to-end effect is that simulated code exactly follows the
behaviour of the original code, at least up to the point where the
simulator aborts.
It has done that for three years and you never bothered to pay
enough attention to notice that it has done that for three years.
Put differently, you also need to simulate the /correct/ instructions and data.
The instructions *are* the data. A sequence of these instructions
(execution trace) is all that the termination analyzer uses.
The same applies to when you try to "copy" code,
I don't try to copy code. libx86emu gets confused with
copied code.
as in your H1 and HHH1:Â by definition of "copy" [as understood by
everybody here] the behaviour of the copied code must exactly match
that of the original code - otherwise it is simply not a proper "copy"
by definition.
There is no copy. It is always the exact same integer
machine address of DDD.
Why do you insist on saying the the emulation of DDD by HHH
is incorrect when it is an easily verified fact that HHH
emulates each instruction of DDD exactly according to the
semantics specified by this instruction.
Every time that anyone every said that the simulation was
incorrect I dared them to point to the line of code that
was simulated incorrectly and they responded with rhetoric,
ad hominem, and double talk and never pointed out any
instruction that was emulated incorrectly.
These tactics may seem convincing to gullible fools yet are
as obvious as a pie-in-the-face to those having enormously
much more single-minded focus of attention.
As a joke alternative you could stop claiming to simulate or copy
anything, and say instead you are misulating and pocying code! You
could say "HHH misulates DDD and sees that DDD will never halt" but
obviously people will just say "What's misulating, and why should
misulating (whatever it is) allow HHH to see things about DDD?"Â You
see - from your perspective that would be hopeless for your wider scope
argument which attempts to invalidate the Linz/Sipser proofs.Â
Similarly if you claim that you "pocyed" HHH to HHH1 and they have
different results when given input DDD, people will just look blank -
what's "pocying" and why would anyone expect a pocyed routine to give
the same result as the original routine?
No, none of that flies. It was a joke, but with a sensible aim - to
convince you that for your wider scale arguments you need simulating
(and copying) to have their correct meanings as everybody here will
understand them. No good saying "they mean something else, but it
doesn't matter because what my program finally writes out is TRUE".
Of course none of that will convince you of anything and you'll just continue.
Your concept of master/slaves simulators is broken. There are
I could change the code so that the slave instances can and do
try to form a halt status decision on the basis of the execution
trace that they do have.
outer/inner simulators but that is just a relative term, and all
simulated code (at whatever level) needs to have the same behaviour as
the unsimulated code.
If your simulation was correctly designed/implemented this would just
work. (Of course, HHH has to correctly use the DebugStep() (et al.)
primitive ops to gather what it needs to make its decision, no cheating
with globals etc..)
That you disagree that the simulation is correct without being
able to point out a single line-of-code of DDD that was simulated
incorrectly seems to indicate that you are happy to directly
contradict verified facts.
I know you've said you don't have time to think about how to do this
correctly. That's fair enough, but in the meantime you should not
claim that your incorrect implementation proves your conclusions!
Anyone having sufficient knowledge of the x86 language can verify
the only two relevant details:
DDD is correctly emulated by HHH until it correctly determines
that DDD specifies not halting behavior that must be aborted.
 To be fair, you shouldn't need x86utm.exe in your arguments - it is
not the Appeal To Authority that you imagine it to be! All of your
arguments could just be phrased in pseudo-code and there would not be
any disagreement about how that would behave by posters here. Of
course, your ideas expressed that way would still be Wrong, and nobody
would agree with them, but that's the case anyway when you try to bring
in x86utm!
That you disagree that the simulation is correct without being
able to point out a single line-of-code of DDD that was simulated
incorrectly seems to indicate that you are happy to directly
contradict verified facts.
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for various
reasons, because whatever mistakes you are making, what finally gets
printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way.
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
On 7/27/2024 3:36 AM, Fred. Zwarts wrote:
Op 26.jul.2024 om 17:56 schreef olcott:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
I have pity with you,
I am not the one that stupidly believes that a non-terminating
input must be emulated to non-existent completion or the emulation
is wrong.
That the first HHH to see the non-halting behavior pattern must
abort or none of them abort is simply too difficult for you.
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for various
reasons, because whatever mistakes you are making, what finally gets
printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for various
reasons, because whatever mistakes you are making, what finally gets
printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
On 7/27/2024 9:17 AM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for
various reasons, because whatever mistakes you are making, what
finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
In a similar way we can create an HHH that is able to reach the return
of DDD.
Any emulation of DDD by HHH such that DDD reaches its return
instruction is an incorrect emulation.
On 7/27/2024 9:17 AM, Fred. Zwarts wrote:That would mean the unemulated DDD doesn't return.
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:If HHH gets the correct answer in an impure way then it only counts
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is stuck >>>>> in rebuttal mode makes any understanding that he may have utterly
useless.
Mike: It seems that HHH has been a pure function of its inputs and
never has provided data downward to its slaves that corrupts their
halt status decision. They don't even make a halt status decision
thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for
various reasons, because whatever mistakes you are making, what
finally gets printed out is saying the right thing!
that it gets it in an impure way if it is impossible to get in a pure
way. This makes it possible for HHH to get this answer in a pure way:
In a similar way we can create an HHH that is able to reach the returnAny emulation of DDD by HHH such that DDD reaches its return instruction
of DDD.
is an incorrect emulation.
On 7/27/2024 9:23 AM, Fred. Zwarts wrote:
Op 27.jul.2024 om 15:48 schreef olcott:
On 7/27/2024 3:36 AM, Fred. Zwarts wrote:
Op 26.jul.2024 om 17:56 schreef olcott:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
I have pity with you,
I am not the one that stupidly believes that a non-terminating
input must be emulated to non-existent completion or the emulation
is wrong.
(That is something I never said, but it seems too difficult for you.)
You are the one that believes that the simulation of a halting program
must be aborted to prevent non-halting. Ha ha.
That the first HHH to see the non-halting behavior pattern must
abort or none of them abort is simply too difficult for you.
That two recursions is not equal to an infinite recursion is already
too difficult for you.
Two recursions with no conditional branch instructions
inbetween *IS* the correct non-halt status criteria.
On 7/27/2024 3:09 AM, Mikko wrote:
On 2024-07-26 20:14:07 +0000, olcott said:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for
various reasons, because whatever mistakes you are making, what
finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
The problem with this attitude is that when you describe your ideas
and present the printed output, you say that HHH is "simulating"
DDD, and people know what simulating means, and everyone has
expectations of what that implies. You are happy to use those
expectations when it goes along with what you want to claim, but try
to conceal that those expectations are unjustified because what you
are doing is not "proper simulation" as everybody would understand it. >>>>
It does not have any effect on the simulation. It only gets
the non-halting results that we can all see is correct in an
impure way. Each instruction of DDD is emulated precisely
according to the semantics that it specifies.
You can't have it both ways.
It may seem that way if you are not paying close enough attention
or have insufficient skill with the semantics of the x86 language.
The way to avoid all such concerns is to implement simulation
correctly, like you claim to have done. Simulation is not /just/
the step by step simulation provided by libx86emu(sp?) -
Yes it is. That *is* what simulation is.
The only thing that is added to this is termination analysis that
can be verified as correct even if this correct result was not
derived in a pure way.
your entire computation environment needs to correctly work together
so that the end-to-end effect is that simulated code exactly follows
the behaviour of the original code, at least up to the point where
the simulator aborts.
It has done that for three years and you never bothered to pay
enough attention to notice that it has done that for three years.
Put differently, you also need to simulate the /correct/
instructions and data.
The instructions *are* the data. A sequence of these instructions
(execution trace) is all that the termination analyzer uses.
The same applies to when you try to "copy" code,
I don't try to copy code. libx86emu gets confused with
copied code.
as in your H1 and HHH1:Â by definition of "copy" [as understood by
everybody here] the behaviour of the copied code must exactly match
that of the original code - otherwise it is simply not a proper
"copy" by definition.
There is no copy. It is always the exact same integer
machine address of DDD.
Why do you insist on saying the the emulation of DDD by HHH
is incorrect when it is an easily verified fact that HHH
emulates each instruction of DDD exactly according to the
semantics specified by this instruction.
Every time that anyone every said that the simulation was
incorrect I dared them to point to the line of code that
was simulated incorrectly and they responded with rhetoric,
ad hominem, and double talk and never pointed out any
instruction that was emulated incorrectly.
These tactics may seem convincing to gullible fools yet are
as obvious as a pie-in-the-face to those having enormously
much more single-minded focus of attention.
As a joke alternative you could stop claiming to simulate or copy
anything, and say instead you are misulating and pocying code! You
could say "HHH misulates DDD and sees that DDD will never halt" but
obviously people will just say "What's misulating, and why should
misulating (whatever it is) allow HHH to see things about DDD?"Â You
see - from your perspective that would be hopeless for your wider
scope argument which attempts to invalidate the Linz/Sipser proofs.
Similarly if you claim that you "pocyed" HHH to HHH1 and they have
different results when given input DDD, people will just look blank
- what's "pocying" and why would anyone expect a pocyed routine to
give the same result as the original routine?
No, none of that flies. It was a joke, but with a sensible aim - to
convince you that for your wider scale arguments you need simulating
(and copying) to have their correct meanings as everybody here will
understand them. No good saying "they mean something else, but it
doesn't matter because what my program finally writes out is TRUE".
Of course none of that will convince you of anything and you'll just
continue.
Your concept of master/slaves simulators is broken. There are
I could change the code so that the slave instances can and do
try to form a halt status decision on the basis of the execution
trace that they do have.
outer/inner simulators but that is just a relative term, and all
simulated code (at whatever level) needs to have the same behaviour
as the unsimulated code.
If your simulation was correctly designed/implemented this would
just work. (Of course, HHH has to correctly use the DebugStep() (et
al.) primitive ops to gather what it needs to make its decision, no
cheating with globals etc..)
That you disagree that the simulation is correct without being
able to point out a single line-of-code of DDD that was simulated
incorrectly seems to indicate that you are happy to directly
contradict verified facts.
I know you've said you don't have time to think about how to do this
correctly. That's fair enough, but in the meantime you should not
claim that your incorrect implementation proves your conclusions!
Anyone having sufficient knowledge of the x86 language can verify
the only two relevant details:
DDD is correctly emulated by HHH until it correctly determines
that DDD specifies not halting behavior that must be aborted.
 To be fair, you shouldn't need x86utm.exe in your arguments - it is
not the Appeal To Authority that you imagine it to be! All of your
arguments could just be phrased in pseudo-code and there would not
be any disagreement about how that would behave by posters here. Of
course, your ideas expressed that way would still be Wrong, and
nobody would agree with them, but that's the case anyway when you
try to bring in x86utm!
That you disagree that the simulation is correct without being
able to point out a single line-of-code of DDD that was simulated
incorrectly seems to indicate that you are happy to directly
contradict verified facts.
No, it is not. A virifiable fact is that you have not proven what you
clain.
I claim that DDD is correctly emulated by HHH and when people
say it is emulated incorrectly they only can provide double-talk and misdirection when asked which instruction was emulated incorrectly.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Thinking that the simulation by a termination analyzer that is required
to halt is incorrect when non-terminating inputs are not simulated to
their non-existent end is even more stupid.
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for
various reasons, because whatever mistakes you are making, what
finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
Mike Terry is right that a simulator has access to the internal state
of the simulated machine, but he did not say that it is correct to
*change in this way* the state of the simulated machine.
Changing the state of the simulated machine is cheating.
I know this and agree with him on this.
Of course a simulator can modify the input before of during the
simulation.
No that is cheating too.
It can change instructions, it can change the value of variable (such
as Root).
However, it is clear that when it simulates a modified input, it is no
longer simulating its input.
This is what happens when the simulator changes the value of Root. It
changes the (hidden) input of the simulated machine, so that the
simulator does no longer simulate the input, but something else.
It is a verified fact that HHH get the correct halt
status decision in that HHH exactly matched that same
behavior pattern as this:
void Infinite_Recursion()
{
 Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55Â Â Â Â Â Â Â Â push ebp
[0000215b] 8bec      mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 Decide_Halting_HH:1
[0000215a][00113924][00113928] 55        push ebp [0000215b][00113924][00113928] 8bec      mov ebp,esp [0000215d][00113920][00002162] e8f8ffffff call 0000215a [0000215a][0011391c][00113924] 55        push ebp [0000215b][0011391c][00113924] 8bec      mov ebp,esp [0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is
no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
The key difference between a partial decider and a decider is that
the former case only needs to get at least one input correctly.
An aborted C program certainly doesn't correspond with a running
turing machine - so it must be a halted turing machine.
If you take the view all all new ideas are inherently incorrect
then you would be right within this false assumption.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
You seem to have the above false assumption.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/27/2024 4:16 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 3:20 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>>>>> This is not the same as reaching its ret instruction and terminating >>>>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in
for turing machines. A turing machine is either running or
halted. There is no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
Where does the notion of "aborted", as being distinct from halted, come >>>> from?
After all of these years and you don't get that?
"Aborted" being distinct from halted is an incoherent notion. It isn't
consistent with turing machines. I was hoping you could give a
justification for it.
A simulating partial halt decider can stop simulating
its input when it detects a non-halting behavior pattern.
This does not count as the input halting.
Says who? Well, OK, it would be the machine halting, not the input, but
that's a small point.
void Infinite_Recursion()
{
Infinite_Recursion();
}
Do you understand that HHH(Infinite_Recursion) correctly
implements this criteria for the above input?
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If you can't understand that Infinite_Recursion() doesn't
halt then you don't know the subject matter nearly well enough.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/27/2024 3:20 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>>> This is not the same as reaching its ret instruction and terminating >>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is >>>> no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
Where does the notion of "aborted", as being distinct from halted, come
from?
After all of these years and you don't get that?
A simulating partial halt decider can stop simulating
its input when it detects a non-halting behavior pattern.
This does not count as the input halting.
The key difference between a partial decider and a decider is that
the former case only needs to get at least one input correctly.
That doesn't seem to have anything to do with my point.
*This is indirectly related to your above question*
A decider must be all knowing it is not allowed to get one
input incorrectly. A partial halt decider is only required
to get at least one input correctly.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/27/2024 9:17 AM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the inner
HHH that modify its behaviour. The Root flag below is derived from
the actual static data and causes inner HHH to totally skip its own
abort logic!
You seem to acknowledge this, but claim it does not matter for
various reasons, because whatever mistakes you are making, what
finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
In a similar way we can create an HHH that is able to reach the return
of DDD.
Any emulation of DDD by HHH such that DDD reaches its return
instruction is an incorrect emulation.
On 7/27/2024 4:45 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 4:16 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 3:20 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting. DDD emulated by >>>>>>>>> HHH stops running when its emulation has been aborted. This is >>>>>>>>> not the same as reaching its ret instruction and terminating >>>>>>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in >>>>>>>> for turing machines. A turing machine is either running or
halted. There is no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
Where does the notion of "aborted", as being distinct from halted, come >>>>>> from?
After all of these years and you don't get that?
"Aborted" being distinct from halted is an incoherent notion. It isn't >>>> consistent with turing machines. I was hoping you could give a
justification for it.
A simulating partial halt decider can stop simulating
its input when it detects a non-halting behavior pattern.
This does not count as the input halting.
Says who? Well, OK, it would be the machine halting, not the input, but >>>> that's a small point.
void Infinite_Recursion()
{
Infinite_Recursion();
}
[ .... ]
Do you understand that HHH(Infinite_Recursion) correctly
implements this criteria for the above input?
There's nothing wrong with my understanding, but I'm not sure what
"implementing a criterion (not "criteria")" means,
HHH correctly simulates Infinite_Recursion until it correctly
detects a the non-halting behavior pattern that every programmer
can see.
You dodged the question about whether you can see this
non-halting behavior pattern on the basis of this x86 code:
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 7/27/2024 5:23 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 4:45 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 4:16 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 3:20 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting. DDD emulated by >>>>>>>>>>> HHH stops running when its emulation has been aborted. This is >>>>>>>>>>> not the same as reaching its ret instruction and terminating >>>>>>>>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in >>>>>>>>>> for turing machines. A turing machine is either running or >>>>>>>>>> halted. There is no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt >>>>>>>>> decider.
Where does the notion of "aborted", as being distinct from
halted, come
from?
After all of these years and you don't get that?
"Aborted" being distinct from halted is an incoherent notion. It >>>>>> isn't
consistent with turing machines. I was hoping you could give a
justification for it.
A simulating partial halt decider can stop simulating
its input when it detects a non-halting behavior pattern.
This does not count as the input halting.
Says who? Well, OK, it would be the machine halting, not the
input, but
that's a small point.
void Infinite_Recursion()
{
   Infinite_Recursion();
}
[ .... ]
Do you understand that HHH(Infinite_Recursion) correctly
implements this criteria for the above input?
There's nothing wrong with my understanding, but I'm not sure what
"implementing a criterion (not "criteria")" means,
[ .... ]
HHH correctly simulates Infinite_Recursion until it correctly
detects a the non-halting behavior pattern that every programmer
can see.
You dodged the question about whether you can see this
non-halting behavior pattern on the basis of this x86 code:
It was an incoherent question. What on Earth does "implementing a
criterion" even mean? But I told you there's nothing amiss with my
understanding.
*Implementing the Sipser approved criterion measure means*
 that HHH simulates Infinite_Recursion until it sees that
 Infinite_Recursion cannot possibly halt.
*Implementing the Sipser approved criterion measure means*
 that HHH simulates Infinite_Recursion until it sees that
 Infinite_Recursion cannot possibly halt.
*Implementing the Sipser approved criterion measure means*
 that HHH simulates Infinite_Recursion until it sees that
 Infinite_Recursion cannot possibly halt.
*Then HHH stops simulating Infinite_Recursion*
 When HHH stops simulating Infinite_Recursion HHH has
 aborted its simulation of Infinite_Recursion.
*Then HHH stops simulating Infinite_Recursion*
 When HHH stops simulating Infinite_Recursion HHH has
 aborted its simulation of Infinite_Recursion.
*Then HHH stops simulating Infinite_Recursion*
 When HHH stops simulating Infinite_Recursion HHH has
 aborted its simulation of Infinite_Recursion.
Op 27.jul.2024 om 16:34 schreef olcott:
On 7/27/2024 9:23 AM, Fred. Zwarts wrote:
Op 27.jul.2024 om 15:48 schreef olcott:
On 7/27/2024 3:36 AM, Fred. Zwarts wrote:
Op 26.jul.2024 om 17:56 schreef olcott:
This is meant for Mike, Joes and Fred don't have the technical competence to understand it.
I have pity with you,
I am not the one that stupidly believes that a non-terminating
input must be emulated to non-existent completion or the emulation
is wrong.
(That is something I never said, but it seems too difficult for you.)
You are the one that believes that the simulation of a halting program must be aborted to prevent
non-halting. Ha ha.
That the first HHH to see the non-halting behavior pattern must
abort or none of them abort is simply too difficult for you.
That two recursions is not equal to an infinite recursion is already too difficult for you.
Two recursions with no conditional branch instructions
inbetween *IS* the correct non-halt status criteria.
Are you really so stupid to think that HHH has no branch instructions?
HHH is a halting program. So, when DDD calls HHH, we know that DDD also halts. It is clear that DDD
is a misleading and unneeded complication. It is easy to eliminate DDD:
int main() {
return HHH(main);
}
This has the same problem. This proves that the problem is not in DDD, but in HHH, which halts when
it aborts the simulation, but it decides that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.
HHH is simply unable to decide about comparable finite recursions.
void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}
It decides after two recursions that there is an infinite recursion, which is incorrect.
Two differs from infinite!
On 27/07/2024 19:14, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is >> no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing
machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
Aborting is an action performed by a simulator, not the TM being simulated.
If we want to count "aborted" as some kind of final status, it will have
to be the status of a specific /PARTIAL SIMULATOR's/ simulation of a
given computation. That's not a property of the computation itself, as different partial simulators can simulate the same computation and
terminate for different reasons. Like HHH(DDD) aborts, while UTM(DDD) simulates to completion and so the final simulation status is halts.
[Neither of those outcomes contradict the fact that the computation
DDD() halts.]
If some partial simulator halts when simulating a computation [as with UTM(DDD)] that implies the computation DDD() halts. But if the
simulator aborts, it doesn't say that much (in and of itself) about
whether the /computation/ halts. The halting problem statement is not concerned with simulations or how the simulations end.
Every time anyone in these PO threads says "halts" it ought to be 100%
clear to everyone whether the computation itself is being discussed, or whether some simulation final status is intended. (But that's far from being the case!) Since the halting problem is concerned with
computations halting and not how partial simulations are ended, I
suggest that PO explicitly make clear that he is referring to
simulations, whenever that is the case. It seems reasonable that
readers seeing "halts" with no further clarification can interpret that
as actual computation behaviour, as that is how the term is always used
in the literature. Same with other terms like "reach"...
So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined mathematically], or its simulation by HHH? He means the latter, but its
far from clear, I'd say! [I think most readers now have come around to reading it as a statement about simulations rather than the actual computation, which totally changes things...]
Mike.
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is
no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
On 7/27/2024 7:40 PM, Mike Terry wrote:
On 27/07/2024 19:14, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>> This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted.
There is
no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing >>> machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
Aborting is an action performed by a simulator, not the TM being
simulated.
If we want to count "aborted" as some kind of final status, it will
have to be the status of a specific /PARTIAL SIMULATOR's/ simulation
of a given computation. That's not a property of the computation
itself, as different partial simulators can simulate the same
computation and terminate for different reasons. Like HHH(DDD)
aborts, while UTM(DDD) simulates to completion and so the final
simulation status is halts. [Neither of those outcomes contradict the
fact that the computation DDD() halts.]
If some partial simulator halts when simulating a computation [as with
UTM(DDD)] that implies the computation DDD() halts. But if the
simulator aborts, it doesn't say that much (in and of itself) about
whether the /computation/ halts. The halting problem statement is not
concerned with simulations or how the simulations end.
Every time anyone in these PO threads says "halts" it ought to be 100%
clear to everyone whether the computation itself is being discussed,
or whether some simulation final status is intended. (But that's far
from being the case!)Â Since the halting problem is concerned with
computations halting and not how partial simulations are ended, I
suggest that PO explicitly make clear that he is referring to
simulations, whenever that is the case. It seems reasonable that
readers seeing "halts" with no further clarification can interpret
that as actual computation behaviour, as that is how the term is
always used in the literature. Same with other terms like "reach"...
So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined
mathematically], or its simulation by HHH? He means the latter, but
its far from clear, I'd say! [I think most readers now have come
around to reading it as a statement about simulations rather than the
actual computation, which totally changes things...]
Mike.
_DDD()
[00002163] 55        push ebp     ; housekeeping
[00002164] 8bec      mov ebp,esp  ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404Â Â Â Â add esp,+04
[00002173] 5d        pop ebp
[00002174] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002174]
It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.
*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.
On 7/27/2024 2:55 PM, Fred. Zwarts wrote:
Op 27.jul.2024 om 21:27 schreef olcott:
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts >>>>>>> their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the
inner HHH that modify its behaviour. The Root flag below is
derived from the actual static data and causes inner HHH to
totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for
various reasons, because whatever mistakes you are making, what
finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there. >>>>>
Mike Terry is right that a simulator has access to the internal
state of the simulated machine, but he did not say that it is
correct to *change in this way* the state of the simulated machine.
Changing the state of the simulated machine is cheating.
I know this and agree with him on this.
Of course a simulator can modify the input before of during the
simulation.
No that is cheating too.
That is exactly what you do when you change the value of the variable
'Root'. 'Root' is a hidden input for HHH.
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
That you don't know this conclusively proves that you
don't have sufficient understanding of the x86 language.
All of the issues that Mike bought up have nothing to
do with correct emulation. They only pertain to how
the halt status decision is derived.
That the halt status decision is proven to be correct
on the basis that its behavior pattern exactly matches
this infinite recursion behavior pattern is proven.
void Infinite_Recursion()
{
 Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55Â Â Â Â Â Â Â Â push ebp
[0000215b] 8bec      mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 [0000215a][00113924][00113928] 55        push ebp [0000215b][00113924][00113928] 8bec      mov ebp,esp [0000215d][00113920][00002162] e8f8ffffff call 0000215a [0000215a][0011391c][00113924] 55        push ebp [0000215b][0011391c][00113924] 8bec      mov ebp,esp [0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 7/27/2024 7:40 PM, Mike Terry wrote:
On 27/07/2024 19:14, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>> This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted.
There is
no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing >>> machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
Aborting is an action performed by a simulator, not the TM being
simulated.
If we want to count "aborted" as some kind of final status, it will
have to be the status of a specific /PARTIAL SIMULATOR's/ simulation
of a given computation. That's not a property of the computation
itself, as different partial simulators can simulate the same
computation and terminate for different reasons. Like HHH(DDD)
aborts, while UTM(DDD) simulates to completion and so the final
simulation status is halts. [Neither of those outcomes contradict the
fact that the computation DDD() halts.]
If some partial simulator halts when simulating a computation [as with
UTM(DDD)] that implies the computation DDD() halts. But if the
simulator aborts, it doesn't say that much (in and of itself) about
whether the /computation/ halts. The halting problem statement is not
concerned with simulations or how the simulations end.
Every time anyone in these PO threads says "halts" it ought to be 100%
clear to everyone whether the computation itself is being discussed,
or whether some simulation final status is intended. (But that's far
from being the case!)Â Since the halting problem is concerned with
computations halting and not how partial simulations are ended, I
suggest that PO explicitly make clear that he is referring to
simulations, whenever that is the case. It seems reasonable that
readers seeing "halts" with no further clarification can interpret
that as actual computation behaviour, as that is how the term is
always used in the literature. Same with other terms like "reach"...
So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined
mathematically], or its simulation by HHH? He means the latter, but
its far from clear, I'd say! [I think most readers now have come
around to reading it as a statement about simulations rather than the
actual computation, which totally changes things...]
Mike.
_DDD()
[00002163] 55        push ebp     ; housekeeping
[00002164] 8bec      mov ebp,esp  ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404Â Â Â Â add esp,+04
[00002173] 5d        pop ebp
[00002174] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002174]
It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.
*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH effectively >>>> uses the static mutable data to pass flags to the inner HHH that modify >>>> its behaviour. The Root flag below is derived from the actual static >>>> data and causes inner HHH to totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for various >>>> reasons, because whatever mistakes you are making, what finally gets
printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there.
Mike Terry is right that a simulator has access to the internal state
of the simulated machine, but he did not say that it is correct to
*change in this way* the state of the simulated machine.
Changing the state of the simulated machine is cheating.
I know this and agree with him on this.
Of course a simulator can modify the input before of during the simulation.
No that is cheating too.
It can change instructions, it can change the value of variable (such as Root).
However, it is clear that when it simulates a modified input, it is no
longer simulating its input.
This is what happens when the simulator changes the value of Root. It
changes the (hidden) input of the simulated machine, so that the
simulator does no longer simulate the input, but something else.
It is a verified fact that HHH get the correct halt
status decision in that HHH exactly matched that same
behavior pattern as this:
On 7/27/2024 2:55 PM, Fred. Zwarts wrote:
Op 27.jul.2024 om 21:27 schreef olcott:
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts >>>>>>> their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH effectively >>>>>> uses the static mutable data to pass flags to the inner HHH that modify >>>>>> its behaviour. The Root flag below is derived from the actual static >>>>>> data and causes inner HHH to totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for various >>>>>> reasons, because whatever mistakes you are making, what finally gets >>>>>> printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there. >>>>>
Mike Terry is right that a simulator has access to the internal state
of the simulated machine, but he did not say that it is correct to
*change in this way* the state of the simulated machine.
Changing the state of the simulated machine is cheating.
I know this and agree with him on this.
Of course a simulator can modify the input before of during the simulation.
No that is cheating too.
That is exactly what you do when you change the value of the variable
'Root'. 'Root' is a hidden input for HHH.
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is
no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is
no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
On 27/07/2024 19:14, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is
no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing
machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
Aborting is an action performed by a simulator, not the TM being simulated.
If we want to count "aborted" as some kind of final status, it will
have to be the status of a specific /PARTIAL SIMULATOR's/ simulation of
a given computation. That's not a property of the computation itself,
as different partial simulators can simulate the same computation and terminate for different reasons. Like HHH(DDD) aborts, while UTM(DDD) simulates to completion and so the final simulation status is halts.
[Neither of those outcomes contradict the fact that the computation
DDD() halts.]
If some partial simulator halts when simulating a computation [as with UTM(DDD)] that implies the computation DDD() halts. But if the
simulator aborts, it doesn't say that much (in and of itself) about
whether the /computation/ halts. The halting problem statement is not concerned with simulations or how the simulations end.
Every time anyone in these PO threads says "halts" it ought to be 100%
clear to everyone whether the computation itself is being discussed, or whether some simulation final status is intended. (But that's far from
being the case!) Since the halting problem is concerned with
computations halting and not how partial simulations are ended, I
suggest that PO explicitly make clear that he is referring to
simulations, whenever that is the case. It seems reasonable that
readers seeing "halts" with no further clarification can interpret that
as actual computation behaviour, as that is how the term is always used
in the literature. Same with other terms like "reach"...
So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined mathematically], or its simulation by HHH? He means the latter, but
its far from clear, I'd say! [I think most readers now have come
around to reading it as a statement about simulations rather than the
actual computation, which totally changes things...]
Mike.
On 7/28/2024 2:50 AM, Fred. Zwarts wrote:
Op 27.jul.2024 om 22:05 schreef olcott:
On 7/27/2024 2:55 PM, Fred. Zwarts wrote:
Op 27.jul.2024 om 21:27 schreef olcott:
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical >>>>>>>>> competence to understand it.
Richard might be able to understand it yet the fact that he is >>>>>>>>> stuck in rebuttal mode makes any understanding that he may have >>>>>>>>> utterly useless.
Mike: It seems that HHH has been a pure function of its inputs >>>>>>>>> and never has provided data downward to its slaves that corrupts >>>>>>>>> their halt status decision. They don't even make a halt status >>>>>>>>> decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the
inner HHH that modify its behaviour. The Root flag below is
derived from the actual static data and causes inner HHH to
totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for >>>>>>>> various reasons, because whatever mistakes you are making, what >>>>>>>> finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there. >>>>>>>
Mike Terry is right that a simulator has access to the internal
state of the simulated machine, but he did not say that it is
correct to *change in this way* the state of the simulated machine. >>>>>> Changing the state of the simulated machine is cheating.
I know this and agree with him on this.
Of course a simulator can modify the input before of during the
simulation.
No that is cheating too.
That is exactly what you do when you change the value of the
variable 'Root'. 'Root' is a hidden input for HHH.
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you understood only a little bit of x86, you would know that
changing the value of a variable (like Root), will modify the
behaviour of a program, making a cheating simulator.
I have been programming in the x86 language since it was new.
I commented the whole block of code out that does the abort
so that HHH is just a simulator and not a termination analyzer
and it just keeps on running until the instruction limited of
50,000,000 instructions have been emulated. Every recursive
emulation take about 100-fold more steps than the prior one.
_DDD()
[00002137] 55Â Â Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002138] 8bec            mov ebp,esp
[0000213a] 6837210000Â Â Â Â Â Â push 00002137
[0000213f] e853f4ffff      call 00001597
[00002144] 83c404Â Â Â Â Â Â Â Â Â Â add esp,+04
[00002147] 5d              pop ebp
[00002148] c3Â Â Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002148]
_main()
[00002157] 55Â Â Â Â Â Â Â Â Â Â Â Â Â Â push ebp
[00002158] 8bec            mov ebp,esp
[0000215a] e8d8ffffff      call 00002137
[0000215f] 33c0Â Â Â Â Â Â Â Â Â Â Â Â xor eax,eax
[00002161] 5d              pop ebp
[00002162] c3Â Â Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0012) [00002162]
 machine  stack    stack    machine   assembly
 address  address  data     code      language
 ======== ======== ======== ========= ============= [00002157][0010379f][00000000] 55              push ebp [00002158][0010379f][00000000] 8bec            mov ebp,esp [0000215a][0010379b][0000215f] e8d8ffffff      call 00002137 [00002137][00103797][0010379f] 55              push ebp [00002138][00103797][0010379f] 8bec            mov ebp,esp [0000213a][00103793][00002137] 6837210000      push 00002137 [0000213f][0010378f][00002144] e853f4ffff      call 00001597
New slave_stack at:103843
Begin Local Halt Decider Simulation  Execution Trace Stored at:11384b [00002137][0011383b][0011383f] 55              push ebp [00002138][0011383b][0011383f] 8bec            mov ebp,esp [0000213a][00113837][00002137] 6837210000      push 00002137 [0000213f][00113833][00002144] e853f4ffff      call 00001597
New slave_stack at:14e26b
[00002137][0015e263][0015e267] 55              push ebp [00002138][0015e263][0015e267] 8bec            mov ebp,esp [0000213a][0015e25f][00002137] 6837210000      push 00002137 [0000213f][0015e25b][00002144] e853f4ffff      call 00001597
New slave_stack at:15e30b
[00002137][0016e303][0016e307] 55              push ebp [00002138][0016e303][0016e307] 8bec            mov ebp,esp [0000213a][0016e2ff][00002137] 6837210000      push 00002137 [0000213f][0016e2fb][00002144] e853f4ffff      call 00001597
New slave_stack at:16e3ab
[00002137][0017e3a3][0017e3a7] 55              push ebp [00002138][0017e3a3][0017e3a7] 8bec            mov ebp,esp [0000213a][0017e39f][00002137] 6837210000      push 00002137 [0000213f][0017e39b][00002144] e853f4ffff      call 00001597
New slave_stack at:17e44b
[00002137][0018e443][0018e447] 55Â Â Â Â Â Â Â Â Â Â Â Â Â Â push ebp
Number of Instructions Executed(50000000) == 746269 Pages
That you don't know this conclusively proves that you
don't have sufficient understanding of the x86 language.
Irrelevant nonsense ignored.
All of the issues that Mike bought up have nothing to
do with correct emulation. They only pertain to how
the halt status decision is derived.
So, why do you bring up x86?
But you keep talking about a halt status. E.g. that the simulator must
abort to halt a non-halting program.
You are twisting the meaning of simulator often, as you think that
aborting is part of a simulation.
You seem to think that aborting is part of the semantics of the x86
language.
That the halt status decision is proven to be correct
on the basis that its behavior pattern exactly matches
this infinite recursion behavior pattern is proven.
void Infinite_Recursion()
{
  Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55Â Â Â Â Â Â Â Â push ebp
[0000215b] 8bec      mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 >>> [0000215a][00113924][00113928] 55        push ebp
[0000215b][00113924][00113928] 8bec      mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff call 0000215a
[0000215a][0011391c][00113924] 55Â Â Â Â Â Â Â Â push ebp
[0000215b][0011391c][00113924] 8bec      mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Proof by example fails.
That the simulation is incorrect is because HHH (and apparently its
programmer) think that a two level recursion is an infinite recursion.
HHH is simply unable to decide about comparable finite recursions.
void Finite_Recursion (int N) {
  if (N > 0) Finite_Recursion (N - 1);
}
It decides after N recursions that there is an infinite recursion,
which is incorrect.
HHH(Infinite_Recursion) sees the non-halting pattern below.
This *is* the exact same pattern that HHH(DDD) sees.
void Infinite_Recursion()
{
 Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55        push ebp     ; 1st line
[0000215b] 8bec      mov ebp,esp  ; 2nd line
[0000215d] e8f8ffffff call 0000215a ; 3rd line
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 [0000215a][00113924][00113928] 55        push ebp     ; 1st line
[0000215b][00113924][00113928] 8bec      mov ebp,esp  ; 2nd line [0000215d][00113920][00002162] e8f8ffffff call 0000215a ; 3rd line [0000215a][0011391c][00113924] 55        push ebp     ; 1st line
[0000215b][0011391c][00113924] 8bec      mov ebp,esp  ; 2nd line [0000215d][00113918][00002162] e8f8ffffff call 0000215a ; 3rd line
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
If you cannot see that the above x86 machine code proves that
it will never halt then you can't possibly understand what I
have been saying.
The first three lines of _Infinite_Recursion() repeat and there
are no conditional branch in that sequence that can possibly keep
it from repeating forever.
On 7/28/2024 2:50 AM, Fred. Zwarts wrote:
Op 27.jul.2024 om 22:05 schreef olcott:
On 7/27/2024 2:55 PM, Fred. Zwarts wrote:
Op 27.jul.2024 om 21:27 schreef olcott:
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:
This is meant for Mike, Joes and Fred don't have the technical >>>>>>>>> competence to understand it.
Richard might be able to understand it yet the fact that he is >>>>>>>>> stuck in rebuttal mode makes any understanding that he may have >>>>>>>>> utterly useless.
Mike: It seems that HHH has been a pure function of its inputs >>>>>>>>> and never has provided data downward to its slaves that corrupts >>>>>>>>> their halt status decision. They don't even make a halt status >>>>>>>>> decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the
inner HHH that modify its behaviour. The Root flag below is
derived from the actual static data and causes inner HHH to
totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for >>>>>>>> various reasons, because whatever mistakes you are making, what >>>>>>>> finally gets printed out is saying the right thing!
If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
;
Obviously a simulator has access to the internal state
(tape contents etc.) of the simulated machine. No problem there. >>>>>>>
Mike Terry is right that a simulator has access to the internal
state of the simulated machine, but he did not say that it is
correct to *change in this way* the state of the simulated machine. >>>>>> Changing the state of the simulated machine is cheating.
I know this and agree with him on this.
Of course a simulator can modify the input before of during the
simulation.
No that is cheating too.
That is exactly what you do when you change the value of the
variable 'Root'. 'Root' is a hidden input for HHH.
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you understood only a little bit of x86, you would know that
changing the value of a variable (like Root), will modify the
behaviour of a program, making a cheating simulator.
I have been programming in the x86 language since it was new.
I commented the whole block of code out that does the abort
so that HHH is just a simulator and not a termination analyzer
and it just keeps on running until the instruction limited of
50,000,000 instructions have been emulated. Every recursive
emulation take about 100-fold more steps than the prior one.
...
That the halt status decision is proven to be correct
on the basis that its behavior pattern exactly matches
this infinite recursion behavior pattern is proven.
void Infinite_Recursion()
{
  Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55Â Â Â Â Â Â Â Â push ebp
[0000215b] 8bec      mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 >>> [0000215a][00113924][00113928] 55        push ebp
[0000215b][00113924][00113928] 8bec      mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff call 0000215a
[0000215a][0011391c][00113924] 55Â Â Â Â Â Â Â Â push ebp
[0000215b][0011391c][00113924] 8bec      mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Proof by example fails.
That the simulation is incorrect is because HHH (and apparently its
programmer) think that a two level recursion is an infinite recursion.
HHH is simply unable to decide about comparable finite recursions.
void Finite_Recursion (int N) {
  if (N > 0) Finite_Recursion (N - 1);
}
It decides after N recursions that there is an infinite recursion,
which is incorrect.
HHH(Infinite_Recursion) sees the non-halting pattern below.
This *is* the exact same pattern that HHH(DDD) sees.
void Infinite_Recursion()
{
 Infinite_Recursion();
}
On 7/28/2024 2:50 AM, Fred. Zwarts wrote:It doesn't even get the answer correct.
Op 27.jul.2024 om 22:05 schreef olcott:
On 7/27/2024 2:55 PM, Fred. Zwarts wrote:
Op 27.jul.2024 om 21:27 schreef olcott:
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
On 7/26/2024 2:46 PM, Mike Terry wrote:
On 26/07/2024 16:56, olcott wrote:If HHH gets the correct answer in an impure way then it only
Mike: It seems that HHH has been a pure function of its inputs >>>>>>>>> and never has provided data downward to its slaves that corrupts >>>>>>>>> their halt status decision. They don't even make a halt status >>>>>>>>> decision thus cannot make a corrupted one.
Well, the first two claims are literally untrue - outer HHH
effectively uses the static mutable data to pass flags to the
inner HHH that modify its behaviour. The Root flag below is
derived from the actual static data and causes inner HHH to
totally skip its own abort logic!
You seem to acknowledge this, but claim it does not matter for >>>>>>>> various reasons, because whatever mistakes you are making, what >>>>>>>> finally gets printed out is saying the right thing!
counts that it gets it in an impure way if it is impossible to get >>>>>>> in a pure way. This makes it possible for HHH to get this answer >>>>>>> in a pure way:
Of course HHH can't abort its not-aborting simulation if you commentI commented the whole block of code out that does the abort so that HHHMike Terry is right that a simulator has access to the internalI know this and agree with him on this.
state of the simulated machine, but he did not say that it is
correct to *change in this way* the state of the simulated machine. >>>>>> Changing the state of the simulated machine is cheating.
Of course a simulator can modify the input before of during the
simulation.
No that is cheating too.
That is exactly what you do when you change the value of the variable
'Root'. 'Root' is a hidden input for HHH.
If you had sufficient understanding of the x86 language you would know
that DDD is correctly emulated by HHH.
If you understood only a little bit of x86, you would know that
changing the value of a variable (like Root), will modify the behaviour
of a program, making a cheating simulator.
is just a simulator and not a termination analyzer and it just keeps on running until the instruction limited of 50,000,000 instructions have
been emulated. Every recursive emulation take about 100-fold more steps
than the prior one.
No, it is not. HHH should see that HHH can abort.HHH(Infinite_Recursion) sees the non-halting pattern below.All of the issues that Mike bought up have nothing to do with correctSo, why do you bring up x86?
emulation. They only pertain to how the halt status decision is
derived.
But you keep talking about a halt status. E.g. that the simulator must
abort to halt a non-halting program.
You are twisting the meaning of simulator often, as you think that
aborting is part of a simulation.
You seem to think that aborting is part of the semantics of the x86
language.
That the halt status decision is proven to be correct on the basisProof by example fails.
that its behavior pattern exactly matches this infinite recursion
behavior pattern is proven.
That the simulation is incorrect is because HHH (and apparently its
programmer) think that a two level recursion is an infinite recursion.
HHH is simply unable to decide about comparable finite recursions.
void Finite_Recursion (int N) {
 if (N > 0) Finite_Recursion (N - 1);
}
It decides after N recursions that there is an infinite recursion,
which is incorrect.
This *is* the exact same pattern that HHH(DDD) sees.
The first three lines of _Infinite_Recursion() repeat and there are no conditional branch in that sequence that can possibly keep it fromOnly your HHH does have an (incorrectly unreachable) branch:
repeating forever.
On 7/28/2024 4:23 AM, Mikko wrote:
On 2024-07-27 18:20:19 +0000, olcott said:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>>> This is not the same as reaching its ret instruction and terminating >>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted.
There is
no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
You also need the conventional ideas of halting and halt decider.
The latter is largely a combination of the conventional ideas of
decider and halting but also involves the conventional of
prediction, so you need that, too.
Although the conventional idea of testing is not relevant to the
construction of a simulating partial halt decider it is helpful to
presentation of the
result, especially if your target audience contains software
engineers. If your target audience is mainly mathematicians the
convnetional idea of proofs is more useful because in that case most
of your presentation must be proofs.
My ideas must be anchored in fully specified running software
otherwise the false assumptions made by computer science people
remain hidden.
Even when I slap them in the face with proven facts they deny
these proven facts on the basis of their indoctrination.
Even Mike is trying to get away with saying that DDD correctly
emulated by HHH according to the semantics specified by the
machine code of DDD and the machine code of HHH when DDD calls
HHH(DDD) in recursive emulation is incorrectly emulated.
HHH(DDD) has the exact same pattern as Infinite_Recursion()
where there are no conditional branch instructions that would
prevent the first three instructions of Infinite_Recursion()
from endlessly repeating.
void Infinite_Recursion()
{
 Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55        push ebp     ; 1st line
[0000215b] 8bec      mov ebp,esp  ; 2nd line
[0000215d] e8f8ffffff call 0000215a ; 3rd line
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 [0000215a][00113924][00113928] 55        push ebp     ; 1st line
[0000215b][00113924][00113928] 8bec      mov ebp,esp  ; 2nd line [0000215d][00113920][00002162] e8f8ffffff call 0000215a ; 3rd line [0000215a][0011391c][00113924] 55        push ebp     ; 1st line
[0000215b][0011391c][00113924] 8bec      mov ebp,esp  ; 2nd line [0000215d][00113918][00002162] e8f8ffffff call 0000215a ; 3rd line
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
=====
void DDD()
{
 HHH(DDD);
}
_DDD()
[00002177] 55              push ebp     ; 1st line [00002178] 8bec            mov ebp,esp  ; 2nd line
[0000217a] 6877210000Â Â Â Â Â Â push 00002177 ; push DDD
[0000217f] e853f4ffff      call 000015d7 ; call HHH
[00002184] 83c404Â Â Â Â Â Â Â Â Â Â add esp,+04
[00002187] 5d              pop ebp
[00002188] c3Â Â Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002188]
// executed HHH emulates 1st instance of DDD
New slave_stack at:10388d
Begin Local Halt Decider Simulation  Execution Trace Stored at:113895 [00002177][00113885][00113889] 55        push ebp     ; 1st line
[00002178][00113885][00113889] 8bec      mov ebp,esp  ; 2nd line [0000217a][00113881][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011387d][00002184] e853f4ffff call 000015d7 ; call HHH
// emulated HHH emulates 2nd instance of DDD
New slave_stack at:14e2b5simulated HHH decides not to abort simulation yet.
[00002177][0015e2ad][0015e2b1] 55        push ebp     ; 1st lineaimulated HHH decides not to abort simulation yet.
[00002178][0015e2ad][0015e2b1] 8bec      mov ebp,esp  ; 2nd linesimulated HHH decides not to abort simulation yet.
[0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDDsimulatd HHH decides not to abort simulation yet.
[0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
On 7/28/2024 4:23 AM, Mikko wrote:
On 2024-07-27 18:20:19 +0000, olcott said:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>>> This is not the same as reaching its ret instruction and terminating >>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is >>>> no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider.
You also need the conventional ideas of halting and halt decider.
The latter is largely a combination of the conventional ideas of
decider and halting but also involves the conventional of
prediction, so you need that, too.
Although the conventional idea of testing is not relevant to the
construction of a simulating partial halt decider it is helpful to
presentation of the
result, especially if your target audience contains software engineers.
If your target audience is mainly mathematicians the convnetional idea
of proofs is more useful because in that case most of your presentation
must be proofs.
My ideas must be anchored in fully specified running software
otherwise the false assumptions made by computer science people
remain hidden.
Even when I slap them in the face with proven facts they deny
these proven facts on the basis of their indoctrination.
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
_DDD()
[00002163] 55        push ebp     ; housekeeping
[00002164] 8bec      mov ebp,esp  ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404Â Â Â Â add esp,+04
[00002173] 5d        pop ebp
[00002174] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002174]
DDD is correctly emulated by HHH until HHH correctly
determines that
 *its simulated DDD would never stop running unless aborted*
 *its simulated DDD would never stop running unless aborted*
 *its simulated DDD would never stop running unless aborted*
On 7/29/2024 2:27 AM, Mikko wrote:
On 2024-07-28 23:54:54 +0000, olcott said:
On 7/28/2024 4:23 AM, Mikko wrote:
On 2024-07-27 18:20:19 +0000, olcott said:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:You also need the conventional ideas of halting and halt decider.
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been
aborted.
This is not the same as reaching its ret instruction and terminating >>>>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for >>>>>> turing machines. A turing machine is either running or halted.
There is
no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider. >>>>
The latter is largely a combination of the conventional ideas of
decider and halting but also involves the conventional of
prediction, so you need that, too.
Although the conventional idea of testing is not relevant to the
construction of a simulating partial halt decider it is helpful to
presentation of the
result, especially if your target audience contains software
engineers. If your target audience is mainly mathematicians the
convnetional idea of proofs is more useful because in that case most
of your presentation must be proofs.
My ideas must be anchored in fully specified running software
otherwise the false assumptions made by computer science people
remain hidden.
There is no "must" there. You may present your ideas whichever way you
think is the best for your purposes.
Even when I make my ideas 100% concrete people still deny
the verified facts.When I make them less than 100% concrete
it is not as specific as verified facts.
One good way to avoid false assumptions is to clearly state what is
assumed instead. Sometimes it may be necessary to clearly state what
is not assumed.
Even when I slap them in the face with proven facts they deny
these proven facts on the basis of their indoctrination.
Facts are never proven. They are observed.
You didn't even bother to look at how HHH examines the
execution trace of Infinite_Recursion() to determine that Infinite_Recursion() specifies non-halting behavior.
Because of this you cannot see that the execution trace
of DDD correctly emulated by DDD is essentially this same
trace and thus also specifies non-halting behavior.
void Infinite_Recursion()
{
 Infinite_Recursion();
}
_Infinite_Recursion()
[0000215a] 55        push ebp     ; 1st line
[0000215b] 8bec      mov ebp,esp  ; 2nd line
[0000215d] e8f8ffffff call 0000215a ; 3rd line
[00002162] 5d        pop ebp
[00002163] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0010) [00002163]
Begin Local Halt Decider Simulation  Execution Trace Stored at:113934 [0000215a][00113924][00113928] 55        push ebp     ; 1st line
[0000215b][00113924][00113928] 8bec      mov ebp,esp  ; 2nd line [0000215d][00113920][00002162] e8f8ffffff call 0000215a ; 3rd line [0000215a][0011391c][00113924] 55        push ebp     ; 1st line
[0000215b][0011391c][00113924] 8bec      mov ebp,esp  ; 2nd line [0000215d][00113918][00002162] e8f8ffffff call 0000215a ; 3rd line
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
=====
void DDD()
{
 HHH(DDD);
}
_DDD()
[00002177] 55              push ebp     ; 1st line [00002178] 8bec            mov ebp,esp  ; 2nd line
[0000217a] 6877210000Â Â Â Â Â Â push 00002177 ; push DDD
[0000217f] e853f4ffff      call 000015d7 ; call HHH
[00002184] 83c404Â Â Â Â Â Â Â Â Â Â add esp,+04
[00002187] 5d              pop ebp
[00002188] c3Â Â Â Â Â Â Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002188]
// executed HHH emulates 1st instance of DDD
New slave_stack at:10388d
Begin Local Halt Decider Simulation  Execution Trace Stored at:113895 [00002177][00113885][00113889] 55        push ebp     ; 1st line
[00002178][00113885][00113889] 8bec      mov ebp,esp  ; 2nd line [0000217a][00113881][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011387d][00002184] e853f4ffff call 000015d7 ; call HHH
// emulated HHH emulates 2nd instance of DDD
New slave_stack at:14e2b5
[00002177][0015e2ad][0015e2b1] 55        push ebp     ; 1st line
[00002178][0015e2ad][0015e2b1] 8bec      mov ebp,esp  ; 2nd line [0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
On 27/07/2024 19:14, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>> This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is >>> no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing >>> machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
Aborting is an action performed by a simulator, not the TM being simulated.
OK, so if a simulator aborts the program it's simulating, that program is still in state running, even though it's a suspended animation which will never get any further. The simulator, having aborted the program, then
has no more work to do, so the simulator will be in state halted. Is
that right?
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
_DDD()
[00002163] 55        push ebp     ; housekeeping
[00002164] 8bec      mov ebp,esp  ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404Â Â Â Â add esp,+04
[00002173] 5d        pop ebp
[00002174] c3Â Â Â Â Â Â Â Â ret
Size in bytes:(0018) [00002174]
DDD is correctly emulated by HHH until HHH correctly
determines that
 *its simulated DDD would never stop running unless aborted*
 *its simulated DDD would never stop running unless aborted*
 *its simulated DDD would never stop running unless aborted*
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
On 7/28/2024 4:10 AM, Mikko wrote:
On 2024-07-27 18:14:52 +0000, Alan Mackenzie said:
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>> This is not the same as reaching its ret instruction and terminating
normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for
turing machines. A turing machine is either running or halted. There is >>> no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing >>> machine.
So aborted programs are halted programs. If you disagree, perhaps you
could point out where in my arguments above I'm wrong.
May I disagree? An "aborted" Turing machine is a runnung Turing machine.
A Turing machine has no notion of being aborted.
On 7/29/2024 2:27 AM, Mikko wrote:
On 2024-07-28 23:54:54 +0000, olcott said:
On 7/28/2024 4:23 AM, Mikko wrote:
On 2024-07-27 18:20:19 +0000, olcott said:
On 7/27/2024 1:14 PM, Alan Mackenzie wrote:You also need the conventional ideas of halting and halt decider.
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>>>>> This is not the same as reaching its ret instruction and terminating >>>>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for >>>>>> turing machines. A turing machine is either running or halted. There is
no third state "aborted".
Until you take the conventional ideas of
(a) UTM
(b) TM Description
(c) Decider
and combine them together to become a simulating partial halt decider. >>>>
The latter is largely a combination of the conventional ideas of
decider and halting but also involves the conventional of
prediction, so you need that, too.
Although the conventional idea of testing is not relevant to the
construction of a simulating partial halt decider it is helpful to
presentation of the
result, especially if your target audience contains software engineers. >>>> If your target audience is mainly mathematicians the convnetional idea >>>> of proofs is more useful because in that case most of your presentation >>>> must be proofs.
My ideas must be anchored in fully specified running software
otherwise the false assumptions made by computer science people
remain hidden.
There is no "must" there. You may present your ideas whichever way you
think is the best for your purposes.
Even when I make my ideas 100% concrete people still deny
the verified facts.
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail
is the meaning of the word "emulate" as that determines what is a
correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider *H correctly simulates its input D*
   *until H correctly determines that its simulated D would never*
   *stop running unless aborted* then
   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
for DDD correctly emulated by HHH until...
On 7/30/2024 2:15 AM, Mikko wrote:
On 2024-07-29 16:55:46 +0000, olcott said:
On 7/28/2024 4:10 AM, Mikko wrote:
On 2024-07-27 18:14:52 +0000, Alan Mackenzie said:A Turing machine has no notion of being aborted.
olcott <polcott333@gmail.com> wrote:
Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted. >>>>>> This is not the same as reaching its ret instruction and terminating >>>>>> normally (AKA halting).
I think you're wrong, here. All your C programs are a stand in for >>>>> turing machines. A turing machine is either running or halted. There is
no third state "aborted". An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted turing >>>>> machine.
So aborted programs are halted programs. If you disagree, perhaps you >>>>> could point out where in my arguments above I'm wrong.
May I disagree? An "aborted" Turing machine is a runnung Turing machine. >>>
That's correct. But you have used the word anyway.
It seems that either you have ADD or are becoming a liar.
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail
is the meaning of the word "emulate" as that determines what is a
correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider *H correctly simulates its input D*
*until H correctly determines that its simulated D would never*
*stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
for DDD correctly emulated by HHH until...
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail
is the meaning of the word "emulate" as that determines what is a
correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider *H correctly simulates its input D*
    *until H correctly determines that its simulated D would never* >>>     *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
for DDD correctly emulated by HHH until...
It is as Sipser does not say whether DDD is correctly simulated by HHH
or what would constitute a correct simulation.
This has already been fully established elsewhere.
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness
you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail
is the meaning of the word "emulate" as that determines what is a
correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider *H correctly simulates its input D*
    *until H correctly determines that its simulated D would never* >>>     *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
for DDD correctly emulated by HHH until...
It is as Sipser does not say whether DDD is correctly simulated by HHH
or what would constitute a correct simulation.
What is relevant is that the emolator program in HHH contains details
that are not specified by the x86 language.
It seems that every time I completely prove my point you
change the subject to another point that I have already
completely proven.
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness >>>>>>>> you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail >>>>>> is the meaning of the word "emulate" as that determines what is a
correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider *H correctly simulates its input D* >>>>> Â Â Â Â *until H correctly determines that its simulated D would never* >>>>> Â Â Â Â *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
for DDD correctly emulated by HHH until...
It is as Sipser does not say whether DDD is correctly simulated by HHH >>>> or what would constitute a correct simulation.
This has already been fully established elsewhere.
You have never shown any proof about either "correctly".
When instructions are executed/emulated according to the
semantics of the x86 language then they are executed/emulated
correctly.
On 8/1/2024 7:52 AM, Fred. Zwarts wrote:
Op 01.aug.2024 om 14:03 schreef olcott:
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness >>>>>>>>>> you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure >>>>>>>>> to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail >>>>>>>> is the meaning of the word "emulate" as that determines what is a >>>>>>>> correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers: >>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
    If simulating halt decider *H correctly simulates its input D* >>>>>>>     *until H correctly determines that its simulated D would never*
    *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
for DDD correctly emulated by HHH until...
It is as Sipser does not say whether DDD is correctly simulated by >>>>>> HHH
or what would constitute a correct simulation.
This has already been fully established elsewhere.
You have never shown any proof about either "correctly".
When instructions are executed/emulated according to the
semantics of the x86 language then they are executed/emulated
correctly.
But only those instructions. A halting program is simulated correctly
if no instructions are skipped.
Correctly and correctly and completely are not the
same damn thing you freaking moron.
On 8/1/2024 7:52 AM, Fred. Zwarts wrote:Yes, an incomplete simulation is also incorrect.
Op 01.aug.2024 om 14:03 schreef olcott:
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
When instructions are executed/emulated according to the semantics ofBut only those instructions. A halting program is simulated correctly
the x86 language then they are executed/emulated correctly.
if no instructions are skipped.
Correctly and completely are not the same damn thing you
freaking moron.
On 8/1/2024 10:46 AM, joes wrote:
Am Thu, 01 Aug 2024 07:56:27 -0500 schrieb olcott:
On 8/1/2024 7:52 AM, Fred. Zwarts wrote:Yes, an incomplete simulation is also incorrect.
Op 01.aug.2024 om 14:03 schreef olcott:
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
When instructions are executed/emulated according to the semantics of >>>>> the x86 language then they are executed/emulated correctly.But only those instructions. A halting program is simulated correctly
if no instructions are skipped.
Correctly and completely are not the same damn thing you
freaking moron.
When N steps of DDD are emulated correctly one can only
say that N steps were not emulated correctly when one
is a liar.
When a correct and complete emulation is impossible
because the computation has no end then it is pretty
damn stupid to insist an a complete emulation.
On 8/1/2024 10:46 AM, joes wrote:Good thing I only said this: not all steps were simulated.
Am Thu, 01 Aug 2024 07:56:27 -0500 schrieb olcott:When N steps of DDD are emulated correctly one can only say that N steps
On 8/1/2024 7:52 AM, Fred. Zwarts wrote:Yes, an incomplete simulation is also incorrect.
Op 01.aug.2024 om 14:03 schreef olcott:
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
Correctly and completely are not the same damn thing you freakingWhen instructions are executed/emulated according to the semanticsBut only those instructions. A halting program is simulated correctly
of the x86 language then they are executed/emulated correctly.
if no instructions are skipped.
moron.
were not emulated correctly when one is a liar.
When a correct and complete emulation is impossible because theIt is possible. It just doesn't end. The simulated machine isn't required
computation has no end then it is pretty damn stupid to insist an a
complete emulation.
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
If you had suffient understanding of x86 language and correctness >>>>>>>> you would know that DDD is incorrectly emnulated by HHH.
This is only seems that way because every reviewer makes sure
to ignore one aspect of the basis of another.
It is perfectly OK to ignore irrelevant details. A relevant detail >>>>>> is the meaning of the word "emulate" as that determines what is a
correct emulation and what is not.
*It is not OK to ignore*
This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> Â Â Â Â If simulating halt decider *H correctly simulates its input D* >>>>> Â Â Â Â *until H correctly determines that its simulated D would never* >>>>> Â Â Â Â *stop running unless aborted* then
    H can abort its simulation of D and correctly report that D >>>>>     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>
for DDD correctly emulated by HHH until...
It is as Sipser does not say whether DDD is correctly simulated by HHH >>>> or what would constitute a correct simulation.
This has already been fully established elsewhere.
You have never shown any proof about either "correctly".
When instructions are executed/emulated according to the
semantics of the x86 language then they are executed/emulated
correctly.
On 8/1/2024 2:26 PM, Fred. Zwarts wrote:
Op 01.aug.2024 om 18:00 schreef olcott:
On 8/1/2024 10:46 AM, joes wrote:
Am Thu, 01 Aug 2024 07:56:27 -0500 schrieb olcott:
On 8/1/2024 7:52 AM, Fred. Zwarts wrote:Yes, an incomplete simulation is also incorrect.
Op 01.aug.2024 om 14:03 schreef olcott:
On 8/1/2024 2:52 AM, Mikko wrote:
On 2024-07-31 17:33:38 +0000, olcott said:
On 7/31/2024 4:15 AM, Mikko wrote:
On 2024-07-30 23:40:21 +0000, olcott said:
On 7/30/2024 2:00 AM, Mikko wrote:
On 2024-07-29 16:50:53 +0000, olcott said:
On 7/28/2024 3:59 AM, Mikko wrote:
On 2024-07-27 20:05:31 +0000, olcott said:
When instructions are executed/emulated according to theBut only those instructions. A halting program is simulated correctly >>>>>> if no instructions are skipped.
semantics of
the x86 language then they are executed/emulated correctly.
Correctly and completely are not the same damn thing you
freaking moron.
When N steps of DDD are emulated correctly one can only
say that N steps were not emulated correctly when one
is a liar.
Nobody claims it. It is just your dream.
When the last M steps of a halting DDD are skipped, one can only say
that it is a correct simulation when one is a liar.
This is the reality.
When a correct and complete emulation is impossible
because the computation has no end then it is pretty
damn stupid to insist an a complete emulation.
Nobody claims it. It is just your dream.
When a correct and complete simulation of HHH by itself is not
possible even when HHH halts, then it is pretty stupid to insist that
a correct simulation of halting program shows that it does not halt.
That is the reality.
Dreams are no substitute for fact, not for logic.
There are no last steps of DDD correctly emulated by HHH.
There are N steps of DDD correctly emulated by HHH that
prove there are no last steps of DDD correctly emulated
by HHH. This is essentially mathematical induction.
This is meant for Mike, Joes and Fred don't have the technical
competence to understand it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 25:27:56 |
| Calls: | 10,390 |
| Calls today: | 1 |
| Files: | 14,064 |
| Messages: | 6,417,035 |