On 3/26/2025 8:22 PM, Richard Damon wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even if
an unbounded number of steps are emulated. Since HHH doesn't do that,
it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite
number of steps.
This proves that the DDD input to HHH that defines a
pathological relationship to HHH specifies different
behavior than the DDD input to HHH1 where no
pathological relationship is defined.
On 3/26/2025 8:22 PM, Richard Damon wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even if
an unbounded number of steps are emulated. Since HHH doesn't do that,
it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite
number of steps.
On 3/26/2025 10:28 PM, Richard Damon wrote:Indeed. The finite string given to HHH specifies a halting function
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even if
an unbounded number of steps are emulated. Since HHH doesn't do
that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
But DDD emulated by an actually correct emulator will,
If you were not intentionally persisting in a lie you
would acknowledge the dead obvious that DDD emulated
by HHH according to the semantics of the x86 language
cannot possibly correctly reach its final halt state.
The behavior that DDD specifies to HHH <is> the behavior
that it must report on.
Turing computable halt functions are only allowed to
report on the behavior that their input specifies.
int sum(int x, int y) { return x + y; }
sum(5,6) must report the sum of 5+6 and
is not allowed to report the sum of 2+3.
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even if
an unbounded number of steps are emulated. Since HHH doesn't do
that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
But DDD emulated by an actually correct emulator will,
If you were not intentionally persisting in a lie you
would acknowledge the dead obvious that DDD emulated
by HHH according to the semantics of the x86 language
cannot possibly correctly reach its final halt state.
The behavior that DDD specifies to HHH <is> the behavior
that it must report on.
Turing computable halt functions are only allowed to
report on the behavior that their input specifies.
int sum(int x, int y) { return x + y; }
sum(5,6) must report the sum of 5+6 and
is not allowed to report the sum of 2+3.
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator reports that it
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even if
an unbounded number of steps are emulated. Since HHH doesn't do
that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite
number of steps.
is unable to reach the end of the simulation of a program that halts
in direct execution.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
It is interesting to know:
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed?'
It is the halts while directly executed that is impossible
for all inputs. No TM can ever report on the behavior of
the direct execution of any other TM.
On 3/27/2025 6:02 AM, Richard Damon wrote:Yes, HHH is not a correct simulator.
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
If you were not intentionally persisting in a lie you wouldBut DDD emulated by an actually correct emulator will,Non-Halting is that the machine won't reach its final staste evenDDD emulated by any HHH will never reach its final state in an
if an unbounded number of steps are emulated. Since HHH doesn't do >>>>>> that, it isn't showing non-halting.
unbounded number of steps.
acknowledge the dead obvious that DDD emulated by HHH according to the
semantics of the x86 language cannot possibly correctly reach its
final halt state.
DDD doesn't specify anything different *to* HHH. It is just the same code.And if you were not intentionally persisting in a lie, you would admit
that your HHH doesn't do that, as it stops before it finishes.
The behavior that DDD specifies to HHH <is> the behavior that it must
report on.
Yes, HHH is counter to the definition - i.e. wrong. It is notWhich, by the definition, is the behavior of the directly executed DDD,That is counter-factual.
The behavior IS WHAT IT IS and that includes recursive emulation.
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:That is exactly what it does, and you have said so before(tm).
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:
That IS NOT what HHH is reporting.It is not very interesting to know whether a simulator reports that itNon-Halting is that the machine won't reach its final staste even ifDDD emulated by any HHH will never reach its final state in an
an unbounded number of steps are emulated. Since HHH doesn't do that,
it isn't showing non-halting.
unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite number of
steps.
is unable to reach the end of the simulation of a program that halts in
direct execution.
HHH correctly rejects DDD because DDD correctly emulated by HHH cannot possibly reach its own final halt state.DDD doesn't *do* anything, it is being simulated. HHH can't reach
The direct execution of a TM is obviously computable from its description.It is interesting to know:It is the halts while directly executed that is impossible for all
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that [...]
halts when directly executed?'
This question seems undecidable for Olcott.
inputs. No TM can ever report on the behavior of the direct execution of
any other TM.
A TM can only report on the behavior that the machine code of another TM specifies. When it specifies a pathological relationship then theNo, the machine code doesn't "specify a pathological relationship", that
behavior caused by the pathological relationship MUST BE REPORTED.
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator reports that it
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even if
an unbounded number of steps are emulated. Since HHH doesn't do
that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite
number of steps.
is unable to reach the end of the simulation of a program that halts
in direct execution.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
It is interesting to know:
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed?'
It is the halts while directly executed that is impossible
for all inputs. No TM can ever report on the behavior of
the direct execution of any other TM.
A TM can only report on the behavior that the machine code
of another TM specifies. When it specifies a pathological
relationship then the behavior caused by the pathological
relationship MUST BE REPORTED.
This question seems undecidable for Olcott.
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even
if an unbounded number of steps are emulated. Since HHH doesn't do >>>>>> that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
But DDD emulated by an actually correct emulator will,
If you were not intentionally persisting in a lie you
would acknowledge the dead obvious that DDD emulated
by HHH according to the semantics of the x86 language
cannot possibly correctly reach its final halt state.
And if you were not intentionally persisting in a lie, you would admit
that your HHH doesn't do that, as it stops before it finishes.
The behavior that DDD specifies to HHH <is> the behavior
that it must report on.
Which, by the definition, is the behavior of the directly executed DDD,
That is counter-factual.
The behavior IS WHAT IT IS and that includes
recursive emulation.
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even
if an unbounded number of steps are emulated. Since HHH doesn't do >>>>>> that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
But DDD emulated by an actually correct emulator will,
If you were not intentionally persisting in a lie you
would acknowledge the dead obvious that DDD emulated
by HHH according to the semantics of the x86 language
cannot possibly correctly reach its final halt state.
And if you were not intentionally persisting in a lie, you would admit
that your HHH doesn't do that, as it stops before it finishes.
The behavior that DDD specifies to HHH <is> the behavior
that it must report on.
Which, by the definition, is the behavior of the directly executed
DDD, or the completely and correctly emulation of that input,
something HHH doesn't do, so HHH doesn't define.
Turing computable halt functions are only allowed to
report on the behavior that their input specifies.
There are no Turing Computable Halt Functions.
A halt function is not the same as a halt decider. https://en.wikipedia.org/wiki/Computable_function
A Turing computable function could have its domain
restricted to a single finite string.
You are just assuming the existance of them, because you live in the
land of Make Beleive.
No it is your mistake of not paying close enough
attention to the exact terms that I am using.
The Halting Problem defines a specific mapping based on the execution
of a program, and provides to the claimed decider a representation of
that program, and asks it to tell us if that program, when run, will
halt.
This has proven to be flat out incorrect countless times
in many ways. Turing computable functions on a domain
of specific finite string encodings of sequences of moves
reports on the actual behavior that this finite string
actually specifies including recursive emulation when
specified.
If it can't do that, then it has just failed to meet the requirements.
These requirements are not incorrect. They are anchored in
false assumptions. When any requirement is anchored in
false assumptions this requirement is incorrect.
You are just trying to insist that you can change the problem so you
can make up an answer, thus violation what you say in your next
statement below:
HHH(DDD) is not allowed to report on the behavior of
DDD(HHH1) when this differs from the behavior of HHH(DDD).
int sum(int x, int y) { return x + y; }
sum(5,6) must report the sum of 5+6 and
is not allowed to report the sum of 2+3.
Right, and HHH(DDD) must report on the actual behavior of the directed
executed DDD as that is what the question it claims to be answering says.
Not the behavior of some DDD' that calls a different HHH than what it
does,
Sorry, you are just proving your stupidity.
On 3/27/2025 4:56 PM, joes wrote:
Am Thu, 27 Mar 2025 13:10:46 -0500 schrieb olcott:
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
If you were not intentionally persisting in a lie you wouldBut DDD emulated by an actually correct emulator will,Non-Halting is that the machine won't reach its final staste even >>>>>>>> if an unbounded number of steps are emulated. Since HHH doesn't do >>>>>>>> that, it isn't showing non-halting.DDD emulated by any HHH will never reach its final state in an
unbounded number of steps.
acknowledge the dead obvious that DDD emulated by HHH according to the >>>>> semantics of the x86 language cannot possibly correctly reach its
final halt state.
Yes, HHH is not a correct simulator.
In other words you either disagree with the x86 language
or don't have a clue about it.
On 3/27/2025 4:56 PM, joes wrote:
Am Thu, 27 Mar 2025 13:10:46 -0500 schrieb olcott:
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
If you were not intentionally persisting in a lie you wouldBut DDD emulated by an actually correct emulator will,Non-Halting is that the machine won't reach its final staste even >>>>>>>> if an unbounded number of steps are emulated. Since HHH doesn't do >>>>>>>> that, it isn't showing non-halting.DDD emulated by any HHH will never reach its final state in an
unbounded number of steps.
acknowledge the dead obvious that DDD emulated by HHH according to the >>>>> semantics of the x86 language cannot possibly correctly reach its
final halt state.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Yes, HHH is not a correct simulator.
You say that it is not a correct simulator on the basis
of your ignorance of the x86 language that conclusively
proves that HHH does correctly simulate the first four
instructions of DDD and correctly simulates itself
simulating the first four instructions of DDD.
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator reports >>>>>>>>>> that it is unable to reach the end of the simulation of a
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste >>>>>>>>>>>> even if an unbounded number of steps are emulated. Since HHH >>>>>>>>>>>> doesn't do that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state >>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>> number of steps.
program that halts in direct execution.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not
computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders*
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM. I proved
this many times in may ways. Ignoring these proofs
IT NOT ANY FORM OF REBUTTAL.
On 3/27/2025 7:47 PM, Richard Damon wrote:
On 3/27/25 8:11 PM, olcott wrote:
On 3/27/2025 4:56 PM, joes wrote:
Am Thu, 27 Mar 2025 13:10:46 -0500 schrieb olcott:
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
If you were not intentionally persisting in a lie you wouldBut DDD emulated by an actually correct emulator will,Non-Halting is that the machine won't reach its final staste even >>>>>>>>>> if an unbounded number of steps are emulated. Since HHHDDD emulated by any HHH will never reach its final state in an >>>>>>>>> unbounded number of steps.
doesn't do
that, it isn't showing non-halting.
acknowledge the dead obvious that DDD emulated by HHH according
to the
semantics of the x86 language cannot possibly correctly reach its >>>>>>> final halt state.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Yes, HHH is not a correct simulator.
You say that it is not a correct simulator on the basis
of your ignorance of the x86 language that conclusively
proves that HHH does correctly simulate the first four
instructions of DDD and correctly simulates itself
simulating the first four instructions of DDD.
It isn't a correct simulator,
You know that you are lying about this or you would
show how DDD emulated by HHH would reach its final state
ACCORDING TO THE SEMANTICS OF THE X86 LANGUAGE.
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>> reports that it is unable to reach the end of the simulation >>>>>>>>>>>> of a program that halts in direct execution.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>> staste even if an unbounded number of steps are emulated. >>>>>>>>>>>>>> Since HHH doesn't do that, it isn't showing non-halting. >>>>>>>>>>>>>>
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>> number of steps.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not >>>>>>>>>> computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders*
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM.
False:
I did not say that no TM can ever report on
behavior that matches the behavior of a directly
executing TM.
No TM can every directly see the behavior of the
direct execution of any other TM because no TM can
take a directly executing TM as an input.
On 3/27/2025 2:56 PM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 18:50 schreef olcott:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator reports that
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste even
if an unbounded number of steps are emulated. Since HHH doesn't do >>>>>> that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite
number of steps.
it is unable to reach the end of the simulation of a program that
halts in direct execution.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
Yes, that is the same in other words as rejecting because it could not
correctly simulate the input up to its end.
It doesn't have an end dumb bunny.
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>> reports that it is unable to reach the end of the simulation >>>>>>>>>>>> of a program that halts in direct execution.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>> staste even if an unbounded number of steps are emulated. >>>>>>>>>>>>>> Since HHH doesn't do that, it isn't showing non-halting. >>>>>>>>>>>>>>
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>> number of steps.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not >>>>>>>>>> computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders*
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM.
False:
I did not say that no TM can ever report on
behavior that matches the behavior of a directly
executing TM.
No TM can every directly see the behavior of the
direct execution of any other TM because no TM can
take a directly executing TM as an input.
The best that any TM can ever do to see what
the behavior of another TM might be is to simulate
the machine code (TM description) of this machine.
When this input defines a pathological relationship
with its simulating half decider this does prevent
this simulated machine from reaching its final halt state.
On 3/27/2025 9:04 PM, Richard Damon wrote:
On 3/27/25 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>> reports that it is unable to reach the end of the simulation >>>>>>>>>>>> of a program that halts in direct execution.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>> staste even if an unbounded number of steps are emulated. >>>>>>>>>>>>>> Since HHH doesn't do that, it isn't showing non-halting. >>>>>>>>>>>>>>
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>> number of steps.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not >>>>>>>>>> computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders*
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM. I proved
this many times in may ways. Ignoring these proofs
IT NOT ANY FORM OF REBUTTAL.
Sure they can.
WHere is your proof? And what actual accepted principles is is based on?
No TM can take another directly executed TM as an input
and Turing computable functions only compute the mapping
from inputs to outputs.
On 3/27/2025 7:47 PM, Richard Damon wrote:But only the first four - three actually, since the call doesn't return.
On 3/27/25 8:11 PM, olcott wrote:
On 3/27/2025 4:56 PM, joes wrote:
Yes, HHH is not a correct simulator.You say that it is not a correct simulator on the basis of your
ignorance of the x86 language that conclusively proves that HHH does
correctly simulate the first four instructions of DDD and correctly
simulates itself simulating the first four instructions of DDD.
Dude, it is impossible for HHH, that's why it's incorrect.It isn't a correct simulator,You know that you are lying about this or you would show how DDD
emulated by HHH would reach its final state ACCORDING TO THE SEMANTICS
OF THE X86 LANGUAGE.
On 3/27/2025 8:24 PM, dbush wrote:
On 3/27/2025 9:21 PM, olcott wrote:
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:That IS NOT what HHH is reporting.
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>>>> reports that it is unable to reach the end of the
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>> [0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>>>> staste even if an unbounded number of steps are >>>>>>>>>>>>>>>> emulated. Since HHH doesn't do that, it isn't showing >>>>>>>>>>>>>>>> non-halting.
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>>>> number of steps.
simulation of a program that halts in direct execution. >>>>>>>>>>>>>
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not >>>>>>>>>>>> computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote: >>>>>>>>>> > In other words you could find any error in my post so you >>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders* >>>>>>>>
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM.
False:
I did not say that no TM can ever report on
behavior that matches the behavior of a directly
executing TM.
Good, because that's all that's required for a solution to the halting
problem:
There are sometimes when the behavior of TM Description
D correctly simulated by UTM1 does not match the behavior
correctly simulated by UTM2.
This can only be directly seen by HHH/DD HHH1/DDD that are
fully operational code.
On 3/27/2025 9:02 PM, Richard Damon wrote:
On 3/27/25 9:10 PM, olcott wrote:
On 3/27/2025 7:47 PM, Richard Damon wrote:
On 3/27/25 8:11 PM, olcott wrote:
On 3/27/2025 4:56 PM, joes wrote:
Am Thu, 27 Mar 2025 13:10:46 -0500 schrieb olcott:
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
If you were not intentionally persisting in a lie you wouldBut DDD emulated by an actually correct emulator will,Non-Halting is that the machine won't reach its final staste >>>>>>>>>>>> evenDDD emulated by any HHH will never reach its final state in an >>>>>>>>>>> unbounded number of steps.
if an unbounded number of steps are emulated. Since HHH >>>>>>>>>>>> doesn't do
that, it isn't showing non-halting.
acknowledge the dead obvious that DDD emulated by HHH according >>>>>>>>> to the
semantics of the x86 language cannot possibly correctly reach its >>>>>>>>> final halt state.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Yes, HHH is not a correct simulator.
You say that it is not a correct simulator on the basis
of your ignorance of the x86 language that conclusively
proves that HHH does correctly simulate the first four
instructions of DDD and correctly simulates itself
simulating the first four instructions of DDD.
It isn't a correct simulator,
You know that you are lying about this or you would
show how DDD emulated by HHH would reach its final state
ACCORDING TO THE SEMANTICS OF THE X86 LANGUAGE.
It can't be, because your HHH doesn't meet your requirement.
You cannot show that because you know you are lying about that.
On 3/27/2025 9:04 PM, Richard Damon wrote:
On 3/27/25 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>> reports that it is unable to reach the end of the simulation >>>>>>>>>>>> of a program that halts in direct execution.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>> staste even if an unbounded number of steps are emulated. >>>>>>>>>>>>>> Since HHH doesn't do that, it isn't showing non-halting. >>>>>>>>>>>>>>
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>> number of steps.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not >>>>>>>>>> computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote:
In other words you could find any error in my post so youresort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders*
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM. I proved
this many times in may ways. Ignoring these proofs
IT NOT ANY FORM OF REBUTTAL.
Sure they can.
WHere is your proof? And what actual accepted principles is is based on?
No TM can take another directly executed TM as an input
and Turing computable functions only compute the mapping
from inputs to outputs.
On 3/27/2025 9:33 PM, dbush wrote:
On 3/27/2025 10:10 PM, olcott wrote:
On 3/27/2025 8:24 PM, dbush wrote:
On 3/27/2025 9:21 PM, olcott wrote:
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:That IS NOT what HHH is reporting.
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>>>>>> reports that it is unable to reach the end of the >>>>>>>>>>>>>>>> simulation of a program that halts in direct execution. >>>>>>>>>>>>>>>
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>>>> [0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>>>>>> staste even if an unbounded number of steps are >>>>>>>>>>>>>>>>>> emulated. Since HHH doesn't do that, it isn't showing >>>>>>>>>>>>>>>>>> non-halting.
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>>>>>> number of steps.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is >>>>>>>>>>>>>> not computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote: >>>>>>>>>>>> > In other words you could find any error in my post so you >>>>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders* >>>>>>>>>>
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM.
False:
I did not say that no TM can ever report on
behavior that matches the behavior of a directly
executing TM.
Good, because that's all that's required for a solution to the
halting problem:
There are sometimes when the behavior of TM Description
D correctly simulated by UTM1 does not match the behavior
correctly simulated by UTM2.
Irrelevant, because to satisfy the requirements, the behavior of the
described machine when executed directly must be reported.
I HAVE PROVED THAT THE REQUIREMENT IS WRONG NITWIT.
A FUNCTION THAT IS REQUIRED TO COMPUTE THE SQUARE
OF A BOX OF ROCKS IS ALSO INCORRECT.
On 3/27/2025 9:33 PM, dbush wrote:It is wrong to ask for the behaviour of the direct execution? Anyways,
On 3/27/2025 10:10 PM, olcott wrote:
On 3/27/2025 8:24 PM, dbush wrote:
On 3/27/2025 9:21 PM, olcott wrote:
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:
In other words, HHH is not a halt decider because it is not >>>>>>>>>>>>>> computing the required mapping:It is not very interesting to know whether a simulator >>>>>>>>>>>>>>>> reports that it is unable to reach the end of the >>>>>>>>>>>>>>>> simulation of a program that halts in direct execution. >>>>>>>>>>>>>>>That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly emulated >>>>>>>>>>>>>>> by HHH cannot possibly reach its own final halt state. >>>>>>>>>>>>>>
I corrected your error dozens of times and you ignore these
corrections and mindlessly repeat your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
There are sometimes when the behavior of TM Description D correctlyI did not say that no TM can ever report on behavior that matches
the behavior of a directly executing TM.
Good, because that's all that's required for a solution to the
halting problem:
simulated by UTM1 does not match the behavior correctly simulated by
UTM2.
Irrelevant, because to satisfy the requirements, the behavior of the
described machine when executed directly must be reported.
I HAVE PROVED THAT THE REQUIREMENT IS WRONG NITWIT.
A FUNCTION THAT IS REQUIRED TO COMPUTE THE SQUARE OF A BOX OF ROCKS IS
ALSO INCORRECT.
On 3/28/2025 1:07 PM, joes wrote:
Am Fri, 28 Mar 2025 12:57:56 -0500 schrieb olcott:
On 3/27/2025 9:33 PM, dbush wrote:
On 3/27/2025 10:10 PM, olcott wrote:
On 3/27/2025 8:24 PM, dbush wrote:
On 3/27/2025 9:21 PM, olcott wrote:
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:
In other words, HHH is not a halt decider because it is not >>>>>>>>>>>>>>>> computing the required mapping:It is not very interesting to know whether a simulator >>>>>>>>>>>>>>>>>> reports that it is unable to reach the end of the >>>>>>>>>>>>>>>>>> simulation of a program that halts in direct execution. >>>>>>>>>>>>>>>>>That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly emulated >>>>>>>>>>>>>>>>> by HHH cannot possibly reach its own final halt state. >>>>>>>>>>>>>>>>
I corrected your error dozens of times and you ignore these >>>>>>>>>>> corrections and mindlessly repeat your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
There are sometimes when the behavior of TM Description D correctlyI did not say that no TM can ever report on behavior that matches >>>>>>> the behavior of a directly executing TM.
Good, because that's all that's required for a solution to the
halting problem:
simulated by UTM1 does not match the behavior correctly simulated by >>>>> UTM2.
Irrelevant, because to satisfy the requirements, the behavior of the
described machine when executed directly must be reported.
I HAVE PROVED THAT THE REQUIREMENT IS WRONG NITWIT.
A FUNCTION THAT IS REQUIRED TO COMPUTE THE SQUARE OF A BOX OF ROCKS IS
ALSO INCORRECT.
It is wrong to ask for the behaviour of the direct execution? Anyways,
HHH can't do it.
Unless and until one TM can take another executing
TM as an input IT IS WRONG TO REQUIRE A TM TO REPORT
ON SOMETHING THAT IT CANNOT SEE.
On 3/28/2025 8:50 AM, Richard Damon wrote:
On 3/27/25 10:11 PM, olcott wrote:
On 3/27/2025 9:02 PM, Richard Damon wrote:
On 3/27/25 9:10 PM, olcott wrote:
On 3/27/2025 7:47 PM, Richard Damon wrote:
On 3/27/25 8:11 PM, olcott wrote:
On 3/27/2025 4:56 PM, joes wrote:
Am Thu, 27 Mar 2025 13:10:46 -0500 schrieb olcott:
On 3/27/2025 6:02 AM, Richard Damon wrote:
On 3/26/25 11:47 PM, olcott wrote:
On 3/26/2025 10:28 PM, Richard Damon wrote:
On 3/26/25 11:09 PM, olcott wrote:
On 3/26/2025 8:22 PM, Richard Damon wrote:
If you were not intentionally persisting in a lie you would >>>>>>>>>>> acknowledge the dead obvious that DDD emulated by HHHBut DDD emulated by an actually correct emulator will,Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>> staste evenDDD emulated by any HHH will never reach its final state in an >>>>>>>>>>>>> unbounded number of steps.
if an unbounded number of steps are emulated. Since HHH >>>>>>>>>>>>>> doesn't do
that, it isn't showing non-halting.
according to the
semantics of the x86 language cannot possibly correctly reach >>>>>>>>>>> its
final halt state.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Yes, HHH is not a correct simulator.
You say that it is not a correct simulator on the basis
of your ignorance of the x86 language that conclusively
proves that HHH does correctly simulate the first four
instructions of DDD and correctly simulates itself
simulating the first four instructions of DDD.
It isn't a correct simulator,
You know that you are lying about this or you would
show how DDD emulated by HHH would reach its final state
ACCORDING TO THE SEMANTICS OF THE X86 LANGUAGE.
It can't be, because your HHH doesn't meet your requirement.
You cannot show that because you know you are lying about that.
Sure we can, make a main that directly calls HHH and then DDD, then
call HHH1(DDD)
That HHH will return 0, saying that DDD is non-halting, but the DDD
wll return, showing that DDD is halting.
Look at the trace that HHH generates, and that HHH1 generates, HHH's
will be a subset of the trace that HHH1 generates, showing that it is
NOT proof that this program is non-halting as that exact same initial
segment halts.
Your argument about changing HHH shows that it doesn't halt is just
invalid, as then you either changed the input, or demonstrated that
you input was a class error as it didn't contain the COMPLETE
representation of the code of DDD.
Sorry, This is what you have been told for years, but you refuse to
look at the truth, because you have been brainwashed by your lies.
Look
I can't understand how that confused mess addresses
the point of this thread:
It is a verified fact that the finite string of machine
code of DDD emulated by HHH according to the semantics of
the x86 language has different behavior than DDD emulated
by HHH1 according to the semantics of the x86 language.
On 3/28/2025 2:17 PM, dbush wrote:
On 3/28/2025 3:05 PM, olcott wrote:
On 3/28/2025 1:07 PM, joes wrote:
Am Fri, 28 Mar 2025 12:57:56 -0500 schrieb olcott:
On 3/27/2025 9:33 PM, dbush wrote:
On 3/27/2025 10:10 PM, olcott wrote:
On 3/27/2025 8:24 PM, dbush wrote:
On 3/27/2025 9:21 PM, olcott wrote:
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 27.mrt.2025 om 04:09 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 3/26/2025 8:22 PM, Richard Damon wrote:
In other words, HHH is not a halt decider because it >>>>>>>>>>>>>>>>>> is notIt is not very interesting to know whether a simulator >>>>>>>>>>>>>>>>>>>> reports that it is unable to reach the end of the >>>>>>>>>>>>>>>>>>>> simulation of a program that halts in direct execution. >>>>>>>>>>>>>>>>>>>That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly emulated >>>>>>>>>>>>>>>>>>> by HHH cannot possibly reach its own final halt state. >>>>>>>>>>>>>>>>>>
computing the required mapping:
I corrected your error dozens of times and you ignore these >>>>>>>>>>>>> corrections and mindlessly repeat your error like a bot >>>>>>>>>>>>Which is what you've been doing for the last three years. >>>>>>>>>>>> Projection, as always. I'll add the above to the list.
There are sometimes when the behavior of TM Description D correctly >>>>>>> simulated by UTM1 does not match the behavior correctly simulated by >>>>>>> UTM2.I did not say that no TM can ever report on behavior that matches >>>>>>>>> the behavior of a directly executing TM.
Good, because that's all that's required for a solution to the >>>>>>>> halting problem:
Irrelevant, because to satisfy the requirements, the behavior of the >>>>>> described machine when executed directly must be reported.
I HAVE PROVED THAT THE REQUIREMENT IS WRONG NITWIT.
A FUNCTION THAT IS REQUIRED TO COMPUTE THE SQUARE OF A BOX OF ROCKS IS >>>>> ALSO INCORRECT.
It is wrong to ask for the behaviour of the direct execution? Anyways, >>>> HHH can't do it.
Unless and until one TM can take another executing
TM as an input IT IS WRONG TO REQUIRE A TM TO REPORT
ON SOMETHING THAT IT CANNOT SEE.
In other words, you agree that Linz is correct.
Incorrect problems lack correct solutions because they
incorrect problems.
On 3/28/2025 8:53 AM, Richard Damon wrote:
On 3/27/25 10:10 PM, olcott wrote:
On 3/27/2025 8:24 PM, dbush wrote:
On 3/27/2025 9:21 PM, olcott wrote:
On 3/27/2025 8:09 PM, dbush wrote:
On 3/27/2025 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:That IS NOT what HHH is reporting.
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>>>>>> reports that it is unable to reach the end of the >>>>>>>>>>>>>>>> simulation of a program that halts in direct execution. >>>>>>>>>>>>>>>
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>>>> [0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>>>>>> staste even if an unbounded number of steps are >>>>>>>>>>>>>>>>>> emulated. Since HHH doesn't do that, it isn't showing >>>>>>>>>>>>>>>>>> non-halting.
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>>>>>> number of steps.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is >>>>>>>>>>>>>> not computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote: >>>>>>>>>>>> > In other words you could find any error in my post so you >>>>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders* >>>>>>>>>>
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM.
False:
I did not say that no TM can ever report on
behavior that matches the behavior of a directly
executing TM.
Good, because that's all that's required for a solution to the
halting problem:
There are sometimes when the behavior of TM Description
D correctly simulated by UTM1 does not match the behavior
correctly simulated by UTM2.
Show a case.
Remember the DEFINITION of a UTM, it is a machine that exactly
reproduces the behavior of the program that is decribed by its input.
Then that definition is incorrect.
When a finite number of steps of input D are simulated
according to the semantics of its language the directly
executed D halts and the D that calls its own UTM never halts.
I spent years carefully studying this as the Peter Linz
example. https://www.liarparadox.org/Linz_Proof.pdf
When Ĥ is applied to ⟨Ĥ⟩
and embedded_H is a UTM based halt decider
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Pages 4-6
https://www.researchgate.net/ publication/374806722_Does_the_halting_problem_place_an_actual_limit_on_computation
On 3/28/2025 9:03 AM, Richard Damon wrote:
On 3/27/25 10:13 PM, olcott wrote:
On 3/27/2025 9:04 PM, Richard Damon wrote:
On 3/27/25 9:07 PM, olcott wrote:
On 3/27/2025 7:38 PM, dbush wrote:
On 3/27/2025 8:34 PM, olcott wrote:
On 3/27/2025 7:12 PM, dbush wrote:
On 3/27/2025 8:11 PM, olcott wrote:
On 3/27/2025 7:02 PM, dbush wrote:
On 3/27/2025 7:36 PM, olcott wrote:
On 3/27/2025 1:27 PM, dbush wrote:
On 3/27/2025 1:50 PM, olcott wrote:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:That IS NOT what HHH is reporting.
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator >>>>>>>>>>>>>> reports that it is unable to reach the end of the
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>>>>>>> [0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final >>>>>>>>>>>>>>>> staste even if an unbounded number of steps are >>>>>>>>>>>>>>>> emulated. Since HHH doesn't do that, it isn't showing >>>>>>>>>>>>>>>> non-halting.
DDD emulated by any HHH will never reach its final state >>>>>>>>>>>>>>> in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite >>>>>>>>>>>>>>> number of steps.
simulation of a program that halts in direct execution. >>>>>>>>>>>>>
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
In other words, HHH is not a halt decider because it is not >>>>>>>>>>>> computing the required mapping:
Troll
On Monday, March 6, 2023 at 3:19:42 PM UTC-5, olcott wrote: >>>>>>>>>> > In other words you could find any error in my post so you >>>>>>>>>> resort to the
lame tactic of ad hominem personal attack.
Troll
On 7/22/2024 10:51 AM, olcott wrote:
*Ad Hominem attacks are the first resort of clueless wonders* >>>>>>>>
I corrected your error dozens of times and you
ignore these corrections and mindlessly repeat
your error like a bot
Which is what you've been doing for the last three years.
Projection, as always. I'll add the above to the list.
TM's cannot possibly ever report on the behavior
of the direct execution of another TM. I proved
this many times in may ways. Ignoring these proofs
IT NOT ANY FORM OF REBUTTAL.
Sure they can.
WHere is your proof? And what actual accepted principles is is based
on?
No TM can take another directly executed TM as an input
and Turing computable functions only compute the mapping
from inputs to outputs.
ThenI guess your model of compuations can't handle numbers or words
with their meanings.
No you don't you are only lying about this.
On 3/28/2025 4:26 AM, Fred. Zwarts wrote:
Op 28.mrt.2025 om 00:39 schreef olcott:
On 3/27/2025 2:56 PM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 18:50 schreef olcott:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:It is not very interesting to know whether a simulator reports
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
Non-Halting is that the machine won't reach its final staste
even if an unbounded number of steps are emulated. Since HHH
doesn't do that, it isn't showing non-halting.
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite
number of steps.
that it is unable to reach the end of the simulation of a program
that halts in direct execution.
That IS NOT what HHH is reporting.
HHH correctly rejects DDD because DDD correctly
emulated by HHH cannot possibly reach its own
final halt state.
Yes, that is the same in other words as rejecting because it could
not correctly simulate the input up to its end.
It doesn't have an end dumb bunny.
Open your eyes. It has an end,
Perpetually insisting on the strawman deception
may get you condemned to actual Hell. https://biblehub.com/revelation/21-8.htm
DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach it own final halt state.
On 3/27/2025 5:01 PM, joes wrote:
Am Thu, 27 Mar 2025 12:50:12 -0500 schrieb olcott:
On 3/27/2025 2:18 AM, Fred. Zwarts wrote:
Op 27.mrt.2025 om 04:09 schreef olcott:
On 3/26/2025 8:22 PM, Richard Damon wrote:
That IS NOT what HHH is reporting.It is not very interesting to know whether a simulator reports that it >>>> is unable to reach the end of the simulation of a program that halts in >>>> direct execution.Non-Halting is that the machine won't reach its final staste even if >>>>>> an unbounded number of steps are emulated. Since HHH doesn't do that, >>>>>> it isn't showing non-halting.DDD emulated by any HHH will never reach its final state in an
unbounded number of steps.
DDD emulated by HHH1 reaches its final state in a finite number of
steps.
That is exactly what it does, and you have said so before(tm).
You are saying that HHH is reporting that HHH is screwing
up THAT IS FALSE. HHH IS REPORTING THAT DDD IS SCREWING UP.
HHH correctly rejects DDD because DDD correctly emulated by HHH cannot
possibly reach its own final halt state.
DDD doesn't *do* anything, it is being simulated. HHH can't reach
DDD's existing halt state.
DDD specifies a recursive emulation relationship with HHH
The direct execution of a TM is obviously computable from itsIt is interesting to know:It is the halts while directly executed that is impossible for all
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that [...]
halts when directly executed?'
This question seems undecidable for Olcott.
inputs. No TM can ever report on the behavior of the direct execution of >>> any other TM.
description.
A TM can only report on the behavior that the machine code of another TM >>> specifies. When it specifies a pathological relationship then the
behavior caused by the pathological relationship MUST BE REPORTED.
No, the machine code doesn't "specify a pathological relationship", thatThe classic HP counter-example input HAS ALWAYS SPECIFIED
is purely a feature of trying to simulate it with the included simulator.
A PATHOLOGICAL RELATIONSHIP TO ITS DECIDER.
The question has always been what Boolean value can H
correctly return when D is able to do the opposite of
whatever value that H returns?
When we prove that it is impossible for D to do the
opposite of whatever value that H returns the original
question becomes moot.
On 3/31/2025 6:07 AM, Richard Damon wrote:
On 3/30/25 11:13 PM, olcott wrote:
On 3/30/2025 9:36 PM, Richard Damon wrote:
On 3/30/25 10:13 PM, olcott wrote:
On 3/30/2025 7:32 PM, Richard Damon wrote:
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:That completely depends on who has verified it.
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote:
On 3/29/2025 2:26 PM, dbush wrote:And therefore does not do a correct UTM simulation >>>>>>>>>>>>>>>>>> that matches the behavior of the direct execution as >>>>>>>>>>>>>>>>>> it is incomplete.
On 3/29/2025 3:22 PM, olcott wrote:
On 3/29/2025 2:06 PM, dbush wrote:
On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>It is not impossible to adapt a UTM such that it >>>>>>>>>>>>>>>>>>>>> correctly simulates a finite number of steps of an >>>>>>>>>>>>>>>>>>>>> input.
In other words, you deny the concept of a UTM, >>>>>>>>>>>>>>>>>>>>>>>> which can take a description of any Turing >>>>>>>>>>>>>>>>>>>>>>>> machine and exactly reproduce the behavior of >>>>>>>>>>>>>>>>>>>>>>>> the direct execution.It defines that it must compute the mapping from >>>>>>>>>>>>>>>>>>>>>>>>>>> the direct execution of a Turing Machine >>>>>>>>>>>>>>>>>>>>>>>>>>Which does not require tracing an actual >>>>>>>>>>>>>>>>>>>>>>>>>> running TM, only mapping properties of the TM >>>>>>>>>>>>>>>>>>>>>>>>>> described.
The key fact that you continue to dishonestly >>>>>>>>>>>>>>>>>>>>>>>>> ignore
is the concrete counter-example that I provided >>>>>>>>>>>>>>>>>>>>>>>>> that
conclusively proves that the finite string of >>>>>>>>>>>>>>>>>>>>>>>>> machine
code input is not always a valid proxy for the >>>>>>>>>>>>>>>>>>>>>>>>> behavior
of the underlying virtual machine. >>>>>>>>>>>>>>>>>>>>>>>>
I deny that a pathological relationship between a >>>>>>>>>>>>>>>>>>>>>>> UTM and
its input can be correctly ignored. >>>>>>>>>>>>>>>>>>>>>>>
In such a case, the UTM will not halt, and neither >>>>>>>>>>>>>>>>>>>>>> will the input when executed directly. >>>>>>>>>>>>>>>>>>>>>
1) then you no longer have a UTM, so statements >>>>>>>>>>>>>>>>>>>> about a UTM don't apply
We can know that when this adapted UTM simulates a >>>>>>>>>>>>>>>>>>> finite number of steps of its input that this finite >>>>>>>>>>>>>>>>>>> number of steps were simulated correctly. >>>>>>>>>>>>>>>>>>
It is dishonest to expect non-terminating inputs to >>>>>>>>>>>>>>>>> complete.
An input that halts when executed directly is not non- >>>>>>>>>>>>>>>> terminating
2) changing the input is not allowed
The input is unchanged. There never was any >>>>>>>>>>>>>>>>>>> indication that the input was in any way changed. >>>>>>>>>>>>>>>>>>>
False, if the starting function calls UTM and UTM >>>>>>>>>>>>>>>>>> changes, you're changing the input.
When UTM1 is a UTM that has been adapted to only simulate >>>>>>>>>>>>>>>>> a finite number of steps
And is therefore no longer a UTM that does a correct and >>>>>>>>>>>>>>>> complete simulation
and input D calls UTM1 then the
behavior of D simulated by UTM1
Is not what I asked about. I asked about the behavior >>>>>>>>>>>>>>>> of D when executed directly.
Off topic for this thread.
UTM1 D DOES NOT HALT
UTM2 D HALTS
D is the same finite string in both cases.
No it isn't, not if it is the definition of a PROGRAM. >>>>>>>>>>>>>>
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The behavior that these machine code bytes specify:
558bec6872210000e853f4ffff83c4045dc3
as an input to HHH is different than these
same bytes as input to HHH1 as a verified fact.
Or, are you admitting you don't understand the meaning of >>>>>>>>>>>>>> a program?
It seems that you "just don't believe in" verified facts. >>>>>>>>>>>>>
No it does not. That is a stupid thing to say.
Every verified fact IS TRUE BY DEFINITION.
No, if the verifiers lies, then his "verification" isn't valid. >>>>>>>>>>
That is not the way semantic tautology works.
If the father of lies says that cats are animals
then cats are still animals.
Or, do you accept the verification by the election deniers >>>>>>>>>> that show that there was the possibility of the fraud,
There is a possibility that five minutes ago never existed.
Claiming that there was fraud when you know there was no
evidence of fraud might get you eternally incinerated.
A guess you have to or you are admitting yourself to be a
hypocrite.
If everyone can see that the way in which Olcott verifies >>>>>>>>>>>> his 'facts' is only a baseless claim, I do not believe in >>>>>>>>>>>> the verification. In particular when he does not fix the >>>>>>>>>>>> errors in the verification that were pointed out to him. >>>>>>>>>>>My claims are verified as true entirely on the basis
of the meaning of their words.
Nope, it is proved incorrect by the ACTUAL meaning of the
words you use, but then you LIE to yourself about what those >>>>>>>>>> words mean.
;
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES
IS A DAMNED LIAR OR STUPID.
How does HHH emulate the call to HHH instruction
The semantics of the x86 language.
Right, which were defined by INTEL, and requires the data emulated >>>>>> to be part of the input.
It is part of the input in the sense that HHH must
emulate itself emulating DDD. HHH it the test program
thus not the program-under-test. HHH is not asking does
itself halt? It was encoded to always halt for such
inputs. HHH is asking does this input specify that it
reaches its own final halt state?
So, you admit to your equivocation.
DDD is NOT a program, if it doesn't have a DEFINITE HHH as part of
it, and thus needs to be part of the input.
The C function DDD specifies non-halting behavior
to termination analyzer HHH because DDD calls HHH
in recursive emulation.
No, the C function DDD specifies no such behavior, as being a leaf
functions without it used function, it doesn't have behavior, it
behavior is officially UNDEFINED. (Read the C standard).
We can define that {cats} is a term-of-the-art for {dogs}.
The machine language specified by the C function species
a specific sequence of state changes defining the behavior
of this C function.
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote:
On 3/29/2025 2:26 PM, dbush wrote:
On 3/29/2025 3:22 PM, olcott wrote:
On 3/29/2025 2:06 PM, dbush wrote:
On 3/29/2025 3:03 PM, olcott wrote:
On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
An input that halts when executed directly is not non- >>>>>>>>>>>>>> terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>>>> finite number of stepsAnd is therefore no longer a UTM that does a correct and >>>>>>>>>>>>>> complete simulation
and input D calls UTM1 then the behavior of D simulated by >>>>>>>>>>>>>>> UTM1Is not what I asked about. I asked about the behavior of D >>>>>>>>>>>>>> when executed directly.
What does "specify to" mean? Which behaviour is correct?UTM1 D DOES NOT HALT UTM2 D HALTS D is the same finite string >>>>>>>>>>>>> in both cases.No it isn't, not if it is the definition of a PROGRAM.
The behavior that these machine code bytes specify:
558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>> different than these same bytes as input to HHH1 as a verified >>>>>>>>>>> fact.
It is part of the program under test, being called by it. That's whatIt is part of the input in the sense that HHH must emulate itselfRight, which were defined by INTEL, and requires the data emulated toThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH ITS >>>>>>> OWN FINAL HALT STATE.How does HHH emulate the call to HHH instruction
be part of the input.
emulating DDD. HHH it the test program thus not the program-under-test.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it reaches its
own final halt state?
Is it guessing based on your limited input that doesn't contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking outsde the
input to the function (since you say that above is the full input), or >>>> Are you admitting all of Halt7.c/obj as part of the input, and thus you >>>> hae a FIXED definition of HHH, which thus NEVER does a complete
emulation, and thus you can't say that the call to HHH is a complete
emulation.
How we we determine that DDD emulated by HHH cannot possibly reach its >>>>> final halt state?Nope, because if you admit to the first two lies, your HHH never was a >>>> valid decider,
Two recursive emulations provide correct inductive proof.
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
On 3/31/2025 6:15 AM, Richard Damon wrote:
On 3/30/25 10:35 PM, olcott wrote:
On 3/30/2025 7:40 PM, Richard Damon wrote:
On 3/30/25 6:17 PM, olcott wrote:
On 3/30/2025 4:59 PM, Mr Flibble wrote:
On Sun, 30 Mar 2025 16:56:37 -0500, olcott wrote:
On 3/30/2025 4:05 PM, Richard Damon wrote:
On 3/30/25 4:32 PM, olcott wrote:*THE ENTIRE SCOPE IS*
On 3/30/2025 1:52 PM, Richard Damon wrote:How is that DDD correctly emulated beyond the call HHH
On 3/30/25 2:27 PM, olcott wrote:_DDD()
On 3/30/2025 3:12 AM, joes wrote:Only because UTM1 isn't actually a UTM, but a LIE since it >>>>>>>>>> only does
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:UTM1 simulates D that calls UTM1 simulated D NEVER reaches final >>>>>>>>>>> halt state
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>> finiteWe can know that when this adapted UTM simulates a finite >>>>>>>>>>>>>>> numberAnd therefore does not do a correct UTM simulation that >>>>>>>>>>>>>> matches
of steps of its input that this finite number of steps were >>>>>>>>>>>>>>> simulated correctly.
the behavior of the direct execution as it is incomplete. >>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>>>
False, if the starting function calls UTM and UTM changes, >>>>>>>>>>>>>> you're2) changing the input is not allowedThe input is unchanged. There never was any indication >>>>>>>>>>>>>>> that the
input was in any way changed.
changing the input.
number of steps
and input D calls UTM1 then the behavior of D simulated by >>>>>>>>>>>>> UTM1Doesn't matter if it calls it, but if the UTM halts.
never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call >>>>>>>>>>>>> Then D
reaches its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM2 simulates D that calls UTM1 simulated D ALWAYS reaches >>>>>>>>>>> final
halt state
a partial simulation, not a complete as REQURIED by the
definition of
a UTM.
[00002172] 55 push ebp ; housekeeping [00002173]
8bec mov ebp,esp ; housekeeping [00002175] 6872210000 push
00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
[0000217f] 83c404 add esp,+04 [00002182] 5d pop ebp
[00002183] c3 ret Size in bytes:(0018) [00002183] >>>>>>>>>
DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH >>>>>>>>> ITS OWN
FINAL HALT STATE.
THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES IS A DAMNED LIAR OR >>>>>>>>> STUPID.
instruction by a
program that is a pure function, and thus only looks at its input? >>>>>>>>
DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH
ITS OWN
FINAL HALT STATE.
If HHH determines this entirely from a psychotic break from
reality the
above sentence remains immutably true.
Will this ever stop? It is kind of depressing to watch.
/Flibble
I will stop bringing up this point and move
on to the next point when the three years of
consistent stonewalling on this point stops.
The problem is you are admitting that you are using a strawman, so
it is YOU that is stonewalling.
When HHH computes the mapping from its finite string
input to its own reject state it must do this by
applying finite string transformations to this input
to derive its output.
No, it only CAN do that, but to be correct, it needs to compute the
needed function, which has no requirement to be based on that sort
of criteria.
At least Rice knows that deciders must recognize semantic
properties encoded as finite strings.
In computability theory, Rice's theorem states that
all non-trivial semantic properties of programs are
undecidable. A semantic property is one about the
program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem
Right, and Rice's definition says it is the behavior of the PROGRAM
described to the decider. Not what the decider can figure out about
it, but the actual behavior of the program.
The actual behavior as a semantic property of the finite string input.
int sum (int x, int y) { return x + y; }
sum(2,3) cannot possibly figure out the sum of 5+3.
It is foolish to require a decider to report on
anything that it cannot not see.
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
On 3/31/2025 3:30 PM, joes wrote:
Am Mon, 31 Mar 2025 13:59:52 -0500 schrieb olcott:
On 3/31/2025 6:19 AM, Richard Damon wrote:
On 3/30/25 11:16 PM, olcott wrote:
On 3/30/2025 9:40 PM, Richard Damon wrote:
On 3/30/25 10:17 PM, olcott wrote:
On 3/30/2025 7:35 PM, Richard Damon wrote:
On 3/30/25 5:56 PM, olcott wrote:
On 3/30/2025 4:05 PM, Richard Damon wrote:
On 3/30/25 4:32 PM, olcott wrote:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote:
You missed something here.It is dishonest to expect non-terminating inputs to >>>>>>>>>>>>>>> complete.A complete simulation of a nonterminating input doesn't halt.
And here.When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>>>> finite number of stepsSo not an UTM.
Only if HHH is not a decider.and input D calls UTM1 then the behavior of D simulated by >>>>>>>>>>>>>>> UTM1 never reaches its final halt state.Doesn't matter if it calls it, but if the UTM halts.
When D is simulated by ordinary UTM2 that D does not call >>>>>>>>>>>>>>> Then D reaches its final halt state.
Only because UTM1 isn't actually a UTM, but a LIE since it only >>>>>>>>>>>> does a partial simulation, not a complete as REQURIED by the >>>>>>>>>>>> definition of a UTM.UTM1 simulates D that calls UTM1 simulated D NEVER reaches >>>>>>>>>>>>> final halt stateI never changed the input. D always calls UTM1.You changed UTM1, which is part of the input D.
thus is the same input to UTM1 as it is to UTM2.
UTM2 simulates D that calls UTM1 simulated D ALWAYS reaches >>>>>>>>>>>>> final halt state
DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH >>>>>>>>>>> ITS OWN FINAL HALT STATE.
You have, only you. We asked your for other steps.How is that DDD correctly emulated beyond the call HHH*THE ENTIRE SCOPE IS*
instruction by a program that is a pure function, and thus only >>>>>>>>>> looks at its input?
DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH ITS >>>>>>>>> OWN FINAL HALT STATE.
From where? Remember, the Halting problem is SPECIFICALLY
OFF F-CKING TOPIC. WE ABOUT ONE F-CKING STEP OF MY PROOF.
WE HAVE BEEN TALKING ABOUT ONE F-CKING STEP OF MY PROOF FOR THREE >>>>>>> F-CKING YEARS.
Not correct is returning the wrong value. It should just say "I can'tOf course it doesn't CORRECTLY emulate itself emulating DDD (andDDD correctly emulated by HHH DOES NOT F-CKING HALT !!!Your proof is just off topic ranting.
The problem is that DDD is NOT correctly emulated by HHH,
You are a damned liar when you try to get away with implying that HHH >>>>> does not emulate itself emulating DDD in recursive emulation according >>>>> to the semantics of the x86 language.
omitting that CORRECTLY is a key point to your fraud), as it stops part >>>> way, and CORRECT emulation that determines behavior doesn't stop until >>>> the end is reached.
It is ALWAYS CORRECT for any simulating termination analyzer to stop
simulating and reject any input that would otherwise prevent its own
termination.
simulate it, but it halts". I don't care about a supposed simulator
that does not say anything about the direct execution.
int sum(int x, int y) { return x + y; }
The property of the input sum(3,2) is 5.
We can incorrectly expect sum(2,3) to return 7.
Halting is a semantic property of an input
it is never any property of any non-input.
On 3/31/2025 6:19 AM, Richard Damon wrote:
On 3/30/25 11:16 PM, olcott wrote:
On 3/30/2025 9:40 PM, Richard Damon wrote:
On 3/30/25 10:17 PM, olcott wrote:
On 3/30/2025 7:35 PM, Richard Damon wrote:
On 3/30/25 5:56 PM, olcott wrote:
On 3/30/2025 4:05 PM, Richard Damon wrote:
On 3/30/25 4:32 PM, olcott wrote:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>> finiteWe can know that when this adapted UTM simulates a finite >>>>>>>>>>>>>>> number ofAnd therefore does not do a correct UTM simulation that >>>>>>>>>>>>>> matches the
steps of its input that this finite number of steps were >>>>>>>>>>>>>>> simulated
correctly.
behavior of the direct execution as it is incomplete. >>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>>>
False, if the starting function calls UTM and UTM changes, >>>>>>>>>>>>>> you're2) changing the input is not allowedThe input is unchanged. There never was any indication >>>>>>>>>>>>>>> that the input
was in any way changed.
changing the input.
number of steps
and input D calls UTM1 then the behavior of D simulated >>>>>>>>>>>>> by UTM1 never reaches its final halt state.Doesn't matter if it calls it, but if the UTM halts.
When D is simulated by ordinary UTM2 that D does not call >>>>>>>>>>>>> Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it >>>>>>>>>> only does a partial simulation, not a complete as REQURIED by >>>>>>>>>> the definition of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES
IS A DAMNED LIAR OR STUPID.
How is that DDD correctly emulated beyond the call HHH
instruction by a program that is a pure function, and thus only >>>>>>>> looks at its input?
*THE ENTIRE SCOPE IS*
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
From where? Remember, the Halting problem is SPECIFICALLY
OFF F-CKING TOPIC. WE ABOUT ONE F-CKING STEP OF MY PROOF.
WE HAVE BEEN TALKING ABOUT ONE F-CKING STEP OF MY PROOF
FOR THREE F-CKING YEARS.
DDD correctly emulated by HHH DOES NOT F-CKING HALT !!!
Your proof is just off topic ranting.
The problem is that DDD is NOT correctly emulated by HHH,
You are a damned liar when you try to get away
with implying that HHH does not emulate itself
emulating DDD in recursive emulation according
to the semantics of the x86 language.
Of course it doesn't CORRECTLY emulate itself emulating DDD (and
omitting that CORRECTLY is a key point to your fraud), as it stops
part way, and CORRECT emulation that determines behavior doesn't stop
until the end is reached.
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
On 3/31/2025 3:26 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 22:32 schreef olcott:
On 3/30/2025 1:52 PM, Richard Damon wrote:But we all agree that HHH fails to reach the end of the simulation of
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:A complete simulation of a nonterminating input doesn't halt.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete.We can know that when this adapted UTM simulates a finiteAnd therefore does not do a correct UTM simulation that matches the >>>>>>>> behavior of the direct execution as it is incomplete.
number of
steps of its input that this finite number of steps were simulated >>>>>>>>> correctly.
So not an UTM.When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that the >>>>>>>>> input
was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then D >>>>>>> reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only does
a partial simulation, not a complete as REQURIED by the definition
of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES
IS A DAMNED LIAR OR STUPID.
this finite recursion. An end that exists as proven by direct
execution and world class simulators. Why repeating this agreement as
if someone denies it?
If you want me to respond to any other your replies
you have to quit playing trollish head games.
HHH DOES NOT FAIL YOU KNOWINGLY LIE ABOUT THIS !!!
Because DDD calls HHH(DDD) in recursive emulation
DDD EMULATED BY HHH CANNOT POSSIIBLY HALT.
On 3/31/2025 3:33 PM, joes wrote:
Am Mon, 31 Mar 2025 13:13:04 -0500 schrieb olcott:
On 3/31/2025 3:26 AM, Fred. Zwarts wrote:That is the failure.
But we all agree that HHH fails to reach the end of the simulation of
this finite recursion. An end that exists as proven by direct execution >>>> and world class simulators. Why repeating this agreement as if someone >>>> denies it?
Because DDD calls HHH(DDD) in recursive emulation DDD EMULATED BY HHH
CANNOT POSSIIBLY HALT.
Non-halting is always construed as the failure of the input.
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:A complete simulation of a nonterminating input doesn't halt.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete.We can know that when this adapted UTM simulates a finiteAnd therefore does not do a correct UTM simulation that matches the >>>>>>>> behavior of the direct execution as it is incomplete.
number of
steps of its input that this finite number of steps were simulated >>>>>>>>> correctly.
So not an UTM.When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that the >>>>>>>>> input
was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then D >>>>>>> reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only does
a partial simulation, not a complete as REQURIED by the definition
of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86,
the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote:
On 3/29/2025 2:26 PM, dbush wrote:
On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
An input that halts when executed directly is not non- >>>>>>>>>>>>>>>>>> terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only >>>>>>>>>>>>>>>>>>> simulate aAnd is therefore no longer a UTM that does a correct and >>>>>>>>>>>>>>>>>> complete simulation
finite number of steps
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the behavior >>>>>>>>>>>>>>>>>> of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct?UTM1 D DOES NOT HALT UTM2 D HALTS D is the same finite >>>>>>>>>>>>>>>>> stringNo it isn't, not if it is the definition of a PROGRAM.
in both cases.
The behavior that these machine code bytes specify: >>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>>>>>> different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>> verified
fact.
It is part of the program under test, being called by it. That's what >>>>>> you call a pathological relationship.It is part of the input in the sense that HHH must emulate itself >>>>>>> emulating DDD. HHH it the test program thus not the program-Right, which were defined by INTEL, and requires the dataThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY >>>>>>>>>>> REACH ITSHow does HHH emulate the call to HHH instruction
OWN FINAL HALT STATE.
emulated to
be part of the input.
under- test.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it
reaches its
own final halt state?
Is it guessing based on your limited input that doesn't contain the >>>>>>>> code at 000015d2, or
Is it admitting to not being a pure function, by looking outsde the >>>>>>>> input to the function (since you say that above is the full
input), or
Are you admitting all of Halt7.c/obj as part of the input, and >>>>>>>> thus you
hae a FIXED definition of HHH, which thus NEVER does a complete >>>>>>>> emulation, and thus you can't say that the call to HHH is a
complete
emulation.
How we we determine that DDD emulated by HHH cannot possibly >>>>>>>>> reach itsNope, because if you admit to the first two lies, your HHH never >>>>>>>> was a
final halt state?
Two recursive emulations provide correct inductive proof.
valid decider,
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH and
DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is changed.
No, it is YOUR misconception. The algorithm DDD consists of the
function DDD, the function HHH, and everything that HHH calls down to
the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level. The ONLY difference is that DDD
does not call HHH1(DDD) in recursive emulation.
On 3/31/2025 7:25 PM, dbush wrote:
On 3/31/2025 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
An input that halts when executed directly is not non- >>>>>>>>>>>>>>>>>>>> terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only >>>>>>>>>>>>>>>>>>>>> simulate aAnd is therefore no longer a UTM that does a correct >>>>>>>>>>>>>>>>>>>> and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct?The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>>>>>>>> different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>>>> verifiedUTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a PROGRAM. >>>>>>>>
in both cases.
fact.
It is part of the program under test, being called by it. That's >>>>>>>> whatIt is part of the input in the sense that HHH must emulate itself >>>>>>>>> emulating DDD. HHH it the test program thus not the program- >>>>>>>>> under- test.Right, which were defined by INTEL, and requires the dataThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY >>>>>>>>>>>>> REACH ITSHow does HHH emulate the call to HHH instruction
OWN FINAL HALT STATE.
emulated to
be part of the input.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it
reaches its
own final halt state?
Is it guessing based on your limited input that doesn't
contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking
outsde the
input to the function (since you say that above is the full >>>>>>>>>> input), or
Are you admitting all of Halt7.c/obj as part of the input, and >>>>>>>>>> thus you
hae a FIXED definition of HHH, which thus NEVER does a complete >>>>>>>>>> emulation, and thus you can't say that the call to HHH is a >>>>>>>>>> complete
emulation.
How we we determine that DDD emulated by HHH cannot possibly >>>>>>>>>>> reach itsvalid decider,
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>> Nope, because if you admit to the first two lies, your HHH >>>>>>>>>> never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH
and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is changed. >>>>>
No, it is YOUR misconception. The algorithm DDD consists of the
function DDD, the function HHH, and everything that HHH calls down
to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.
So you agree that the input to both is the immutable code of the
function DDD, the immutable code of the function HHH, and the
immutable code of everything that HHH calls down to the OS level.
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.
Which means it is strictly forbidden to have or hypothesize different
implementations for any of them.
And when that complete immutable code is executed by the semantics of
the x86 programming language, it will halt.
The input to HHH(DDD) cannot possibly halt
and the exact same input to HHH1(DDD) halts
because DDD only calls HHH(DDD) in recursive emulation.
On 3/31/2025 7:28 PM, Richard Damon wrote:
On 3/31/25 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
An input that halts when executed directly is not non- >>>>>>>>>>>>>>>>>>>> terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only >>>>>>>>>>>>>>>>>>>>> simulate aAnd is therefore no longer a UTM that does a correct >>>>>>>>>>>>>>>>>>>> and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct?The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>>>>>>>> different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>>>> verifiedUTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a PROGRAM. >>>>>>>>
in both cases.
fact.
It is part of the program under test, being called by it. That's >>>>>>>> whatIt is part of the input in the sense that HHH must emulate itself >>>>>>>>> emulating DDD. HHH it the test program thus not the program- >>>>>>>>> under- test.Right, which were defined by INTEL, and requires the dataThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY >>>>>>>>>>>>> REACH ITSHow does HHH emulate the call to HHH instruction
OWN FINAL HALT STATE.
emulated to
be part of the input.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it
reaches its
own final halt state?
Is it guessing based on your limited input that doesn't
contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking
outsde the
input to the function (since you say that above is the full >>>>>>>>>> input), or
Are you admitting all of Halt7.c/obj as part of the input, and >>>>>>>>>> thus you
hae a FIXED definition of HHH, which thus NEVER does a complete >>>>>>>>>> emulation, and thus you can't say that the call to HHH is a >>>>>>>>>> complete
emulation.
How we we determine that DDD emulated by HHH cannot possibly >>>>>>>>>>> reach itsvalid decider,
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>> Nope, because if you admit to the first two lies, your HHH >>>>>>>>>> never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH
and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is changed. >>>>>
No, it is YOUR misconception. The algorithm DDD consists of the
function DDD, the function HHH, and everything that HHH calls down
to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level. The ONLY difference is that DDD
does not call HHH1(DDD) in recursive emulation.
So?
What difference does that make that the actual instruction level?
What instruction behaved differently, at the processor level as
defined by INTEL, between the two paths.
HHH emulates itself emulating DDD and HHH1 does not
emulate itself emulating DDD because DDD calls HHH(DDD)
in recursive emulation and does not call HHH1 at all.
You are just proving you are nothing but a pathological liar that just
doesn't know what he is talking about.
On 3/31/2025 8:03 PM, dbush wrote:
On 3/31/2025 8:56 PM, olcott wrote:
On 3/31/2025 7:25 PM, dbush wrote:
On 3/31/2025 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>
An input that halts when executed directly is not >>>>>>>>>>>>>>>>>>>>>> non-
terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only >>>>>>>>>>>>>>>>>>>>>>> simulate aAnd is therefore no longer a UTM that does a >>>>>>>>>>>>>>>>>>>>>> correct and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct?The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to >>>>>>>>>>>>>>>>>>> HHH isUTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a PROGRAM. >>>>>>>>>>
in both cases.
different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>>>>>> verified
fact.
It is part of the program under test, being called by it.It is part of the input in the sense that HHH must emulate >>>>>>>>>>> itselfRight, which were defined by INTEL, and requires the data >>>>>>>>>>>> emulated toThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY >>>>>>>>>>>>>>> REACH ITSHow does HHH emulate the call to HHH instruction
OWN FINAL HALT STATE.
be part of the input.
emulating DDD. HHH it the test program thus not the program- >>>>>>>>>>> under- test.
That's what
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it >>>>>>>>>>> reaches its
own final halt state?
Is it guessing based on your limited input that doesn't >>>>>>>>>>>> contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking >>>>>>>>>>>> outsde the
input to the function (since you say that above is the full >>>>>>>>>>>> input), or
Are you admitting all of Halt7.c/obj as part of the input, >>>>>>>>>>>> and thus you
hae a FIXED definition of HHH, which thus NEVER does a complete >>>>>>>>>>>> emulation, and thus you can't say that the call to HHH is a >>>>>>>>>>>> complete
emulation.
How we we determine that DDD emulated by HHH cannotvalid decider,
possibly reach its
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>>>> Nope, because if you admit to the first two lies, your HHH >>>>>>>>>>>> never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH >>>>>>>> and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is
changed.
No, it is YOUR misconception. The algorithm DDD consists of the
function DDD, the function HHH, and everything that HHH calls down >>>>>> to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.
So you agree that the input to both is the immutable code of the
function DDD, the immutable code of the function HHH, and the
immutable code of everything that HHH calls down to the OS level.
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.
False. The function DDD by itself is not a program. The function
DDD, the function HHH, and everything that HHH calls down the OS level
are *all* under test.
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
The only rebuttal to this is rejecting the notion
that deciders must always halt.
On 3/31/2025 8:39 PM, dbush wrote:
On 3/31/2025 9:26 PM, olcott wrote:
On 3/31/2025 8:03 PM, dbush wrote:
On 3/31/2025 8:56 PM, olcott wrote:
On 3/31/2025 7:25 PM, dbush wrote:
On 3/31/2025 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 30.mrt.2025 om 04:35 schreef olcott: >>>>>>>>>>>>>>>>>>>>> On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 5:08 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 5:46 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>>>
An input that halts when executed directly is >>>>>>>>>>>>>>>>>>>>>>>> not non-
terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to >>>>>>>>>>>>>>>>>>>>>>>>> only simulate aAnd is therefore no longer a UTM that does a >>>>>>>>>>>>>>>>>>>>>>>> correct and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct? >>>>>>>>>>>>UTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a >>>>>>>>>>>>>>>>>>>>>> PROGRAM.
in both cases.
The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to >>>>>>>>>>>>>>>>>>>>> HHH is
different than these same bytes as input to HHH1 as >>>>>>>>>>>>>>>>>>>>> a verified
fact.
It is part of the program under test, being called by it. >>>>>>>>>>>> That's whatIt is part of the input in the sense that HHH must emulate >>>>>>>>>>>>> itselfRight, which were defined by INTEL, and requires the data >>>>>>>>>>>>>> emulated toDDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT >>>>>>>>>>>>>>>>> POSSIBLY REACH ITSHow does HHH emulate the call to HHH instruction >>>>>>>>>>>>>>> The semantics of the x86 language.
OWN FINAL HALT STATE.
be part of the input.
emulating DDD. HHH it the test program thus not the
program- under- test.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it >>>>>>>>>>>>> reaches its
own final halt state?
Is it guessing based on your limited input that doesn't >>>>>>>>>>>>>> contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking >>>>>>>>>>>>>> outsde the
input to the function (since you say that above is the >>>>>>>>>>>>>> full input), or
Are you admitting all of Halt7.c/obj as part of the input, >>>>>>>>>>>>>> and thus you
hae a FIXED definition of HHH, which thus NEVER does a >>>>>>>>>>>>>> complete
emulation, and thus you can't say that the call to HHH is >>>>>>>>>>>>>> a complete
emulation.
How we we determine that DDD emulated by HHH cannot >>>>>>>>>>>>>>> possibly reach itsvalid decider,
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>>>>>> Nope, because if you admit to the first two lies, your HHH >>>>>>>>>>>>>> never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with >>>>>>>>>> HHH and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is >>>>>>>>> changed.
No, it is YOUR misconception. The algorithm DDD consists of the >>>>>>>> function DDD, the function HHH, and everything that HHH calls
down to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.
So you agree that the input to both is the immutable code of the
function DDD, the immutable code of the function HHH, and the
immutable code of everything that HHH calls down to the OS level.
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.
False. The function DDD by itself is not a program. The function
DDD, the function HHH, and everything that HHH calls down the OS
level are *all* under test.
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Repeat of previously refuted point:
On 3/31/2025 6:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:DDD.
It is ALWAYS CORRECT for any simulating termination;
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
;
;
Except when doing so changes the input, as is the case with HHH and
;
Changing the input is not allowed.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:A complete simulation of a nonterminating input doesn't halt.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete.We can know that when this adapted UTM simulates a finite number of >>>>>>>>> steps of its input that this finite number of steps were simulated >>>>>>>>> correctly.And therefore does not do a correct UTM simulation that matches the >>>>>>>> behavior of the direct execution as it is incomplete.
So not an UTM.When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that the input >>>>>>>>> was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only does a >>>> partial simulation, not a complete as REQURIED by the definition of a
UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86,
the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote:
On 3/29/2025 2:26 PM, dbush wrote:
On 3/29/2025 3:22 PM, olcott wrote:
On 3/29/2025 2:06 PM, dbush wrote:
On 3/29/2025 3:03 PM, olcott wrote:
On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
An input that halts when executed directly is not non- >>>>>>>>>>>>>> terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>>>> finite number of stepsAnd is therefore no longer a UTM that does a correct and >>>>>>>>>>>>>> complete simulation
and input D calls UTM1 then the behavior of D simulated by >>>>>>>>>>>>>>> UTM1Is not what I asked about. I asked about the behavior of D >>>>>>>>>>>>>> when executed directly.
What does "specify to" mean? Which behaviour is correct?UTM1 D DOES NOT HALT UTM2 D HALTS D is the same finite string >>>>>>>>>>>>> in both cases.No it isn't, not if it is the definition of a PROGRAM.
The behavior that these machine code bytes specify:
558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>> different than these same bytes as input to HHH1 as a verified >>>>>>>>>>> fact.
It is part of the program under test, being called by it. That's whatIt is part of the input in the sense that HHH must emulate itselfRight, which were defined by INTEL, and requires the data emulated toThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH ITS >>>>>>> OWN FINAL HALT STATE.How does HHH emulate the call to HHH instruction
be part of the input.
emulating DDD. HHH it the test program thus not the program-under-test.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it reaches its
own final halt state?
Is it guessing based on your limited input that doesn't contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking outsde the
input to the function (since you say that above is the full input), or >>>> Are you admitting all of Halt7.c/obj as part of the input, and thus you >>>> hae a FIXED definition of HHH, which thus NEVER does a complete
emulation, and thus you can't say that the call to HHH is a complete
emulation.
How we we determine that DDD emulated by HHH cannot possibly reach its >>>>> final halt state?Nope, because if you admit to the first two lies, your HHH never was a >>>> valid decider,
Two recursive emulations provide correct inductive proof.
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
On 3/31/2025 9:48 PM, dbush wrote:
On 3/31/2025 10:38 PM, olcott wrote:
HHH must report on the behavior that its input
actually specifies.
And the input specifies an algorithm that halts when executed directly.
Which is NOT how it is executed.
It IS executed with recursive emulation.
This seems way too difficult
for people that can only spout off words that
they learned by rote, with no actual understanding
of the underlying principles involved.
Every actual computation can only transform input
finite strings into outputs. HHH does do this.
But not as per the requirements:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
The "requirements" that you mindlessly spout off
Which would make all true statements provable if they could be met.
violate this foundational principle of functions
computed by Turing machines.
Which just says that no Turing machine satisfies those requirements,
as Linz and others proved.
int sum(int x, int y)
{
return 5;
}
sum(2,3) does not compute the sum of 2 + 3.
It absolutely does. There are *NO* requirements on the
implementation, only the result.
Unless and algorithm transforms its inputs
into its outputs it is not a Turing computable
function.
On 3/31/2025 9:26 PM, dbush wrote:
On 3/31/2025 10:12 PM, olcott wrote:
On 3/31/2025 8:39 PM, dbush wrote:
On 3/31/2025 9:26 PM, olcott wrote:
On 3/31/2025 8:03 PM, dbush wrote:
On 3/31/2025 8:56 PM, olcott wrote:
On 3/31/2025 7:25 PM, dbush wrote:
On 3/31/2025 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 3/30/2025 7:32 PM, Richard Damon wrote:
Yes, HHH is off the topic of deciding halting.On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 30.mrt.2025 om 04:35 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 5:08 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 5:46 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>>>>>
An input that halts when executed directly is >>>>>>>>>>>>>>>>>>>>>>>>>> not non-
terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to >>>>>>>>>>>>>>>>>>>>>>>>>>> only simulate aAnd is therefore no longer a UTM that does a >>>>>>>>>>>>>>>>>>>>>>>>>> correct and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct? >>>>>>>>>>>>>>UTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a >>>>>>>>>>>>>>>>>>>>>>>> PROGRAM.
in both cases.
The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input >>>>>>>>>>>>>>>>>>>>>>> to HHH is
different than these same bytes as input to HHH1 >>>>>>>>>>>>>>>>>>>>>>> as a verified
fact.
It is part of the program under test, being called by it. >>>>>>>>>>>>>> That's whatIt is part of the input in the sense that HHH must >>>>>>>>>>>>>>> emulate itselfRight, which were defined by INTEL, and requires the >>>>>>>>>>>>>>>> data emulated toDDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT >>>>>>>>>>>>>>>>>>> POSSIBLY REACH ITSHow does HHH emulate the call to HHH instruction >>>>>>>>>>>>>>>>> The semantics of the x86 language.
OWN FINAL HALT STATE.
be part of the input.
emulating DDD. HHH it the test program thus not the >>>>>>>>>>>>>>> program- under- test.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that >>>>>>>>>>>>>>> it reaches its
own final halt state?
Is it guessing based on your limited input that doesn't >>>>>>>>>>>>>>>> contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking >>>>>>>>>>>>>>>> outsde the
input to the function (since you say that above is the >>>>>>>>>>>>>>>> full input), or
Are you admitting all of Halt7.c/obj as part of the >>>>>>>>>>>>>>>> input, and thus you
hae a FIXED definition of HHH, which thus NEVER does a >>>>>>>>>>>>>>>> complete
emulation, and thus you can't say that the call to HHH >>>>>>>>>>>>>>>> is a complete
emulation.
How we we determine that DDD emulated by HHH cannot >>>>>>>>>>>>>>>>> possibly reach itsvalid decider,
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>>>>>>>> Nope, because if you admit to the first two lies, your >>>>>>>>>>>>>>>> HHH never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with >>>>>>>>>>>> HHH and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is >>>>>>>>>>> changed.
No, it is YOUR misconception. The algorithm DDD consists of >>>>>>>>>> the function DDD, the function HHH, and everything that HHH >>>>>>>>>> calls down to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.
So you agree that the input to both is the immutable code of the >>>>>>>> function DDD, the immutable code of the function HHH, and the
immutable code of everything that HHH calls down to the OS level. >>>>>>>>
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.
False. The function DDD by itself is not a program. The function >>>>>> DDD, the function HHH, and everything that HHH calls down the OS
level are *all* under test.
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Repeat of previously refuted point:
On 3/31/2025 6:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:and DDD.
It is ALWAYS CORRECT for any simulating termination;
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
;
;
Except when doing so changes the input, as is the case with HHH
;
Changing the input is not allowed.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
Which is also a previously refuted point.
This means you agree that the input to both is the same, i.e. the
algorithm DDD, and therefore must be reported the same as per the
requirements:
HHH must report on the behavior that its input
actually specifies. This seems way too difficult
for people that can only spout off words that
they learned by rote, with no actual understanding
of the underlying principles involved.
Every actual computation can only transform input
finite strings into outputs. HHH does do this.
The "requirements" that you mindlessly spout off
violate this foundational principle of functions
computed by Turing machines.
int sum(int x, int y)
{
return 5;
}
sum(2,3) does not compute the sum of 2 + 3.
On 3/31/2025 10:02 PM, dbush wrote:
On 3/31/2025 10:57 PM, olcott wrote:
On 3/31/2025 9:48 PM, dbush wrote:
On 3/31/2025 10:38 PM, olcott wrote:
HHH must report on the behavior that its input
actually specifies.
And the input specifies an algorithm that halts when executed directly. >>>>
Which is NOT how it is executed.
But IS what it is required to report on.
It IS executed with recursive emulation.
Finitely recursive emulation, which is part of the algorithm DDD that
halts.
This seems way too difficult
for people that can only spout off words that
they learned by rote, with no actual understanding
of the underlying principles involved.
Every actual computation can only transform input
finite strings into outputs. HHH does do this.
But not as per the requirements:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
The "requirements" that you mindlessly spout off
Which would make all true statements provable if they could be met.
violate this foundational principle of functions
computed by Turing machines.
Which just says that no Turing machine satisfies those requirements,
as Linz and others proved.
int sum(int x, int y)
{
return 5;
}
sum(2,3) does not compute the sum of 2 + 3.
It absolutely does. There are *NO* requirements on the
implementation, only the result.
Unless and algorithm transforms its inputs
into its outputs it is not a Turing computable
function.
The only requirements of an algorithm are to generate the results of a
mapping. How that is accomplished is irrelevant.
It may have been historically considered irrelevant.
When it comes down to determining that mere guesses
are not any sort of: "computing the mapping" then it
does become relevant.
On 3/31/2025 10:02 PM, dbush wrote:
The only requirements of an algorithm are to generate the results of
a mapping. How that is accomplished is irrelevant.
It may have been historically considered irrelevant.
When it comes down to determining that mere guesses
are not any sort of: "computing the mapping" then it
does become relevant.
On 3/31/2025 7:28 PM, Richard Damon wrote:That is not an answer. Which instruction was simulated differently by
On 3/31/25 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote:
On 3/29/2025 3:14 PM, dbush wrote:
On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote:
An input that halts when executed directly is not non- >>>>>>>>>>>>>>>>>>>> terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only >>>>>>>>>>>>>>>>>>>>> simulate aAnd is therefore no longer a UTM that does a correct >>>>>>>>>>>>>>>>>>>> and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct?The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>>>>>>>> different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>>>> verifiedUTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a PROGRAM. >>>>>>>>
in both cases.
fact.
It is part of the program under test, being called by it. That's >>>>>>>> whatIt is part of the input in the sense that HHH must emulate itself >>>>>>>>> emulating DDD. HHH it the test program thus not the program- >>>>>>>>> under- test.Right, which were defined by INTEL, and requires the dataThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY >>>>>>>>>>>>> REACH ITSHow does HHH emulate the call to HHH instruction
OWN FINAL HALT STATE.
emulated to
be part of the input.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it
reaches its
own final halt state?
Is it guessing based on your limited input that doesn't
contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking
outsde the
input to the function (since you say that above is the full >>>>>>>>>> input), or
Are you admitting all of Halt7.c/obj as part of the input, and >>>>>>>>>> thus you
hae a FIXED definition of HHH, which thus NEVER does a complete >>>>>>>>>> emulation, and thus you can't say that the call to HHH is a >>>>>>>>>> complete
emulation.
How we we determine that DDD emulated by HHH cannot possibly >>>>>>>>>>> reach itsvalid decider,
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>> Nope, because if you admit to the first two lies, your HHH >>>>>>>>>> never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH
and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is changed. >>>>>
No, it is YOUR misconception. The algorithm DDD consists of the
function DDD, the function HHH, and everything that HHH calls down
to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level. The ONLY difference is that DDD
does not call HHH1(DDD) in recursive emulation.
So?
What difference does that make that the actual instruction level?
What instruction behaved differently, at the processor level as
defined by INTEL, between the two paths.
HHH emulates itself emulating DDD and HHH1 does not
emulate itself emulating DDD because DDD calls HHH(DDD)
in recursive emulation and does not call HHH1 at all.
On 3/31/2025 8:03 PM, dbush wrote:
On 3/31/2025 8:56 PM, olcott wrote:
On 3/31/2025 7:25 PM, dbush wrote:
On 3/31/2025 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:Yes, HHH is off the topic of deciding halting.
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
On 3/29/2025 5:46 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>
An input that halts when executed directly is not >>>>>>>>>>>>>>>>>>>>>> non-
terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to only >>>>>>>>>>>>>>>>>>>>>>> simulate aAnd is therefore no longer a UTM that does a >>>>>>>>>>>>>>>>>>>>>> correct and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct?The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to >>>>>>>>>>>>>>>>>>> HHH isUTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a PROGRAM. >>>>>>>>>>
in both cases.
different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>>>>>> verified
fact.
It is part of the program under test, being called by it.It is part of the input in the sense that HHH must emulate >>>>>>>>>>> itselfRight, which were defined by INTEL, and requires the data >>>>>>>>>>>> emulated toThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY >>>>>>>>>>>>>>> REACH ITSHow does HHH emulate the call to HHH instruction
OWN FINAL HALT STATE.
be part of the input.
emulating DDD. HHH it the test program thus not the program- >>>>>>>>>>> under- test.
That's what
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that it >>>>>>>>>>> reaches its
own final halt state?
Is it guessing based on your limited input that doesn't >>>>>>>>>>>> contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking >>>>>>>>>>>> outsde the
input to the function (since you say that above is the full >>>>>>>>>>>> input), or
Are you admitting all of Halt7.c/obj as part of the input, >>>>>>>>>>>> and thus you
hae a FIXED definition of HHH, which thus NEVER does a complete >>>>>>>>>>>> emulation, and thus you can't say that the call to HHH is a >>>>>>>>>>>> complete
emulation.
How we we determine that DDD emulated by HHH cannotvalid decider,
possibly reach its
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>>>> Nope, because if you admit to the first two lies, your HHH >>>>>>>>>>>> never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with HHH >>>>>>>> and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is
changed.
No, it is YOUR misconception. The algorithm DDD consists of the
function DDD, the function HHH, and everything that HHH calls down >>>>>> to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.
So you agree that the input to both is the immutable code of the
function DDD, the immutable code of the function HHH, and the
immutable code of everything that HHH calls down to the OS level.
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.
False. The function DDD by itself is not a program. The function
DDD, the function HHH, and everything that HHH calls down the OS level
are *all* under test.
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
The only rebuttal to this is rejecting the notion
that deciders must always halt.
On 3/31/2025 9:26 PM, dbush wrote:
On 3/31/2025 10:12 PM, olcott wrote:
On 3/31/2025 8:39 PM, dbush wrote:
On 3/31/2025 9:26 PM, olcott wrote:
On 3/31/2025 8:03 PM, dbush wrote:
On 3/31/2025 8:56 PM, olcott wrote:
On 3/31/2025 7:25 PM, dbush wrote:
On 3/31/2025 7:34 PM, olcott wrote:
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 3/30/2025 7:32 PM, Richard Damon wrote:
Yes, HHH is off the topic of deciding halting.On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>>>> Op 30.mrt.2025 om 04:35 schreef olcott: >>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 3/29/25 6:44 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 5:08 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 5:46 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>>>>>
An input that halts when executed directly is >>>>>>>>>>>>>>>>>>>>>>>>>> not non-
terminating
Off topic for this thread.When UTM1 is a UTM that has been adapted to >>>>>>>>>>>>>>>>>>>>>>>>>>> only simulate aAnd is therefore no longer a UTM that does a >>>>>>>>>>>>>>>>>>>>>>>>>> correct and
finite number of steps
complete simulation
and input D calls UTM1 then the behavior of D >>>>>>>>>>>>>>>>>>>>>>>>>>> simulated byIs not what I asked about. I asked about the >>>>>>>>>>>>>>>>>>>>>>>>>> behavior of D
UTM1
when executed directly.
What does "specify to" mean? Which behaviour is correct? >>>>>>>>>>>>>>UTM1 D DOES NOT HALT UTM2 D HALTS D is the same >>>>>>>>>>>>>>>>>>>>>>>>> finite stringNo it isn't, not if it is the definition of a >>>>>>>>>>>>>>>>>>>>>>>> PROGRAM.
in both cases.
The behavior that these machine code bytes specify: >>>>>>>>>>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input >>>>>>>>>>>>>>>>>>>>>>> to HHH is
different than these same bytes as input to HHH1 >>>>>>>>>>>>>>>>>>>>>>> as a verified
fact.
It is part of the program under test, being called by it. >>>>>>>>>>>>>> That's whatIt is part of the input in the sense that HHH must >>>>>>>>>>>>>>> emulate itselfRight, which were defined by INTEL, and requires the >>>>>>>>>>>>>>>> data emulated toDDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT >>>>>>>>>>>>>>>>>>> POSSIBLY REACH ITSHow does HHH emulate the call to HHH instruction >>>>>>>>>>>>>>>>> The semantics of the x86 language.
OWN FINAL HALT STATE.
be part of the input.
emulating DDD. HHH it the test program thus not the >>>>>>>>>>>>>>> program- under- test.
you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt forWhich it does (except when simulated by HHH).
such inputs. HHH is asking does this input specify that >>>>>>>>>>>>>>> it reaches its
own final halt state?
Is it guessing based on your limited input that doesn't >>>>>>>>>>>>>>>> contain the
code at 000015d2, or
Is it admitting to not being a pure function, by looking >>>>>>>>>>>>>>>> outsde the
input to the function (since you say that above is the >>>>>>>>>>>>>>>> full input), or
Are you admitting all of Halt7.c/obj as part of the >>>>>>>>>>>>>>>> input, and thus you
hae a FIXED definition of HHH, which thus NEVER does a >>>>>>>>>>>>>>>> complete
emulation, and thus you can't say that the call to HHH >>>>>>>>>>>>>>>> is a complete
emulation.
How we we determine that DDD emulated by HHH cannot >>>>>>>>>>>>>>>>> possibly reach itsvalid decider,
final halt state?
Two recursive emulations provide correct inductive proof. >>>>>>>>>>>>>>>> Nope, because if you admit to the first two lies, your >>>>>>>>>>>>>>>> HHH never was a
It is ALWAYS CORRECT for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Except when doing so changes the input, as is the case with >>>>>>>>>>>> HHH and DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is >>>>>>>>>>> changed.
No, it is YOUR misconception. The algorithm DDD consists of >>>>>>>>>> the function DDD, the function HHH, and everything that HHH >>>>>>>>>> calls down to the OS level.
We have already been over this.
HHH(DDD) and HHH1(DDD) have the same inputs all the way
down to the OS level.
So you agree that the input to both is the immutable code of the >>>>>>>> function DDD, the immutable code of the function HHH, and the
immutable code of everything that HHH calls down to the OS level. >>>>>>>>
It is the input in terms of the behavior of DDD emulated
by HHH, yet only DDD is the program-under-test.
False. The function DDD by itself is not a program. The function >>>>>> DDD, the function HHH, and everything that HHH calls down the OS
level are *all* under test.
*Simulating termination analyzer Principle*
It is always correct for any simulating termination
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
Repeat of previously refuted point:
On 3/31/2025 6:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:and DDD.
It is ALWAYS CORRECT for any simulating termination;
analyzer to stop simulating and reject any input
that would otherwise prevent its own termination.
;
;
Except when doing so changes the input, as is the case with HHH
;
Changing the input is not allowed.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
*I said this before*
The input to HHH(DDD) and HHH1(DDD) is the same
all the way down to the operating system level.
Which is also a previously refuted point.
This means you agree that the input to both is the same, i.e. the
algorithm DDD, and therefore must be reported the same as per the
requirements:
HHH must report on the behavior that its input
actually specifies.
On 3/31/2025 2:15 PM, Fred. Zwarts wrote:
Op 31.mrt.2025 om 20:13 schreef olcott:
On 3/31/2025 3:26 AM, Fred. Zwarts wrote:So agreeing with you is playing trollish head games?
Op 30.mrt.2025 om 22:32 schreef olcott:
On 3/30/2025 1:52 PM, Richard Damon wrote:But we all agree that HHH fails to reach the end of the simulation
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete. >>>>>>>> A complete simulation of a nonterminating input doesn't halt.We can know that when this adapted UTM simulates a finite >>>>>>>>>>> number ofAnd therefore does not do a correct UTM simulation that
steps of its input that this finite number of steps were >>>>>>>>>>> simulated
correctly.
matches the
behavior of the direct execution as it is incomplete.
When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that >>>>>>>>>>> the input
was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then >>>>>>>>> D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only
does a partial simulation, not a complete as REQURIED by the
definition of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES
IS A DAMNED LIAR OR STUPID.
of this finite recursion. An end that exists as proven by direct
execution and world class simulators. Why repeating this agreement
as if someone denies it?
If you want me to respond to any other your replies
you have to quit playing trollish head games.
That explains what you are doing.
Dishonestly twisting my words is not agreement.
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete. >>>>>>>> A complete simulation of a nonterminating input doesn't halt.We can know that when this adapted UTM simulates a finite >>>>>>>>>>> number ofAnd therefore does not do a correct UTM simulation that
steps of its input that this finite number of steps were >>>>>>>>>>> simulated
correctly.
matches the
behavior of the direct execution as it is incomplete.
When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that >>>>>>>>>>> the input
was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then >>>>>>>>> D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only
does a partial simulation, not a complete as REQURIED by the
definition of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86,
the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or
emulation.
Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.
When-so-ever a finite number of steps of x86 machine
code have been emulated according to the semantics
of the x86 language then these steps have been
emulated correctly even if God himself disagrees.
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete. >>>>>>>> A complete simulation of a nonterminating input doesn't halt.We can know that when this adapted UTM simulates a finite number of >>>>>>>>>>> steps of its input that this finite number of steps were simulated >>>>>>>>>>> correctly.And therefore does not do a correct UTM simulation that matches the >>>>>>>>>> behavior of the direct execution as it is incomplete.
When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that the input
was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only does a >>>>>> partial simulation, not a complete as REQURIED by the definition of a >>>>>> UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86,
the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or emulation.
Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.
On 4/1/2025 8:15 PM, Richard Damon wrote:
On 4/1/25 7:31 PM, olcott wrote:
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>We can know that when this adapted UTM simulates a finite >>>>>>>>>>>>> number ofAnd therefore does not do a correct UTM simulation that >>>>>>>>>>>> matches the
steps of its input that this finite number of steps were >>>>>>>>>>>>> simulated
correctly.
behavior of the direct execution as it is incomplete.
When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>> finiteFalse, if the starting function calls UTM and UTM changes, >>>>>>>>>>>> you're2) changing the input is not allowedThe input is unchanged. There never was any indication that >>>>>>>>>>>>> the input
was in any way changed.
changing the input.
number of steps
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call >>>>>>>>>>> Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only >>>>>>>> does a partial simulation, not a complete as REQURIED by the
definition of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86, >>>>>> the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or
emulation.
Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.
When-so-ever a finite number of steps of x86 machine
code have been emulated according to the semantics
of the x86 language then these steps have been
emulated correctly even if God himself disagrees.
And the number of times you have INCORRECTLY claimed that you partial
simulator did a correct emulation just shows how much of a liar you are.
Anyone that knows the C language knows that one recursive
emulation proves that DDD emulated by HHH cannot possibly
reach its final halt state in an infinite number of steps.
On 3/31/2025 3:33 PM, joes wrote:What the fuck. A halt *decider* is supposed to halt, even on non-halting inputs.
Am Mon, 31 Mar 2025 13:13:04 -0500 schrieb olcott:Non-halting is always construed as the failure of the input.
On 3/31/2025 3:26 AM, Fred. Zwarts wrote:That is the failure.
But we all agree that HHH fails to reach the end of the simulation ofBecause DDD calls HHH(DDD) in recursive emulation DDD EMULATED BY HHH
this finite recursion. An end that exists as proven by direct
execution and world class simulators. Why repeating this agreement as
if someone denies it?
CANNOT POSSIIBLY HALT.
On 3/31/2025 5:54 PM, dbush wrote:
On 3/31/2025 6:30 PM, olcott wrote:
On 3/31/2025 5:17 PM, dbush wrote:
On 3/31/2025 6:12 PM, olcott wrote:
On 3/31/2025 3:44 PM, joes wrote:
Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
On 3/30/2025 7:32 PM, Richard Damon wrote:
On 3/30/25 7:59 PM, olcott wrote:
On 3/30/2025 5:50 PM, Richard Damon wrote:
On 3/30/25 5:53 PM, olcott wrote:
On 3/30/2025 4:01 PM, Richard Damon wrote:
On 3/30/25 3:42 PM, olcott wrote:
On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
Op 30.mrt.2025 om 04:35 schreef olcott:
On 3/29/2025 8:12 PM, Richard Damon wrote:
On 3/29/25 6:44 PM, olcott wrote:
On 3/29/2025 5:08 PM, dbush wrote:
Yes, HHH is off the topic of deciding halting.Is not what I asked about. I asked about the behavior >>>>>>>>>>>>>>>>>> of D when executed directly.Off topic for this thread.
What does "specify to" mean? Which behaviour is correct?The behavior that these machine code bytes specify: >>>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is >>>>>>>>>>>>>>> different than these same bytes as input to HHH1 as a >>>>>>>>>>>>>>> verified fact.
It is part of the program under test, being called by it. That'sIt is part of the input in the sense that HHH must emulate itself >>>>>>> emulating DDD. HHH it the test program thus not the program-under- >>>>>>> test.Right, which were defined by INTEL, and requires the dataThe semantics of the x86 language.DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH >>>>>>>>>>> ITS OWN FINAL HALT STATE.How does HHH emulate the call to HHH instruction
emulated to be part of the input.
what you call a pathological relationship.
HHH is not asking does itself halt?Yes it is saying "I can't simulate this".
It was encoded to always halt for such inputs. HHH is asking does >>>>>>> this input specify that it reaches its own final halt state?Which it does (except when simulated by HHH).
That is actually not a difference but the same that DDD calls HHH.We have already been over this.No, it is YOUR misconception. The algorithm DDD consists of theExcept when doing so changes the input, as is the case with HHH andHow we we determine that DDD emulated by HHH cannot possibly >>>>>>>>> reach its final halt state?Nope, because if you admit to the first two lies, your HHH never >>>>>>>> was a valid decider,
Two recursive emulations provide correct inductive proof.
It is ALWAYS CORRECT for any simulating termination analyzer to stop >>>>> simulating and reject any input that would otherwise prevent its own >>>>> termination.
DDD.
Changing the input is not allowed.
I have already addressed your misconception that the input is changed.
function DDD, the function HHH, and everything that HHH calls down to
the OS level.
HHH(DDD) and HHH1(DDD) have the same inputs all the way down to the OS
level. The ONLY difference is that DDD does not call HHH1(DDD) in
recursive emulation.
On 4/2/2025 9:11 AM, joes wrote:
Am Mon, 31 Mar 2025 17:11:05 -0500 schrieb olcott:
On 3/31/2025 3:33 PM, joes wrote:
Am Mon, 31 Mar 2025 13:13:04 -0500 schrieb olcott:Non-halting is always construed as the failure of the input.
On 3/31/2025 3:26 AM, Fred. Zwarts wrote:That is the failure.
But we all agree that HHH fails to reach the end of the simulation of >>>>>> this finite recursion. An end that exists as proven by directBecause DDD calls HHH(DDD) in recursive emulation DDD EMULATED BY HHH >>>>> CANNOT POSSIIBLY HALT.
execution and world class simulators. Why repeating this agreement as >>>>>> if someone denies it?
What the fuck. A halt *decider* is supposed to halt, even on non-halting
inputs.
HHH(DDD) has halted since its original version H(P)
several years ago. DDD emulated by HHH could not
possibly halt since its original version P emulated
by H several years ago.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
... PO really /has/ an H (it's
trivial to do for this one case) that
correctly determines that P(P)
*would* never stop running *unless* aborted.
On 4/2/2025 6:18 AM, Richard Damon wrote:
On 4/1/25 10:40 PM, olcott wrote:
On 4/1/2025 8:15 PM, Richard Damon wrote:
On 4/1/25 7:31 PM, olcott wrote:
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>> finiteWe can know that when this adapted UTM simulates a finite >>>>>>>>>>>>>>> number ofAnd therefore does not do a correct UTM simulation that >>>>>>>>>>>>>> matches the
steps of its input that this finite number of steps were >>>>>>>>>>>>>>> simulated
correctly.
behavior of the direct execution as it is incomplete. >>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>>>
False, if the starting function calls UTM and UTM changes, >>>>>>>>>>>>>> you're2) changing the input is not allowedThe input is unchanged. There never was any indication >>>>>>>>>>>>>>> that the input
was in any way changed.
changing the input.
number of steps
and input D calls UTM1 then the behavior of D simulated >>>>>>>>>>>>> by UTM1 never reaches its final halt state.Doesn't matter if it calls it, but if the UTM halts.
When D is simulated by ordinary UTM2 that D does not call >>>>>>>>>>>>> Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it >>>>>>>>>> only does a partial simulation, not a complete as REQURIED by >>>>>>>>>> the definition of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of >>>>>>>> x86,
the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or
emulation.
Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.
When-so-ever a finite number of steps of x86 machine
code have been emulated according to the semantics
of the x86 language then these steps have been
emulated correctly even if God himself disagrees.
And the number of times you have INCORRECTLY claimed that you
partial simulator did a correct emulation just shows how much of a
liar you are.
Anyone that knows the C language knows that one recursive
emulation proves that DDD emulated by HHH cannot possibly
reach its final halt state in an infinite number of steps.
No it doesn't, as if HHH actually emulated that path, it would see
that the HHH that it emulated will eventually abort its emulation and
return.
This stumped me for abut four days several years ago.
It turns out that unless the outer HHH aborts none
of them ever abort. This proves that HHH is correct.
On 4/2/2025 9:10 AM, joes wrote:
Am Mon, 31 Mar 2025 18:34:17 -0500 schrieb olcott:
On 3/31/2025 5:54 PM, dbush wrote:
No, it is YOUR misconception. The algorithm DDD consists of theWe have already been over this.
function DDD, the function HHH, and everything that HHH calls down to
the OS level.
HHH(DDD) and HHH1(DDD) have the same inputs all the way down to the OS
level. The ONLY difference is that DDD does not call HHH1(DDD) in
recursive emulation.
That is actually not a difference but the same that DDD calls HHH.
That DDD calls HHH(DDD) instead of HHH1(DDD)
causes the behavior of DDD emulated by HHH and
DDD emulated by HHH1 to differ.
On 4/2/2025 9:10 AM, joes wrote:
Am Mon, 31 Mar 2025 18:34:17 -0500 schrieb olcott:
On 3/31/2025 5:54 PM, dbush wrote:
No, it is YOUR misconception. The algorithm DDD consists of theWe have already been over this.
function DDD, the function HHH, and everything that HHH calls down to
the OS level.
HHH(DDD) and HHH1(DDD) have the same inputs all the way down to the OS
level. The ONLY difference is that DDD does not call HHH1(DDD) in
recursive emulation.
That is actually not a difference but the same that DDD calls HHH.
That DDD calls HHH(DDD) instead of HHH1(DDD)
causes the behavior of DDD emulated by HHH and
DDD emulated by HHH1 to differ.
On 4/2/2025 4:09 AM, Mikko wrote:
On 2025-04-01 23:31:23 +0000, olcott said:
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:Sure all trolls would agree that when-so-ever a statement
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>We can know that when this adapted UTM simulates a finite number ofAnd therefore does not do a correct UTM simulation that matches the
steps of its input that this finite number of steps were simulated
correctly.
behavior of the direct execution as it is incomplete.
When UTM1 is a UTM that has been adapted to only simulate a finite >>>>>>>>>>> number of stepsFalse, if the starting function calls UTM and UTM changes, you're >>>>>>>>>>>> changing the input.2) changing the input is not allowedThe input is unchanged. There never was any indication that the input
was in any way changed.
and input D calls UTM1 then the behavior of D simulatedDoesn't matter if it calls it, but if the UTM halts.
by UTM1 never reaches its final halt state.
When D is simulated by ordinary UTM2 that D does not call Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only does a >>>>>>>> partial simulation, not a complete as REQURIED by the definition of a >>>>>>>> UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86, >>>>>> the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or emulation. >>>
is made many dozens of time this proves that this statement
was never said.
Trolls don't care what was said. But I do. My comment was about your words >> I quoted. Your response was not about my or your quoted words. Instead you >> talked obout something else as trolls typically do.
I always reply to the immediate context.
What you said was irrelevant was a key essence
of my reasoning that proves my point.
When someone totally proves their point a Troll
that is only interested in naysaying would see
that the point is irrefutable so they say some
other nonsense such that the point was irrelevant.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86, >>>>>> the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
On 4/2/2025 9:10 AM, joes wrote:
Am Mon, 31 Mar 2025 18:34:17 -0500 schrieb olcott:
On 3/31/2025 5:54 PM, dbush wrote:
No, it is YOUR misconception. The algorithm DDD consists of theWe have already been over this.
function DDD, the function HHH, and everything that HHH calls down to
the OS level.
HHH(DDD) and HHH1(DDD) have the same inputs all the way down to the OS
level. The ONLY difference is that DDD does not call HHH1(DDD) in
recursive emulation.
That is actually not a difference but the same that DDD calls HHH.
That DDD calls HHH(DDD) instead of HHH1(DDD)
causes the behavior of DDD emulated by HHH and
DDD emulated by HHH1 to differ.
On 4/3/2025 1:32 AM, Mikko wrote:
On 2025-04-03 02:08:22 +0000, olcott said:
On 4/2/2025 4:09 AM, Mikko wrote:
On 2025-04-01 23:31:23 +0000, olcott said:
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
When UTM1 is a UTM that has been adapted to only simulate a >>>>>>>>>>>>> finiteWe can know that when this adapted UTM simulates a finite >>>>>>>>>>>>>>> number ofAnd therefore does not do a correct UTM simulation that >>>>>>>>>>>>>> matches the
steps of its input that this finite number of steps were >>>>>>>>>>>>>>> simulated
correctly.
behavior of the direct execution as it is incomplete. >>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>>>
False, if the starting function calls UTM and UTM changes, >>>>>>>>>>>>>> you're2) changing the input is not allowedThe input is unchanged. There never was any indication >>>>>>>>>>>>>>> that the input
was in any way changed.
changing the input.
number of steps
and input D calls UTM1 then the behavior of D simulated >>>>>>>>>>>>> by UTM1 never reaches its final halt state.Doesn't matter if it calls it, but if the UTM halts.
When D is simulated by ordinary UTM2 that D does not call >>>>>>>>>>>>> Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it >>>>>>>>>> only does a partial simulation, not a complete as REQURIED by >>>>>>>>>> the definition of a UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of >>>>>>>> x86,
the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or
emulation.
Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.
Trolls don't care what was said. But I do. My comment was about your
words
I quoted. Your response was not about my or your quoted words.
Instead you
talked obout something else as trolls typically do.
I always reply to the immediate context.
What you said was irrelevant was a key essence
of my reasoning that proves my point.
When someone totally proves their point a Troll
that is only interested in naysaying would see
that the point is irrefutable so they say some
other nonsense such that the point was irrelevant.
As can be seen above, you had said said:
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
That, and especially the last pair of lines, is the immediate context
to my comment:
THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS
NOT RELEVANT TO A CORRECT DECISION BY A HALT DECIDER?
HHH does correctly compute the mapping from its input
finite string on this basis:
On 4/3/2025 1:32 AM, Mikko wrote:
On 2025-04-03 02:08:22 +0000, olcott said:
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Which does not agree or disagree with my comment nor say anything
about it,
and it doesn't clarify any aspect of your statement that i commented.
If there is any indirect connection to anything relevant that
connection is
not presented, leaving your response unconnected and therefore
irrelevant.
So you did not reply to the immediated context.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS
NOT RELEVANT TO A CORRECT DECISION BY A HALT DECIDER?
HHH does correctly compute the mapping from its input
finite string on this basis:
Simulating termination analyzer Principle
It is always correct for any simulating termination
analyzer to stop simulating and reject any input that
would otherwise prevent its own termination. The
only rebuttal to this is rejecting the notion that
deciders must always halt.
On 4/3/2025 1:32 AM, Mikko wrote:
On 2025-04-03 02:08:22 +0000, olcott said:
On 4/2/2025 4:09 AM, Mikko wrote:
On 2025-04-01 23:31:23 +0000, olcott said:
On 4/1/2025 1:25 AM, Mikko wrote:
On 2025-03-31 18:06:35 +0000, olcott said:
On 3/31/2025 3:47 AM, Mikko wrote:
On 2025-03-30 20:32:07 +0000, olcott said:
On 3/30/2025 1:52 PM, Richard Damon wrote:
On 3/30/25 2:27 PM, olcott wrote:
On 3/30/2025 3:12 AM, joes wrote:
Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
On 3/29/2025 3:14 PM, dbush wrote:So not an UTM.
On 3/29/2025 4:01 PM, olcott wrote:
When UTM1 is a UTM that has been adapted to only simulate a finiteWe can know that when this adapted UTM simulates a finite number ofAnd therefore does not do a correct UTM simulation that matches the
steps of its input that this finite number of steps were simulated
correctly.
behavior of the direct execution as it is incomplete. >>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete. >>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt. >>>>>>>>>>>>
False, if the starting function calls UTM and UTM changes, you're2) changing the input is not allowedThe input is unchanged. There never was any indication that the input
was in any way changed.
changing the input.
number of steps
and input D calls UTM1 then the behavior of D simulated >>>>>>>>>>>>> by UTM1 never reaches its final halt state.Doesn't matter if it calls it, but if the UTM halts.
When D is simulated by ordinary UTM2 that D does not call Then D reaches
its final halt state.
You changed UTM1, which is part of the input D.Changing the input is not allowed.I never changed the input. D always calls UTM1.
thus is the same input to UTM1 as it is to UTM2.
UTM1 simulates D that calls UTM1
simulated D NEVER reaches final halt state
UTM2 simulates D that calls UTM1
simulated D ALWAYS reaches final halt state
Only because UTM1 isn't actually a UTM, but a LIE since it only does a
partial simulation, not a complete as REQURIED by the definition of a
UTM.
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
No, it does not. HHH misintepretes, contrary to the semantics of x86, >>>>>>>> the specification to mean that.
It is a truism that a correct x86 emulator
would emulate itself emulating DDD whenever
DDD calls this emulator with itself.
Irrelevant. You didn't say anything about a correct emulator or emulation.
Sure all trolls would agree that when-so-ever a statement
is made many dozens of time this proves that this statement
was never said.
Trolls don't care what was said. But I do. My comment was about your words >>>> I quoted. Your response was not about my or your quoted words. Instead you >>>> talked obout something else as trolls typically do.
I always reply to the immediate context.
What you said was irrelevant was a key essence
of my reasoning that proves my point.
When someone totally proves their point a Troll
that is only interested in naysaying would see
that the point is irrefutable so they say some
other nonsense such that the point was irrelevant.
As can be seen above, you had said said:
_DDD()
[00002172] 55 push ebp ; housekeeping >>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD EMULATED BY HHH DOES SPECIFY THAT IT
CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
That, and especially the last pair of lines, is the immediate context
to my comment:
THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS
NOT RELEVANT TO A CORRECT DECISION BY A HALT DECIDER?
HHH does correctly compute the mapping from its input
finite string on this basis:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A
It is a truism that a correct x86 emulator would emulate itself
emulating DDD whenever DDD calls this emulator with itself.
Which does not agree or disagree with my comment nor say anything about
it,
and it doesn't clarify any aspect of your statement that i commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and
therefore irrelevant.
So you did not reply to the immediated context.
CORRECT DECISION BY A HALT DECIDER?
On 4/13/2025 9:46 AM, joes wrote:
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A
It is a truism that a correct x86 emulator would emulate itself >>>>>>>>> emulating DDD whenever DDD calls this emulator with itself.
Which does not agree or disagree with my comment nor say anything about >>>> it,
and it doesn't clarify any aspect of your statement that i commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and
therefore irrelevant.
So you did not reply to the immediated context.
CORRECT DECISION BY A HALT DECIDER?
THE ONLY RELEVANT THING IS THE PATHOLOGICAL SELF-REFERENCE
BEHAVIOR THAT THE INPUT FINITE STRING SPECIFIES.
IGNORING THIS IS DISHONEST, STUPID, OR BOTH.
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no bearing on
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A
It is a truism that a correct x86 emulator would emulate itself >>>>>>>>> emulating DDD whenever DDD calls this emulator with itself.
Which does not agree or disagree with my comment nor say anything
about it,
and it doesn't clarify any aspect of your statement that i commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and
therefore irrelevant.
So you did not reply to the immediated context.
CORRECT DECISION BY A HALT DECIDER?
THE ONLY RELEVANT THING IS THE PATHOLOGICAL SELF-REFERENCE BEHAVIOR THATDDD does not „specify” self-reference; simulating with HHH does.
THE INPUT FINITE STRING SPECIFIES.
On 4/14/2025 6:54 PM, dbush wrote:
On 4/14/2025 7:50 PM, olcott wrote:
On 4/14/2025 4:32 AM, joes wrote:
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:
On 4/13/2025 9:46 AM, joes wrote:
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
To clarify: that *HHH* does not simulate DDD halting has noTHE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOTYes.
RELEVANT TO A
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
THE DIRECT EXECUTION IS NOT WHAT IT SEES
Irrelevant.
THAT IS A STUPID THING TO SAY
THAT COMPLETELY IGNORES WHAT
COMPUTABLE FUNCTIONS ARE AND HOW THEY WORK.
On 4/14/2025 4:32 AM, joes wrote:
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no bearing on
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A >>>>> CORRECT DECISION BY A HALT DECIDER?
It is a truism that a correct x86 emulator would emulate itself >>>>>>>>>>> emulating DDD whenever DDD calls this emulator with itself.
Which does not agree or disagree with my comment nor say anything
about it,
and it doesn't clarify any aspect of your statement that i commented. >>>>>> If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and >>>>>> therefore irrelevant.
So you did not reply to the immediated context.
its direct execution.
THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS
FORBIDDING IT FROM REPORTING ON THE DIRECT EXECUTION.
THE ONLY RELEVANT THING IS THE PATHOLOGICAL SELF-REFERENCE BEHAVIOR THAT >>> THE INPUT FINITE STRING SPECIFIES.DDD does not „specify” self-reference; simulating with HHH does.
On 4/14/2025 6:54 PM, dbush wrote:
On 4/14/2025 7:50 PM, olcott wrote:
On 4/14/2025 4:32 AM, joes wrote:
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no bearing on >>>> its direct execution.
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A >>>>>>> CORRECT DECISION BY A HALT DECIDER?
Which does not agree or disagree with my comment nor say anything >>>>>>>> about it,It is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>> itself
emulating DDD whenever DDD calls this emulator with itself. >>>>>>>>
and it doesn't clarify any aspect of your statement that i
commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and >>>>>>>> therefore irrelevant.
So you did not reply to the immediated context.
THE DIRECT EXECUTION IS NOT WHAT IT SEES
Irrelevant.
THAT IS A STUPID THING TO SAY THAT COMPLETELY IGNORES WHAT
COMPUTABLE FUNCTIONS ARE AND HOW THEY WORK.
On 4/14/2025 8:32 PM, Richard Heathfield wrote:
On 15/04/2025 02:02, olcott wrote:
On 4/14/2025 6:54 PM, dbush wrote:
On 4/14/2025 7:50 PM, olcott wrote:
On 4/14/2025 4:32 AM, joes wrote:
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:
On 4/13/2025 9:46 AM, joes wrote:
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
<snip>
To clarify: that *HHH* does not simulate DDD halting has noTHE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOTYes.
RELEVANT TO A
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
THE DIRECT EXECUTION IS NOT WHAT IT SEES
Irrelevant.
THAT IS A STUPID THING TO SAY
Far from it. In fact it's very very true, and the all-caps
foot-stamping doesn't help your case one jot.
THAT COMPLETELY IGNORES WHAT
COMPUTABLE FUNCTIONS ARE AND HOW THEY WORK.
It doesn't matter how they work.
You can't stupidly ignored that all deciders must be
computable functions.
On 4/14/2025 8:32 PM, Richard Heathfield wrote:
On 15/04/2025 02:02, olcott wrote:
On 4/14/2025 6:54 PM, dbush wrote:
On 4/14/2025 7:50 PM, olcott wrote:
On 4/14/2025 4:32 AM, joes wrote:
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:
On 4/13/2025 9:46 AM, joes wrote:
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
<snip>
To clarify: that *HHH* does not simulate DDD halting has no bearing on >>>>>> its direct execution.THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A >>>>>>>>> CORRECT DECISION BY A HALT DECIDER?Yes.
THE DIRECT EXECUTION IS NOT WHAT IT SEES
Irrelevant.
THAT IS A STUPID THING TO SAY
Far from it. In fact it's very very true, and the all-caps
foot-stamping doesn't help your case one jot.
THAT COMPLETELY IGNORES WHAT
COMPUTABLE FUNCTIONS ARE AND HOW THEY WORK.
It doesn't matter how they work.
You can't stupidly ignored that all deciders must be
computable functions.
On 4/14/2025 8:32 PM, Richard Heathfield wrote:
On 15/04/2025 02:02, olcott wrote:
On 4/14/2025 6:54 PM, dbush wrote:
On 4/14/2025 7:50 PM, olcott wrote:
On 4/14/2025 4:32 AM, joes wrote:
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:
On 4/13/2025 9:46 AM, joes wrote:
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
<snip>
To clarify: that *HHH* does not simulate DDD halting has noTHE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT >>>>>>>>> TO AYes.
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
THE DIRECT EXECUTION IS NOT WHAT IT SEES
Irrelevant.
THAT IS A STUPID THING TO SAY
Far from it. In fact it's very very true, and the all-caps foot-
stamping doesn't help your case one jot.
THAT COMPLETELY IGNORES WHAT
COMPUTABLE FUNCTIONS ARE AND HOW THEY WORK.
It doesn't matter how they work.
You can't stupidly ignored that all deciders must be
computable functions.
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing processor does.
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no bearing on
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A >>>>> CORRECT DECISION BY A HALT DECIDER?
Which does not agree or disagree with my comment nor say anythingIt is a truism that a correct x86 emulator would emulate >>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>> itself.
about it,
and it doesn't clarify any aspect of your statement that i
commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and >>>>>> therefore irrelevant.
So you did not reply to the immediated context.
its direct execution.
REPORTING ON THE DIRECT EXECUTION.
On 4/22/2025 7:40 AM, joes wrote:
Am Mon, 14 Apr 2025 18:50:52 -0500 schrieb olcott:
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing processor
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no bearing on >>>> its direct execution.
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A >>>>>>> CORRECT DECISION BY A HALT DECIDER?
Which does not agree or disagree with my comment nor say anything >>>>>>>> about it,It is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>>>> itself.
and it doesn't clarify any aspect of your statement that i
commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and >>>>>>>> therefore irrelevant.
So you did not reply to the immediated context.
REPORTING ON THE DIRECT EXECUTION.
does.
HHH cannot possibly see what HHH1.
On 4/22/2025 10:22 AM, Fred. Zwarts wrote:
Op 22.apr.2025 om 16:07 schreef olcott:
On 4/22/2025 7:40 AM, joes wrote:
Am Mon, 14 Apr 2025 18:50:52 -0500 schrieb olcott:
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing processor
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT >>>>>>>>> TO A
Which does not agree or disagree with my comment nor say anything >>>>>>>>>> about it,It is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>>>>>> itself.
and it doesn't clarify any aspect of your statement that i >>>>>>>>>> commented.
If there is any indirect connection to anything relevant that >>>>>>>>>> connection is not presented, leaving your response unconnected >>>>>>>>>> and
therefore irrelevant.
So you did not reply to the immediated context.
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
REPORTING ON THE DIRECT EXECUTION.
does.
HHH cannot possibly see what HHH1.
Yes, the programmer made HHH such that it cannot see the behaviour.
typedef void (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH1(DD);
}
It is stupid to think that HHH can see anything
that it caller does.
This failure of HHH does not say anything about the behaviour
specified by the input. According to the semantics of the x86
language, this input specifies a halting program, as proven by direct
execution and world- class simulators. That HHH is unable to reach the
end of this halting program, does not change the semantics of the x86
language.
On 4/22/2025 7:40 AM, joes wrote:
Am Mon, 14 Apr 2025 18:50:52 -0500 schrieb olcott:
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing processor
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no bearing on >>>> its direct execution.
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT TO A >>>>>>> CORRECT DECISION BY A HALT DECIDER?
Which does not agree or disagree with my comment nor say anything >>>>>>>> about it,It is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>>>> itself.
and it doesn't clarify any aspect of your statement that i
commented.
If there is any indirect connection to anything relevant that
connection is not presented, leaving your response unconnected and >>>>>>>> therefore irrelevant.
So you did not reply to the immediated context.
REPORTING ON THE DIRECT EXECUTION.
does.
HHH cannot possibly see what HHH1.
On 4/22/2025 2:26 PM, Fred. Zwarts wrote:
Op 22.apr.2025 om 20:43 schreef olcott:
On 4/22/2025 10:22 AM, Fred. Zwarts wrote:
Op 22.apr.2025 om 16:07 schreef olcott:
On 4/22/2025 7:40 AM, joes wrote:
Am Mon, 14 Apr 2025 18:50:52 -0500 schrieb olcott:
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM >>>>>>> REPORTING ON THE DIRECT EXECUTION.
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT
Which does not agree or disagree with my comment nor say >>>>>>>>>>>> anythingIt is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>>>>>>>> itself.
about it,
and it doesn't clarify any aspect of your statement that i >>>>>>>>>>>> commented.
If there is any indirect connection to anything relevant that >>>>>>>>>>>> connection is not presented, leaving your response
unconnected and
therefore irrelevant.
So you did not reply to the immediated context.
RELEVANT TO A
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
processor does.
HHH cannot possibly see what HHH1.
Yes, the programmer made HHH such that it cannot see the behaviour.
typedef void (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH1(DD);
}
It is stupid to think that HHH can see anything
that it caller does.
It is stupid to think that when HHH is made blind for some facts by
the programmer, that these facts are not true.
If HHH can see any aspect of its caller then this
violates the requirements of a computable function.
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function
On 4/22/2025 5:58 PM, Richard Damon wrote:
On 4/22/25 10:07 AM, olcott wrote:
On 4/22/2025 7:40 AM, joes wrote:
Am Mon, 14 Apr 2025 18:50:52 -0500 schrieb olcott:
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing processor
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT >>>>>>>>> TO A
Which does not agree or disagree with my comment nor say anything >>>>>>>>>> about it,It is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>>>>>> itself.
and it doesn't clarify any aspect of your statement that i >>>>>>>>>> commented.
If there is any indirect connection to anything relevant that >>>>>>>>>> connection is not presented, leaving your response unconnected >>>>>>>>>> and
therefore irrelevant.
So you did not reply to the immediated context.
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
REPORTING ON THE DIRECT EXECUTION.
does.
HHH cannot possibly see what HHH1.
But it isn't a matter of what HHH "sees", it is what the correct
answer is.
It never has been about a correct answer.
It has always been about what finite string
transformations can be applied to finite
string inputs to derive corresponding outputs.
If one of them is a correct answer great.
If HHH can't figure that out, it just makes HHH wrong.
You don't seem to understand that simple fact of truth.
On 4/22/2025 5:58 PM, Richard Damon wrote:
On 4/22/25 10:07 AM, olcott wrote:
On 4/22/2025 7:40 AM, joes wrote:
Am Mon, 14 Apr 2025 18:50:52 -0500 schrieb olcott:
On 4/14/2025 4:32 AM, joes wrote:It sure ought to see the same thing the directly executing processor
Am Sun, 13 Apr 2025 14:54:35 -0500 schrieb olcott:THE DIRECT EXECUTION IS NOT WHAT IT SEES THUS FORBIDDING IT FROM
On 4/13/2025 9:46 AM, joes wrote:To clarify: that *HHH* does not simulate DDD halting has no
Am Thu, 03 Apr 2025 16:57:43 -0500 schrieb olcott:
On 4/3/2025 1:32 AM, Mikko wrote:Yes.
On 2025-04-03 02:08:22 +0000, olcott said:THE FACT THAT DDD EMULATED BY HHH DOES NOT HALT IS NOT RELEVANT >>>>>>>>> TO A
Which does not agree or disagree with my comment nor say anything >>>>>>>>>> about it,It is a truism that a correct x86 emulator would emulate >>>>>>>>>>>>>>> itself emulating DDD whenever DDD calls this emulator with >>>>>>>>>>>>>>> itself.
and it doesn't clarify any aspect of your statement that i >>>>>>>>>> commented.
If there is any indirect connection to anything relevant that >>>>>>>>>> connection is not presented, leaving your response unconnected >>>>>>>>>> and
therefore irrelevant.
So you did not reply to the immediated context.
CORRECT DECISION BY A HALT DECIDER?
bearing on
its direct execution.
REPORTING ON THE DIRECT EXECUTION.
does.
HHH cannot possibly see what HHH1.
But it isn't a matter of what HHH "sees", it is what the correct
answer is.
It never has been about a correct answer.
It has always been about what finite string
transformations can be applied to finite
string inputs to derive corresponding outputs.
If one of them is a correct answer great.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 03:27:22 |
| Calls: | 9,707 |
| Calls today: | 2 |
| Files: | 13,740 |
| Messages: | 6,180,826 |