On 5/22/22 12:42 PM, olcott wrote:
On 5/22/2022 11:40 AM, Richard Damon wrote:
On 5/22/22 12:31 PM, olcott wrote:
On 5/22/2022 11:21 AM, Richard Damon wrote:
On 5/22/22 10:57 AM, olcott wrote:
On 5/22/2022 6:06 AM, Richard Damon wrote:
On 5/22/22 1:02 AM, olcott wrote:
On 5/21/2022 11:05 PM, Richard Damon wrote:No, because the second level emulation is NOT emulated by the top >>>>>>> level emulator, its emulator is.
On 5/21/22 11:59 PM, olcott wrote:
On 5/21/2022 10:54 PM, Richard Damon wrote:
On 5/21/22 11:36 PM, olcott wrote:
On 5/21/2022 10:27 PM, Richard Damon wrote:
On 5/21/22 10:48 PM, olcott wrote:
On 5/21/2022 9:37 PM, Richard Damon wrote:
On 5/21/22 10:28 PM, olcott wrote:
On 5/21/2022 9:20 PM, Richard Damon wrote:
On 5/21/22 9:23 PM, olcott wrote:
On 5/21/2022 8:05 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote:
In other words you acknowledge that you are >>>>>>>>>>>>>>>>>> technically incompetent to provide the execution trace >>>>>>>>>>>>>>>>>> of one simulation and one nested simulation of the >>>>>>>>>>>>>>>>>> input to H(P,P).On 5/20/2022 5:25 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
You have known that the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>>> simulated correctly provingIf H is intended to be a halt decider (even if only >>>>>>>>>>>>>>>>>>>>> for the one case you
that H(P,P)==0 is correct for the whole six months >>>>>>>>>>>>>>>>>>>>>
claim to care about) then H(P,P) == 0 is wrong, >>>>>>>>>>>>>>>>>>>>> because P(P) halts.
When we correctly reverse-engineer what the >>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be for >>>>>>>>>>>>>>>>>>>> one emulation and one nested emulation we can see >>>>>>>>>>>>>>>>>>>> that the correctly emulated input to H(P,P) would >>>>>>>>>>>>>>>>>>>> never reach its final state at machine address >>>>>>>>>>>>>>>>>>>> [0000136c].
A nonsense trace, as it is mixing the execution path >>>>>>>>>>>>>>>>>>> of two independent execution units.
No, I am saying that you are asking for the equivalent >>>>>>>>>>>>>>>>> of a of a square circle.
So an execution trace of the input to H(P,P) is easy to >>>>>>>>>>>>>>>> show when H simulates its input, yet another execution >>>>>>>>>>>>>>>> trace of the input to H(P,P) that was invoked by P is >>>>>>>>>>>>>>>> "like a square circle" can't possibly exist?
The problem is that your second trace is NOT a piece of >>>>>>>>>>>>>>> the first.
The fact you don't understand that says you just don't >>>>>>>>>>>>>>> know how computers or programs actually work.
When a UTM simulates a TM description that calls a UTM >>>>>>>>>>>>>> that simulates a
TM description all of this is simply data on the first >>>>>>>>>>>>>> UTM's tape and the only actual executable is the first UTM. >>>>>>>>>>>>>
Yes, and a trace made by that outer UTM will show the >>>>>>>>>>>>> states that the second UTM is going through, but NOT the >>>>>>>>>>>>> states that second UTM simulates in its own processing. >>>>>>>>>>>>>
That second UTM might produce its OWN trace of the states >>>>>>>>>>>>> that it has simulated, but that is a SEPERATE trace, and >>>>>>>>>>>>> NOT part of the trace from the OUTER UTM.
And this trace is written to the outer UTM's tape as a part >>>>>>>>>>>> of its own data.
Yes, the DATA is there, ENCODED on the tape, but it isn't >>>>>>>>>>> part of the trace generated by that UTM.
The only actual executable is the outer UTM everything else is >>>>>>>>>> a part of the same nested process.
So the only actual valid trace is what that outer simulator
actual simulated.
There is a valid trace of every line of code that is emulated. >>>>>>>> Operating system code has its trace tuned off. This only leaves >>>>>>>> the user code such as P() and main(). Then we see the 14 lines >>>>>>>> execution trace of the two level simulation of the input to H(P,P) >>>>>>>
Unless you are lying about what H does, you are just lying that
the second level code is emulated by the same emulation process
that the first is. (That may well be true, but it means you logic >>>>>>> is still built on a lie).
If you are too stupid to understand that H(P,P) derives the same
execution trace of its input every time it is called you are far
too stupid to evaluate my work.
Ok, then why does the H(P,P) that P calls get stuck in an infinite
recursion wneh the top level doesn't?
It is a verified fact that the correct simulation of the input to
H(P,P) never reaches its final instruction thus conclusively proving
that it never halts.
The only machine that you have shown that does a correct simulation
is the version that never aborts. That version fails to answer the
question, so fails to be a halt decider.
Any version of H that aborts, and returns a not-halting answer
changes P into a Halting Compuation.
The "pathological" use of H by P lets it change as you change H, so
if H aborts, it is wrong because THAT P halts, if it doesn't, then it
is wrong for not answering.
You seem to miss this fact because you just don't understand the
basics of how computations work. Part of your problem is you keep on
trying to define H by rules that aren't an actual algorithm, so can't
actually be written.
It is an easily verifiable fact that the C function H does correctly
determine that the C function named P would never reach its last
instruction when correctly emulated by H.
Don't just "Claim" it, so an ACTUAL verification, or you just show
yourself to be a liar.
Everyone disagreeing with verified facts is incorrect on the basis of
lack of technical competency or lack of honesty.
You haven't verified ANY fact, you have made claims using FAKE data that don't even really support your claim.
On 5/22/2022 12:36 PM, Richard Damon wrote:
On 5/22/22 12:42 PM, olcott wrote:
On 5/22/2022 11:40 AM, Richard Damon wrote:
On 5/22/22 12:31 PM, olcott wrote:
On 5/22/2022 11:21 AM, Richard Damon wrote:
On 5/22/22 10:57 AM, olcott wrote:
On 5/22/2022 6:06 AM, Richard Damon wrote:
On 5/22/22 1:02 AM, olcott wrote:
On 5/21/2022 11:05 PM, Richard Damon wrote:No, because the second level emulation is NOT emulated by the
On 5/21/22 11:59 PM, olcott wrote:
On 5/21/2022 10:54 PM, Richard Damon wrote:
On 5/21/22 11:36 PM, olcott wrote:
On 5/21/2022 10:27 PM, Richard Damon wrote:
On 5/21/22 10:48 PM, olcott wrote:
On 5/21/2022 9:37 PM, Richard Damon wrote:
On 5/21/22 10:28 PM, olcott wrote:
On 5/21/2022 9:20 PM, Richard Damon wrote:
On 5/21/22 9:23 PM, olcott wrote:
On 5/21/2022 8:05 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote:
In other words you acknowledge that you are >>>>>>>>>>>>>>>>>>> technically incompetent to provide the execution >>>>>>>>>>>>>>>>>>> trace of one simulation and one nested simulation of >>>>>>>>>>>>>>>>>>> the input to H(P,P).On 5/20/2022 5:25 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>
You have known that the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>>>> simulated correctly provingIf H is intended to be a halt decider (even if >>>>>>>>>>>>>>>>>>>>>> only for the one case you
that H(P,P)==0 is correct for the whole six months >>>>>>>>>>>>>>>>>>>>>>
claim to care about) then H(P,P) == 0 is wrong, >>>>>>>>>>>>>>>>>>>>>> because P(P) halts.
When we correctly reverse-engineer what the >>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be for >>>>>>>>>>>>>>>>>>>>> one emulation and one nested emulation we can see >>>>>>>>>>>>>>>>>>>>> that the correctly emulated input to H(P,P) would >>>>>>>>>>>>>>>>>>>>> never reach its final state at machine address >>>>>>>>>>>>>>>>>>>>> [0000136c].
A nonsense trace, as it is mixing the execution path >>>>>>>>>>>>>>>>>>>> of two independent execution units.
No, I am saying that you are asking for the equivalent >>>>>>>>>>>>>>>>>> of a of a square circle.
So an execution trace of the input to H(P,P) is easy to >>>>>>>>>>>>>>>>> show when H simulates its input, yet another execution >>>>>>>>>>>>>>>>> trace of the input to H(P,P) that was invoked by P is >>>>>>>>>>>>>>>>> "like a square circle" can't possibly exist?
The problem is that your second trace is NOT a piece of >>>>>>>>>>>>>>>> the first.
The fact you don't understand that says you just don't >>>>>>>>>>>>>>>> know how computers or programs actually work.
When a UTM simulates a TM description that calls a UTM >>>>>>>>>>>>>>> that simulates a
TM description all of this is simply data on the first >>>>>>>>>>>>>>> UTM's tape and the only actual executable is the first UTM. >>>>>>>>>>>>>>
Yes, and a trace made by that outer UTM will show the >>>>>>>>>>>>>> states that the second UTM is going through, but NOT the >>>>>>>>>>>>>> states that second UTM simulates in its own processing. >>>>>>>>>>>>>>
That second UTM might produce its OWN trace of the states >>>>>>>>>>>>>> that it has simulated, but that is a SEPERATE trace, and >>>>>>>>>>>>>> NOT part of the trace from the OUTER UTM.
And this trace is written to the outer UTM's tape as a part >>>>>>>>>>>>> of its own data.
Yes, the DATA is there, ENCODED on the tape, but it isn't >>>>>>>>>>>> part of the trace generated by that UTM.
The only actual executable is the outer UTM everything else >>>>>>>>>>> is a part of the same nested process.
So the only actual valid trace is what that outer simulator >>>>>>>>>> actual simulated.
There is a valid trace of every line of code that is emulated. >>>>>>>>> Operating system code has its trace tuned off. This only leaves >>>>>>>>> the user code such as P() and main(). Then we see the 14 lines >>>>>>>>> execution trace of the two level simulation of the input to H(P,P) >>>>>>>>
top level emulator, its emulator is.
Unless you are lying about what H does, you are just lying that >>>>>>>> the second level code is emulated by the same emulation process >>>>>>>> that the first is. (That may well be true, but it means you
logic is still built on a lie).
If you are too stupid to understand that H(P,P) derives the same >>>>>>> execution trace of its input every time it is called you are far >>>>>>> too stupid to evaluate my work.
Ok, then why does the H(P,P) that P calls get stuck in an infinite >>>>>> recursion wneh the top level doesn't?
It is a verified fact that the correct simulation of the input to
H(P,P) never reaches its final instruction thus conclusively
proving that it never halts.
The only machine that you have shown that does a correct simulation
is the version that never aborts. That version fails to answer the
question, so fails to be a halt decider.
Any version of H that aborts, and returns a not-halting answer
changes P into a Halting Compuation.
The "pathological" use of H by P lets it change as you change H, so
if H aborts, it is wrong because THAT P halts, if it doesn't, then
it is wrong for not answering.
You seem to miss this fact because you just don't understand the
basics of how computations work. Part of your problem is you keep on
trying to define H by rules that aren't an actual algorithm, so
can't actually be written.
It is an easily verifiable fact that the C function H does correctly
determine that the C function named P would never reach its last
instruction when correctly emulated by H.
Don't just "Claim" it, so an ACTUAL verification, or you just show
yourself to be a liar.
Everyone disagreeing with verified facts is incorrect on the basis of
lack of technical competency or lack of honesty.
You haven't verified ANY fact, you have made claims using FAKE data
that don't even really support your claim.
Software engineering experts
can reverse-engineer what the correct x86 emulation of the input to
H(P,P) would be for one emulation and one nested emulation thus
confirming that the provided execution trace is correct. They can do
this entirely on the basis of the x86 source-code for P with no need to
see the source-code or execution trace of H.
Anyone unable to do this conclusively proves their lack of sufficient technical competence.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Richard was able to correctly determine that the correct simulation of
the input to H(P,P) would emulate the first 7 lines of P.
Richard was utterly baffled beyond all comprehension that the invocation
of the same function with the same input would derive the same trace.
Richard even said that this trace is "like a square circle" in that it
cannot possibly exist.
Does anyone here believe that Richard is really that stupid? (I don't).
On 5/22/22 5:06 PM, olcott wrote:
On 5/22/2022 12:36 PM, Richard Damon wrote:
On 5/22/22 12:42 PM, olcott wrote:
On 5/22/2022 11:40 AM, Richard Damon wrote:
On 5/22/22 12:31 PM, olcott wrote:
On 5/22/2022 11:21 AM, Richard Damon wrote:
On 5/22/22 10:57 AM, olcott wrote:
On 5/22/2022 6:06 AM, Richard Damon wrote:
On 5/22/22 1:02 AM, olcott wrote:
On 5/21/2022 11:05 PM, Richard Damon wrote:
On 5/21/22 11:59 PM, olcott wrote:
On 5/21/2022 10:54 PM, Richard Damon wrote:
On 5/21/22 11:36 PM, olcott wrote:
On 5/21/2022 10:27 PM, Richard Damon wrote:
On 5/21/22 10:48 PM, olcott wrote:
On 5/21/2022 9:37 PM, Richard Damon wrote:
On 5/21/22 10:28 PM, olcott wrote:
On 5/21/2022 9:20 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>
On 5/21/22 9:23 PM, olcott wrote:
On 5/21/2022 8:05 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote:
In other words you acknowledge that you are >>>>>>>>>>>>>>>>>>>> technically incompetent to provide the execution >>>>>>>>>>>>>>>>>>>> trace of one simulation and one nested simulation of >>>>>>>>>>>>>>>>>>>> the input to H(P,P).On 5/20/2022 5:25 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>
You have known that the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>>>>> simulated correctly provingIf H is intended to be a halt decider (even if >>>>>>>>>>>>>>>>>>>>>>> only for the one case you
that H(P,P)==0 is correct for the whole six months >>>>>>>>>>>>>>>>>>>>>>>
claim to care about) then H(P,P) == 0 is wrong, >>>>>>>>>>>>>>>>>>>>>>> because P(P) halts.
When we correctly reverse-engineer what the >>>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be >>>>>>>>>>>>>>>>>>>>>> for one emulation and one nested emulation we can >>>>>>>>>>>>>>>>>>>>>> see that the correctly emulated input to H(P,P) >>>>>>>>>>>>>>>>>>>>>> would never reach its final state at machine >>>>>>>>>>>>>>>>>>>>>> address [0000136c].
A nonsense trace, as it is mixing the execution >>>>>>>>>>>>>>>>>>>>> path of two independent execution units. >>>>>>>>>>>>>>>>>>>>>
No, I am saying that you are asking for the >>>>>>>>>>>>>>>>>>> equivalent of a of a square circle.
So an execution trace of the input to H(P,P) is easy >>>>>>>>>>>>>>>>>> to show when H simulates its input, yet another >>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) that was >>>>>>>>>>>>>>>>>> invoked by P is "like a square circle" can't possibly >>>>>>>>>>>>>>>>>> exist?
The problem is that your second trace is NOT a piece of >>>>>>>>>>>>>>>>> the first.
The fact you don't understand that says you just don't >>>>>>>>>>>>>>>>> know how computers or programs actually work. >>>>>>>>>>>>>>>>>
When a UTM simulates a TM description that calls a UTM >>>>>>>>>>>>>>>> that simulates a
TM description all of this is simply data on the first >>>>>>>>>>>>>>>> UTM's tape and the only actual executable is the first UTM. >>>>>>>>>>>>>>>
Yes, and a trace made by that outer UTM will show the >>>>>>>>>>>>>>> states that the second UTM is going through, but NOT the >>>>>>>>>>>>>>> states that second UTM simulates in its own processing. >>>>>>>>>>>>>>>
That second UTM might produce its OWN trace of the states >>>>>>>>>>>>>>> that it has simulated, but that is a SEPERATE trace, and >>>>>>>>>>>>>>> NOT part of the trace from the OUTER UTM.
And this trace is written to the outer UTM's tape as a >>>>>>>>>>>>>> part of its own data.
Yes, the DATA is there, ENCODED on the tape, but it isn't >>>>>>>>>>>>> part of the trace generated by that UTM.
The only actual executable is the outer UTM everything else >>>>>>>>>>>> is a part of the same nested process.
So the only actual valid trace is what that outer simulator >>>>>>>>>>> actual simulated.
There is a valid trace of every line of code that is emulated. >>>>>>>>>> Operating system code has its trace tuned off. This only
leaves the user code such as P() and main(). Then we see the >>>>>>>>>> 14 lines execution trace of the two level simulation of the >>>>>>>>>> input to H(P,P)
No, because the second level emulation is NOT emulated by the >>>>>>>>> top level emulator, its emulator is.
Unless you are lying about what H does, you are just lying that >>>>>>>>> the second level code is emulated by the same emulation process >>>>>>>>> that the first is. (That may well be true, but it means you
logic is still built on a lie).
If you are too stupid to understand that H(P,P) derives the same >>>>>>>> execution trace of its input every time it is called you are far >>>>>>>> too stupid to evaluate my work.
Ok, then why does the H(P,P) that P calls get stuck in an
infinite recursion wneh the top level doesn't?
It is a verified fact that the correct simulation of the input to
H(P,P) never reaches its final instruction thus conclusively
proving that it never halts.
The only machine that you have shown that does a correct simulation
is the version that never aborts. That version fails to answer the
question, so fails to be a halt decider.
Any version of H that aborts, and returns a not-halting answer
changes P into a Halting Compuation.
The "pathological" use of H by P lets it change as you change H, so
if H aborts, it is wrong because THAT P halts, if it doesn't, then
it is wrong for not answering.
You seem to miss this fact because you just don't understand the
basics of how computations work. Part of your problem is you keep
on trying to define H by rules that aren't an actual algorithm, so
can't actually be written.
It is an easily verifiable fact that the C function H does correctly
determine that the C function named P would never reach its last
instruction when correctly emulated by H.
Don't just "Claim" it, so an ACTUAL verification, or you just show
yourself to be a liar.
Everyone disagreeing with verified facts is incorrect on the basis
of lack of technical competency or lack of honesty.
You haven't verified ANY fact, you have made claims using FAKE data
that don't even really support your claim.
Software engineering experts
can reverse-engineer what the correct x86 emulation of the input to
H(P,P) would be for one emulation and one nested emulation thus
confirming that the provided execution trace is correct. They can do
this entirely on the basis of the x86 source-code for P with no need
to see the source-code or execution trace of H.
Interesting point, that you eed to talk about "reverse-engineering" this output implies that you don't actually have a program to generate it.
You don't need to "reverse-engineer" something you have.
Anyone unable to do this conclusively proves their lack of sufficient
technical competence.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Richard was able to correctly determine that the correct simulation of
the input to H(P,P) would emulate the first 7 lines of P.
Richard was utterly baffled beyond all comprehension that the
invocation of the same function with the same input would derive the
same trace.
No, that is NOT what I said, and you repeating that LIE just shows you
are not intertested in honest answer. I hope what ever review looks at
your final paper (it you ever get to it) and happens to search and come accross these discussions and sees your level of dishonesty.
On 5/22/2022 4:34 PM, Richard Damon wrote:
On 5/22/22 5:06 PM, olcott wrote:
On 5/22/2022 12:36 PM, Richard Damon wrote:
On 5/22/22 12:42 PM, olcott wrote:
On 5/22/2022 11:40 AM, Richard Damon wrote:
On 5/22/22 12:31 PM, olcott wrote:
On 5/22/2022 11:21 AM, Richard Damon wrote:
On 5/22/22 10:57 AM, olcott wrote:
On 5/22/2022 6:06 AM, Richard Damon wrote:
On 5/22/22 1:02 AM, olcott wrote:
On 5/21/2022 11:05 PM, Richard Damon wrote:
On 5/21/22 11:59 PM, olcott wrote:
On 5/21/2022 10:54 PM, Richard Damon wrote:
On 5/21/22 11:36 PM, olcott wrote:
On 5/21/2022 10:27 PM, Richard Damon wrote:
On 5/21/22 10:48 PM, olcott wrote:
On 5/21/2022 9:37 PM, Richard Damon wrote:
On 5/21/22 10:28 PM, olcott wrote:
On 5/21/2022 9:20 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>
On 5/21/22 9:23 PM, olcott wrote:
On 5/21/2022 8:05 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>
In other words you acknowledge that you are >>>>>>>>>>>>>>>>>>>>> technically incompetent to provide the execution >>>>>>>>>>>>>>>>>>>>> trace of one simulation and one nested simulation >>>>>>>>>>>>>>>>>>>>> of the input to H(P,P).You have known that the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>>>>>> simulated correctly provingIf H is intended to be a halt decider (even if >>>>>>>>>>>>>>>>>>>>>>>> only for the one case you
that H(P,P)==0 is correct for the whole six months >>>>>>>>>>>>>>>>>>>>>>>>
claim to care about) then H(P,P) == 0 is wrong, >>>>>>>>>>>>>>>>>>>>>>>> because P(P) halts.
When we correctly reverse-engineer what the >>>>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be >>>>>>>>>>>>>>>>>>>>>>> for one emulation and one nested emulation we can >>>>>>>>>>>>>>>>>>>>>>> see that the correctly emulated input to H(P,P) >>>>>>>>>>>>>>>>>>>>>>> would never reach its final state at machine >>>>>>>>>>>>>>>>>>>>>>> address [0000136c].
A nonsense trace, as it is mixing the execution >>>>>>>>>>>>>>>>>>>>>> path of two independent execution units. >>>>>>>>>>>>>>>>>>>>>>
No, I am saying that you are asking for the >>>>>>>>>>>>>>>>>>>> equivalent of a of a square circle.
So an execution trace of the input to H(P,P) is easy >>>>>>>>>>>>>>>>>>> to show when H simulates its input, yet another >>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) that was >>>>>>>>>>>>>>>>>>> invoked by P is "like a square circle" can't possibly >>>>>>>>>>>>>>>>>>> exist?
The problem is that your second trace is NOT a piece >>>>>>>>>>>>>>>>>> of the first.
The fact you don't understand that says you just don't >>>>>>>>>>>>>>>>>> know how computers or programs actually work. >>>>>>>>>>>>>>>>>>
When a UTM simulates a TM description that calls a UTM >>>>>>>>>>>>>>>>> that simulates a
TM description all of this is simply data on the first >>>>>>>>>>>>>>>>> UTM's tape and the only actual executable is the first >>>>>>>>>>>>>>>>> UTM.
Yes, and a trace made by that outer UTM will show the >>>>>>>>>>>>>>>> states that the second UTM is going through, but NOT the >>>>>>>>>>>>>>>> states that second UTM simulates in its own processing. >>>>>>>>>>>>>>>>
That second UTM might produce its OWN trace of the >>>>>>>>>>>>>>>> states that it has simulated, but that is a SEPERATE >>>>>>>>>>>>>>>> trace, and NOT part of the trace from the OUTER UTM. >>>>>>>>>>>>>>>>
And this trace is written to the outer UTM's tape as a >>>>>>>>>>>>>>> part of its own data.
Yes, the DATA is there, ENCODED on the tape, but it isn't >>>>>>>>>>>>>> part of the trace generated by that UTM.
The only actual executable is the outer UTM everything else >>>>>>>>>>>>> is a part of the same nested process.
So the only actual valid trace is what that outer simulator >>>>>>>>>>>> actual simulated.
There is a valid trace of every line of code that is
emulated. Operating system code has its trace tuned off. This >>>>>>>>>>> only leaves the user code such as P() and main(). Then we see >>>>>>>>>>> the 14 lines execution trace of the two level simulation of >>>>>>>>>>> the input to H(P,P)
No, because the second level emulation is NOT emulated by the >>>>>>>>>> top level emulator, its emulator is.
Unless you are lying about what H does, you are just lying >>>>>>>>>> that the second level code is emulated by the same emulation >>>>>>>>>> process that the first is. (That may well be true, but it
means you logic is still built on a lie).
If you are too stupid to understand that H(P,P) derives the
same execution trace of its input every time it is called you >>>>>>>>> are far too stupid to evaluate my work.
Ok, then why does the H(P,P) that P calls get stuck in an
infinite recursion wneh the top level doesn't?
It is a verified fact that the correct simulation of the input to >>>>>>> H(P,P) never reaches its final instruction thus conclusively
proving that it never halts.
The only machine that you have shown that does a correct
simulation is the version that never aborts. That version fails to >>>>>> answer the question, so fails to be a halt decider.
Any version of H that aborts, and returns a not-halting answer
changes P into a Halting Compuation.
The "pathological" use of H by P lets it change as you change H,
so if H aborts, it is wrong because THAT P halts, if it doesn't,
then it is wrong for not answering.
You seem to miss this fact because you just don't understand the
basics of how computations work. Part of your problem is you keep
on trying to define H by rules that aren't an actual algorithm, so >>>>>> can't actually be written.
It is an easily verifiable fact that the C function H does
correctly determine that the C function named P would never reach
its last instruction when correctly emulated by H.
Don't just "Claim" it, so an ACTUAL verification, or you just show
yourself to be a liar.
Everyone disagreeing with verified facts is incorrect on the basis
of lack of technical competency or lack of honesty.
You haven't verified ANY fact, you have made claims using FAKE data
that don't even really support your claim.
Software engineering experts
can reverse-engineer what the correct x86 emulation of the input to
H(P,P) would be for one emulation and one nested emulation thus
confirming that the provided execution trace is correct. They can do
this entirely on the basis of the x86 source-code for P with no need
to see the source-code or execution trace of H.
Interesting point, that you eed to talk about "reverse-engineering"
this output implies that you don't actually have a program to generate
it.
Not at all. This program took me a whole man-year.
The most difficult part was to make the nested simulations work correctly.
You don't need to "reverse-engineer" something you have.
No but everyone else does to confirm its correctness because
THEY DON'T HAVE IT.
Anyone unable to do this conclusively proves their lack of sufficient
technical competence.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Richard was able to correctly determine that the correct simulation
of the input to H(P,P) would emulate the first 7 lines of P.
Richard was utterly baffled beyond all comprehension that the
invocation of the same function with the same input would derive the
same trace.
No, that is NOT what I said, and you repeating that LIE just shows you
are not intertested in honest answer. I hope what ever review looks at
your final paper (it you ever get to it) and happens to search and
come accross these discussions and sees your level of dishonesty.
So then you now agree that the nested invocation of H(P,P) would derive
the same execution trace of its input that the the outer one did?
In order to contradict me you must contradict computer science.
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
On 5/22/22 5:06 PM, olcott wrote:
On 5/22/2022 12:36 PM, Richard Damon wrote:
On 5/22/22 12:42 PM, olcott wrote:
On 5/22/2022 11:40 AM, Richard Damon wrote:
On 5/22/22 12:31 PM, olcott wrote:
On 5/22/2022 11:21 AM, Richard Damon wrote:
On 5/22/22 10:57 AM, olcott wrote:
On 5/22/2022 6:06 AM, Richard Damon wrote:
On 5/22/22 1:02 AM, olcott wrote:
On 5/21/2022 11:05 PM, Richard Damon wrote:
On 5/21/22 11:59 PM, olcott wrote:
On 5/21/2022 10:54 PM, Richard Damon wrote:
On 5/21/22 11:36 PM, olcott wrote:
On 5/21/2022 10:27 PM, Richard Damon wrote:
On 5/21/22 10:48 PM, olcott wrote:
On 5/21/2022 9:37 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 5/21/22 10:28 PM, olcott wrote:
On 5/21/2022 9:20 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>
On 5/21/22 9:23 PM, olcott wrote:
On 5/21/2022 8:05 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>
In other words you acknowledge that you are >>>>>>>>>>>>>>>>>>>>>> technically incompetent to provide the execution >>>>>>>>>>>>>>>>>>>>>> trace of one simulation and one nested simulation >>>>>>>>>>>>>>>>>>>>>> of the input to H(P,P).You have known that the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>>>>>>> simulated correctly proving >>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct for the whole six >>>>>>>>>>>>>>>>>>>>>>>>>> months
If H is intended to be a halt decider (even if >>>>>>>>>>>>>>>>>>>>>>>>> only for the one case you
claim to care about) then H(P,P) == 0 is wrong, >>>>>>>>>>>>>>>>>>>>>>>>> because P(P) halts.
When we correctly reverse-engineer what the >>>>>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be >>>>>>>>>>>>>>>>>>>>>>>> for one emulation and one nested emulation we >>>>>>>>>>>>>>>>>>>>>>>> can see that the correctly emulated input to >>>>>>>>>>>>>>>>>>>>>>>> H(P,P) would never reach its final state at >>>>>>>>>>>>>>>>>>>>>>>> machine address [0000136c].
A nonsense trace, as it is mixing the execution >>>>>>>>>>>>>>>>>>>>>>> path of two independent execution units. >>>>>>>>>>>>>>>>>>>>>>>
No, I am saying that you are asking for the >>>>>>>>>>>>>>>>>>>>> equivalent of a of a square circle.
So an execution trace of the input to H(P,P) is easy >>>>>>>>>>>>>>>>>>>> to show when H simulates its input, yet another >>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) that was >>>>>>>>>>>>>>>>>>>> invoked by P is "like a square circle" can't >>>>>>>>>>>>>>>>>>>> possibly exist?
The problem is that your second trace is NOT a piece >>>>>>>>>>>>>>>>>>> of the first.
The fact you don't understand that says you just >>>>>>>>>>>>>>>>>>> don't know how computers or programs actually work. >>>>>>>>>>>>>>>>>>>
When a UTM simulates a TM description that calls a UTM >>>>>>>>>>>>>>>>>> that simulates a
TM description all of this is simply data on the first >>>>>>>>>>>>>>>>>> UTM's tape and the only actual executable is the first >>>>>>>>>>>>>>>>>> UTM.
Yes, and a trace made by that outer UTM will show the >>>>>>>>>>>>>>>>> states that the second UTM is going through, but NOT >>>>>>>>>>>>>>>>> the states that second UTM simulates in its own >>>>>>>>>>>>>>>>> processing.
That second UTM might produce its OWN trace of the >>>>>>>>>>>>>>>>> states that it has simulated, but that is a SEPERATE >>>>>>>>>>>>>>>>> trace, and NOT part of the trace from the OUTER UTM. >>>>>>>>>>>>>>>>>
And this trace is written to the outer UTM's tape as a >>>>>>>>>>>>>>>> part of its own data.
Yes, the DATA is there, ENCODED on the tape, but it isn't >>>>>>>>>>>>>>> part of the trace generated by that UTM.
The only actual executable is the outer UTM everything >>>>>>>>>>>>>> else is a part of the same nested process.
So the only actual valid trace is what that outer simulator >>>>>>>>>>>>> actual simulated.
There is a valid trace of every line of code that is
emulated. Operating system code has its trace tuned off. >>>>>>>>>>>> This only leaves the user code such as P() and main(). Then >>>>>>>>>>>> we see the 14 lines execution trace of the two level
simulation of the input to H(P,P)
No, because the second level emulation is NOT emulated by the >>>>>>>>>>> top level emulator, its emulator is.
Unless you are lying about what H does, you are just lying >>>>>>>>>>> that the second level code is emulated by the same emulation >>>>>>>>>>> process that the first is. (That may well be true, but it >>>>>>>>>>> means you logic is still built on a lie).
If you are too stupid to understand that H(P,P) derives the >>>>>>>>>> same execution trace of its input every time it is called you >>>>>>>>>> are far too stupid to evaluate my work.
Ok, then why does the H(P,P) that P calls get stuck in an
infinite recursion wneh the top level doesn't?
It is a verified fact that the correct simulation of the input >>>>>>>> to H(P,P) never reaches its final instruction thus conclusively >>>>>>>> proving that it never halts.
The only machine that you have shown that does a correct
simulation is the version that never aborts. That version fails
to answer the question, so fails to be a halt decider.
Any version of H that aborts, and returns a not-halting answer
changes P into a Halting Compuation.
The "pathological" use of H by P lets it change as you change H, >>>>>>> so if H aborts, it is wrong because THAT P halts, if it doesn't, >>>>>>> then it is wrong for not answering.
You seem to miss this fact because you just don't understand the >>>>>>> basics of how computations work. Part of your problem is you keep >>>>>>> on trying to define H by rules that aren't an actual algorithm,
so can't actually be written.
It is an easily verifiable fact that the C function H does
correctly determine that the C function named P would never reach
its last instruction when correctly emulated by H.
Don't just "Claim" it, so an ACTUAL verification, or you just show
yourself to be a liar.
Everyone disagreeing with verified facts is incorrect on the basis >>>>>> of lack of technical competency or lack of honesty.
You haven't verified ANY fact, you have made claims using FAKE data
that don't even really support your claim.
Software engineering experts
can reverse-engineer what the correct x86 emulation of the input to
H(P,P) would be for one emulation and one nested emulation thus
confirming that the provided execution trace is correct. They can do
this entirely on the basis of the x86 source-code for P with no need
to see the source-code or execution trace of H.
Interesting point, that you eed to talk about "reverse-engineering"
this output implies that you don't actually have a program to
generate it.
Not at all. This program took me a whole man-year.
Then why do we need to "reverse-engineer" the trace?
The most difficult part was to make the nested simulations work
correctly.
Which it seems you failed at. Maybe that is why ot took so long. It is
hard to make automaticaly believable lies.
You don't need to "reverse-engineer" something you have.
No but everyone else does to confirm its correctness because
THEY DON'T HAVE IT.
No, you present the trace and people can verify it.
Note, it has been pointed out that it does NOT match what you claim is happening, which proves it is WRONG.
The trace implies that H just calls its input, and hides its own behavior.
If it does that, then it can't abort its trace, or isn't actually a computatiopn. (and we see it aborts, and you claim it is a computatiopn)
Thus, the trace is incorrect, or you are lying and the trace doesn't
matter.
Anyone unable to do this conclusively proves their lack of
sufficient technical competence.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P >>>> [0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Richard was able to correctly determine that the correct simulation
of the input to H(P,P) would emulate the first 7 lines of P.
Richard was utterly baffled beyond all comprehension that the
invocation of the same function with the same input would derive the
same trace.
No, that is NOT what I said, and you repeating that LIE just shows
you are not intertested in honest answer. I hope what ever review
looks at your final paper (it you ever get to it) and happens to
search and come accross these discussions and sees your level of
dishonesty.
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer one did?
Yes seem to have a confusion. Yes, the second simulator will produce and identical trace to the first one, AS A SEPERATE TRACE.
In order to contradict me you must contradict computer science.
On 5/22/2022 5:34 PM, Richard Damon wrote:
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
On 5/22/22 5:06 PM, olcott wrote:
On 5/22/2022 12:36 PM, Richard Damon wrote:
On 5/22/22 12:42 PM, olcott wrote:
On 5/22/2022 11:40 AM, Richard Damon wrote:
On 5/22/22 12:31 PM, olcott wrote:
On 5/22/2022 11:21 AM, Richard Damon wrote:
On 5/22/22 10:57 AM, olcott wrote:
On 5/22/2022 6:06 AM, Richard Damon wrote:
On 5/22/22 1:02 AM, olcott wrote:
On 5/21/2022 11:05 PM, Richard Damon wrote:
On 5/21/22 11:59 PM, olcott wrote:
On 5/21/2022 10:54 PM, Richard Damon wrote:
On 5/21/22 11:36 PM, olcott wrote:
On 5/21/2022 10:27 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 5/21/22 10:48 PM, olcott wrote:
On 5/21/2022 9:37 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 5/21/22 10:28 PM, olcott wrote:
On 5/21/2022 9:20 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>
On 5/21/22 9:23 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 5/21/2022 8:05 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>
In other words you acknowledge that you are >>>>>>>>>>>>>>>>>>>>>>> technically incompetent to provide the execution >>>>>>>>>>>>>>>>>>>>>>> trace of one simulation and one nested simulation >>>>>>>>>>>>>>>>>>>>>>> of the input to H(P,P).You have known that the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>>>>>>>> simulated correctly proving >>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct for the whole six >>>>>>>>>>>>>>>>>>>>>>>>>>> months
If H is intended to be a halt decider (even if >>>>>>>>>>>>>>>>>>>>>>>>>> only for the one case you
claim to care about) then H(P,P) == 0 is >>>>>>>>>>>>>>>>>>>>>>>>>> wrong, because P(P) halts. >>>>>>>>>>>>>>>>>>>>>>>>>>
When we correctly reverse-engineer what the >>>>>>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be >>>>>>>>>>>>>>>>>>>>>>>>> for one emulation and one nested emulation we >>>>>>>>>>>>>>>>>>>>>>>>> can see that the correctly emulated input to >>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) would never reach its final state at >>>>>>>>>>>>>>>>>>>>>>>>> machine address [0000136c].
A nonsense trace, as it is mixing the execution >>>>>>>>>>>>>>>>>>>>>>>> path of two independent execution units. >>>>>>>>>>>>>>>>>>>>>>>>
No, I am saying that you are asking for the >>>>>>>>>>>>>>>>>>>>>> equivalent of a of a square circle. >>>>>>>>>>>>>>>>>>>>>
So an execution trace of the input to H(P,P) is >>>>>>>>>>>>>>>>>>>>> easy to show when H simulates its input, yet >>>>>>>>>>>>>>>>>>>>> another execution trace of the input to H(P,P) that >>>>>>>>>>>>>>>>>>>>> was invoked by P is "like a square circle" can't >>>>>>>>>>>>>>>>>>>>> possibly exist?
The problem is that your second trace is NOT a piece >>>>>>>>>>>>>>>>>>>> of the first.
The fact you don't understand that says you just >>>>>>>>>>>>>>>>>>>> don't know how computers or programs actually work. >>>>>>>>>>>>>>>>>>>>
When a UTM simulates a TM description that calls a >>>>>>>>>>>>>>>>>>> UTM that simulates a
TM description all of this is simply data on the >>>>>>>>>>>>>>>>>>> first UTM's tape and the only actual executable is >>>>>>>>>>>>>>>>>>> the first UTM.
Yes, and a trace made by that outer UTM will show the >>>>>>>>>>>>>>>>>> states that the second UTM is going through, but NOT >>>>>>>>>>>>>>>>>> the states that second UTM simulates in its own >>>>>>>>>>>>>>>>>> processing.
That second UTM might produce its OWN trace of the >>>>>>>>>>>>>>>>>> states that it has simulated, but that is a SEPERATE >>>>>>>>>>>>>>>>>> trace, and NOT part of the trace from the OUTER UTM. >>>>>>>>>>>>>>>>>>
And this trace is written to the outer UTM's tape as a >>>>>>>>>>>>>>>>> part of its own data.
Yes, the DATA is there, ENCODED on the tape, but it >>>>>>>>>>>>>>>> isn't part of the trace generated by that UTM.
The only actual executable is the outer UTM everything >>>>>>>>>>>>>>> else is a part of the same nested process.
So the only actual valid trace is what that outer
simulator actual simulated.
There is a valid trace of every line of code that is >>>>>>>>>>>>> emulated. Operating system code has its trace tuned off. >>>>>>>>>>>>> This only leaves the user code such as P() and main(). Then >>>>>>>>>>>>> we see the 14 lines execution trace of the two level >>>>>>>>>>>>> simulation of the input to H(P,P)
No, because the second level emulation is NOT emulated by >>>>>>>>>>>> the top level emulator, its emulator is.
Unless you are lying about what H does, you are just lying >>>>>>>>>>>> that the second level code is emulated by the same emulation >>>>>>>>>>>> process that the first is. (That may well be true, but it >>>>>>>>>>>> means you logic is still built on a lie).
If you are too stupid to understand that H(P,P) derives the >>>>>>>>>>> same execution trace of its input every time it is called you >>>>>>>>>>> are far too stupid to evaluate my work.
Ok, then why does the H(P,P) that P calls get stuck in an
infinite recursion wneh the top level doesn't?
It is a verified fact that the correct simulation of the input >>>>>>>>> to H(P,P) never reaches its final instruction thus conclusively >>>>>>>>> proving that it never halts.
The only machine that you have shown that does a correct
simulation is the version that never aborts. That version fails >>>>>>>> to answer the question, so fails to be a halt decider.
Any version of H that aborts, and returns a not-halting answer >>>>>>>> changes P into a Halting Compuation.
The "pathological" use of H by P lets it change as you change H, >>>>>>>> so if H aborts, it is wrong because THAT P halts, if it doesn't, >>>>>>>> then it is wrong for not answering.
You seem to miss this fact because you just don't understand the >>>>>>>> basics of how computations work. Part of your problem is you
keep on trying to define H by rules that aren't an actual
algorithm, so can't actually be written.
It is an easily verifiable fact that the C function H does
correctly determine that the C function named P would never reach >>>>>>> its last instruction when correctly emulated by H.
Don't just "Claim" it, so an ACTUAL verification, or you just show >>>>>> yourself to be a liar.
Everyone disagreeing with verified facts is incorrect on the
basis of lack of technical competency or lack of honesty.
You haven't verified ANY fact, you have made claims using FAKE
data that don't even really support your claim.
Software engineering experts
can reverse-engineer what the correct x86 emulation of the input to
H(P,P) would be for one emulation and one nested emulation thus
confirming that the provided execution trace is correct. They can
do this entirely on the basis of the x86 source-code for P with no
need to see the source-code or execution trace of H.
Interesting point, that you eed to talk about "reverse-engineering"
this output implies that you don't actually have a program to
generate it.
Not at all. This program took me a whole man-year.
Then why do we need to "reverse-engineer" the trace?
It is the only way that you can verify that this trace is correct:
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= ============= ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
The most difficult part was to make the nested simulations work
correctly.
Which it seems you failed at. Maybe that is why ot took so long. It is
hard to make automaticaly believable lies.
You don't need to "reverse-engineer" something you have.
No but everyone else does to confirm its correctness because
THEY DON'T HAVE IT.
No, you present the trace and people can verify it.
Note, it has been pointed out that it does NOT match what you claim is
happening, which proves it is WRONG.
THIS HAS NEVER BEEN MORE THAN A BASELESS ASSERTION.
The trace implies that H just calls its input, and hides its own
behavior.
I hrrd code the system to never output the trace of operating system code.
If it does that, then it can't abort its trace, or isn't actually a
computatiopn. (and we see it aborts, and you claim it is a computatiopn)
Thus, the trace is incorrect, or you are lying and the trace doesn't
matter.
Anyone unable to do this conclusively proves their lack of
sufficient technical competence.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
Richard was able to correctly determine that the correct simulation
of the input to H(P,P) would emulate the first 7 lines of P.
Richard was utterly baffled beyond all comprehension that the
invocation of the same function with the same input would derive
the same trace.
No, that is NOT what I said, and you repeating that LIE just shows
you are not intertested in honest answer. I hope what ever review
looks at your final paper (it you ever get to it) and happens to
search and come accross these discussions and sees your level of
dishonesty.
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer one did? >>>
Yes seem to have a confusion. Yes, the second simulator will produce
and identical trace to the first one, AS A SEPERATE TRACE.
I don't have any confusion. You have rebuttal of my work as your only
goal. As soon as I pointed out the a rebuttal of what I said would
directly contradict computer science you backed down because you knew
you couldn't get way with it.
So then you agree that the invocation of H(P,P) would derive the
following trace of its input on the first 7 lines and when P invokes
another instance of H(P,P) this derives the next 7 lines of execution
trace.
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
In order to contradict me you must contradict computer science.
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer one did?
Yes seem to have a confusion. Yes, the second simulator will produce and identical trace to the first one, AS A SEPERATE TRACE.
The issue is you can not validly "combine" them into a single trace,
that is just a lie. The first simulator needs to show its trace of the instructions of the second simulator doing its simulation.
I suppose if you want, you can omit that with a note of omitted detail,
but the the trace goes to the call, says details omited, then the notice
that the trace was aborted, but then you don't have any grounds to claim
that it was correct (since there aren't any).
In order to contradict me you must contradict computer science.
Nope, YOU do that enough.
On 5/22/2022 5:34 PM, Richard Damon wrote:
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer one did? >>>
Yes seem to have a confusion. Yes, the second simulator will produce
and identical trace to the first one, AS A SEPERATE TRACE.
So the first invocation of H(P,P) derives this trace
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
And the second (nested) invocation of H(P,P) derives this trace ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
From this we can see the pattern that the C/x86 function named P will
never reach its last instruction, thus conclusively proving that when
H(P,P) rejects its input as non-halting it is correct.
The issue is you can not validly "combine" them into a single trace,
that is just a lie. The first simulator needs to show its trace of the
instructions of the second simulator doing its simulation.
So when I show the trace of main() this trace is a lie? I show the trace
of every line of user code and none of these traces are a lie.
I suppose if you want, you can omit that with a note of omitted
detail, but the the trace goes to the call, says details omited, then
the notice that the trace was aborted, but then you don't have any
grounds to claim that it was correct (since there aren't any).
In order to contradict me you must contradict computer science.
Nope, YOU do that enough.
On 5/22/22 7:16 PM, olcott wrote:The fact that I just proved that the simulated input to H(P,P) never
On 5/22/2022 5:34 PM, Richard Damon wrote:
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer one
did?
Yes seem to have a confusion. Yes, the second simulator will produce
and identical trace to the first one, AS A SEPERATE TRACE.
So the first invocation of H(P,P) derives this trace
Begin Local Halt Decider Simulation Execution Trace Stored at:212352
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
And the second (nested) invocation of H(P,P) derives this trace
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
From this we can see the pattern that the C/x86 function named P will
never reach its last instruction, thus conclusively proving that when
H(P,P) rejects its input as non-halting it is correct.
No, because the whole second trace is conditioned on the halt deciding
of H. So, if the top level H aborts at that point, then the trace become incorrect by being incomplete (it doesn't show the FULL Halting behavior
of the input, which refers to the machine it represents, which did not
halt there.
On 5/22/22 7:59 PM, olcott wrote:
On 5/22/2022 6:52 PM, Richard Damon wrote:
On 5/22/22 7:16 PM, olcott wrote:The fact that I just proved that the simulated input to H(P,P) never
On 5/22/2022 5:34 PM, Richard Damon wrote:
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer
one did?
Yes seem to have a confusion. Yes, the second simulator will
produce and identical trace to the first one, AS A SEPERATE TRACE.
So the first invocation of H(P,P) derives this trace
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
And the second (nested) invocation of H(P,P) derives this trace
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
From this we can see the pattern that the C/x86 function named P
will never reach its last instruction, thus conclusively proving
that when H(P,P) rejects its input as non-halting it is correct.
No, because the whole second trace is conditioned on the halt
deciding of H. So, if the top level H aborts at that point, then the
trace become incorrect by being incomplete (it doesn't show the FULL
Halting behavior of the input, which refers to the machine it
represents, which did not halt there.
reaches its own final state conclusively proves that it is non-halting
regardless of whether or not it stops running.
You proved that the INCOMPLETE simulation of the input by H doesn't
reach a final state.
NOT that the CORRECT simulation of the input by a CORRECT simulator
doesn't.
You just are proving that you don't know the meaning of CORRECT. (or are
just lying).
On 5/22/2022 6:52 PM, Richard Damon wrote:
On 5/22/22 7:16 PM, olcott wrote:The fact that I just proved that the simulated input to H(P,P) never
On 5/22/2022 5:34 PM, Richard Damon wrote:
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
So then you now agree that the nested invocation of H(P,P) would
derive the same execution trace of its input that the the outer one
did?
Yes seem to have a confusion. Yes, the second simulator will produce
and identical trace to the first one, AS A SEPERATE TRACE.
So the first invocation of H(P,P) derives this trace
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
And the second (nested) invocation of H(P,P) derives this trace
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
From this we can see the pattern that the C/x86 function named P
will never reach its last instruction, thus conclusively proving that
when H(P,P) rejects its input as non-halting it is correct.
No, because the whole second trace is conditioned on the halt deciding
of H. So, if the top level H aborts at that point, then the trace
become incorrect by being incomplete (it doesn't show the FULL Halting
behavior of the input, which refers to the machine it represents,
which did not halt there.
reaches its own final state conclusively proves that it is non-halting regardless of whether or not it stops running.
On 5/22/2022 7:21 PM, Richard Damon wrote:
On 5/22/22 7:59 PM, olcott wrote:
On 5/22/2022 6:52 PM, Richard Damon wrote:
On 5/22/22 7:16 PM, olcott wrote:The fact that I just proved that the simulated input to H(P,P) never
On 5/22/2022 5:34 PM, Richard Damon wrote:
On 5/22/22 5:59 PM, olcott wrote:
On 5/22/2022 4:34 PM, Richard Damon wrote:
So then you now agree that the nested invocation of H(P,P) would >>>>>>> derive the same execution trace of its input that the the outer
one did?
Yes seem to have a confusion. Yes, the second simulator will
produce and identical trace to the first one, AS A SEPERATE TRACE.
So the first invocation of H(P,P) derives this trace
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 >>>>> ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H >>>>>
And the second (nested) invocation of H(P,P) derives this trace
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H >>>>>
From this we can see the pattern that the C/x86 function named P
will never reach its last instruction, thus conclusively proving
that when H(P,P) rejects its input as non-halting it is correct.
No, because the whole second trace is conditioned on the halt
deciding of H. So, if the top level H aborts at that point, then the
trace become incorrect by being incomplete (it doesn't show the FULL
Halting behavior of the input, which refers to the machine it
represents, which did not halt there.
reaches its own final state conclusively proves that it is
non-halting regardless of whether or not it stops running.
You proved that the INCOMPLETE simulation of the input by H doesn't
reach a final state.
So in other words you simply are not bright enough to understand that
the emulated P can't possibly ever reach its own last instruction.
I honestly can't believe that you are that stupid.
NOT that the CORRECT simulation of the input by a CORRECT simulator
doesn't.
You just are proving that you don't know the meaning of CORRECT. (or
are just lying).
... it is non-halting regardless of whether or not it stops running.
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
On 5/23/2022 6:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.
On 5/23/22 7:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
As near as I can figure it, Peter thinks that because H stops simulating
its P input, that P never halts, because that copy never gets to the
final state that a fully run P will get to.
On 5/23/2022 8:58 AM, Python wrote:
Peter Olcott, demented kook, wrote:
On 5/23/2022 6:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.
This is not even remotely related to your absurd claims, come on Peter!
Halting DOES NOT MEAN STOPS RUNNING,
Halting means reaches its final state.
Peter Olcott, demented kook, wrote:
On 5/23/2022 6:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.
This is not even remotely related to your absurd claims, come on Peter!
Peter Olcott, old fart, wrote:
On 5/23/2022 8:58 AM, Python wrote:
Peter Olcott, demented kook, wrote:
On 5/23/2022 6:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running. >>>>>This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.
This is not even remotely related to your absurd claims, come on Peter!
Halting DOES NOT MEAN STOPS RUNNING,
Halting means reaches its final state.
*facepalm*
Peter Olcott wrote:Insightful observation. I have been curious, since he is now a
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
On 5/23/2022 5:55 AM, Python wrote:
Peter Olcott wrote:Insightful observation. I have been curious, since he is now a
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
pathological liar, whether he lies about cancer too. I wouldn't be
surprised. As to cognitive disorders, I believe he his learning
disabilities compounded by the attention span of a roach. I don't
believe that any thing said here will cure any of his observed issues.
As a test, I speculate he will respond to this message, if at all, with either many identical lines of capitol letters or yet another copy of
his faked up trace. Gentlemen, Place Your Bets!
On 5/23/2022 6:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.
On 5/23/2022 7:22 AM, Richard Damon wrote:
On 5/23/22 7:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
As near as I can figure it, Peter thinks that because H stops
simulating its P input, that P never halts, because that copy never
gets to the final state that a fully run P will get to.
Begin Local Halt Decider Simulation Execution Trace Stored at:212352 ...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp ...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08] ...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08] ...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08] ...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
In other words you are simply too freaking stupid to understand that the correctly simulated P never reaches its last instruction whether or not
this simulation is ever aborted.
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
On 5/23/2022 8:58 AM, Python wrote:
Peter Olcott, demented kook, wrote:
On 5/23/2022 6:55 AM, Python wrote:
Peter Olcott wrote:
... it is non-halting regardless of whether or not it stops running.
This is quite a serious cognitive dissonance to be able to
write down such a sentence and believe it.
Cancer is not the worse illness you have, Peter.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.
This is not even remotely related to your absurd claims, come on Peter!
Halting DOES NOT MEAN STOPS RUNNING,
Halting means reaches its final state.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 106:00:40 |
| Calls: | 6,661 |
| Calls today: | 3 |
| Files: | 12,209 |
| Messages: | 5,335,401 |