NO ONE HERE UNDERSTANDS THIS

[olcott]

*NO ONE HERE UNDERSTANDS THIS*
It is impossible to have the necessary consequence of three premises to
be false when the premises are true. (details below)



H correctly simulates its input D until H correctly determines that its
simulated D would never stop running unless aborted

(a) A halt decider must report on the actual behavior specified by its
input.

(b) The definition of a universal Turing machine (UTM) specifies that
the correct simulation of a machine description provides the actual
behavior specified by this machine description.

(c) A correctly simulated input that would never stop running unless
aborted specifies non-halting behavior.

(d) H correctly determines that D specifies a non-halting behavior.

{a,b,c} ⊨ (d) // intended as notation for sound deduction

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[wij]

On Thursday, November 17, 2022 at 2:40:45 PM UTC+8, olcott wrote:
> *NO ONE HERE UNDERSTANDS THIS*
> It is impossible to have the necessary consequence of three premises to
> be false when the premises are true. (details below)

> ..[cut]

> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
> Genius hits a target no one else can see." Arthur Schopenhauer

You said "H returns 0 to main()" means "H halts".
So, "D returns to main()" means "D halts". Do you agree?

int main() {
D(D);
}

[olcott]

Because halt deciders compute the mapping from their inputs to
an accept or reject state it is dishonest of you to slip in
the behavior of non-inputs.

In order for a simulating halt decider to be wrong it must provide
the halt status of its correctly simulated input that does not
correspond to the behavior of this correctly simulated input

--

[Mikko]

On 2022-11-17 06:40:23 +0000, olcott said:

> *NO ONE HERE UNDERSTANDS THIS*
> It is impossible to have the necessary consequence of three premises to
> be false when the premises are true. (details below)
>
>
>
> H correctly simulates its input D until H correctly determines that its
> simulated D would never stop running unless aborted
>
> (a) A halt decider must report on the actual behavior specified by its input.
>
> (b) The definition of a universal Turing machine (UTM) specifies that
> the correct simulation of a machine description provides the actual
> behavior specified by this machine description.
>
> (c) A correctly simulated input that would never stop running unless
> aborted specifies non-halting behavior.
>
> (d) H correctly determines that D specifies a non-halting behavior.
>
> {a,b,c} ⊨ (d) // intended as notation for sound deduction

The conclusion does not follow. (b) is about UTM which is not mentioned
in other premises nor in the conclusion. Therefore it contributes nothing
to the conclusion. (c) is counterfactual so its logical meaning is not
clear. Therefore it does not support (d). (a) is not specifiec: an
algorithm may satisfy (a) without being a halt decider.

Mikko

[olcott]

On 11/17/2022 10:52 AM, Mikko wrote:
> On 2022-11-17 06:40:23 +0000, olcott said:
>
>> *NO ONE HERE UNDERSTANDS THIS*
>> It is impossible to have the necessary consequence of three premises
>> to be false when the premises are true. (details below)
>>
>>
>>
>> H correctly simulates its input D until H correctly determines that
>> its simulated D would never stop running unless aborted
>>
>> (a) A halt decider must report on the actual behavior specified by its
>> input.
>>
>> (b) The definition of a universal Turing machine (UTM) specifies that
>> the correct simulation of a machine description provides the actual
>> behavior specified by this machine description.
>>
>> (c) A correctly simulated input that would never stop running unless
>> aborted specifies non-halting behavior.
>>
>> (d) H correctly determines that D specifies a non-halting behavior.
>>
>> {a,b,c} ⊨ (d)  // intended as notation for sound deduction
>
> The conclusion does not follow. (b) is about UTM which is not mentioned

(b) Is not about a UTM it is about the correct simulation of a machine
description producing the actual behavior specified by this machine
description.

> in other premises nor in the conclusion. Therefore it contributes nothing
> to the conclusion. (c) is counterfactual so its logical meaning is not

Is not counter-factual, it may be beyond your comprehension.

An alternative wording would be that H correctly predicts that
D correctly simulated by H would not reach its own final state and
terminate normally in 1 to ∞ steps of correct simulation.

> clear. Therefore it does not support (d). (a) is not specifiec: an
> algorithm may satisfy (a) without being a halt decider.
>

(a) Specifically excludes the behavior of non-inputs when these
non-inputs have behavior that differs from the behavior of D correctly
simulated by H. This only happens with pathological inputs.

> Mikko

[olcott]

On 11/17/2022 5:59 PM, Fritz Feldhase wrote:

> On Thursday, November 17, 2022 at 6:37:21 PM UTC+1, _ Olcott wrote:
>
>> (a) A halt decider must report on the actual behavior specified by its
>> input.
>

> Indeed!
>
> So let's make clear some things first:
>
> 1. H is a syntactically correct "program" (or function) that will run without runtime errors and terminate _for any input_. We will assume that H(X, X) returns false if X is either a syntactically incorrect program or if X produces a runtime error with input X. In all other cases H will comply with (a).
>
> 2. H is a correct halt decider. [...]
>
> 3. Based on 1. we will assume that
>
> void D(void (*x)())
> {
> bool Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> is a syntactically correct "program" (or function) that will run without runtime errors for input D.
>
> Rationale: We "know" by 1. that H is syntactically correct and will run without runtime errors. [...]
>
> ____________________________________
>
> Now some short considerations:
>
> We have:
>
> void D(void (*x)())
> {
> bool Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> Now D(D) either halts or doesn't halt. Right?
>
> If H is a _correct_ halt decider H(D, D) will return true iff D(D) halts and it will return false iff D(D) doesn't halt. Right?
>
> Slightly modified main program:
>
> int main()
> {
> Output("D(D) halts: ", (String)H(D, D));
> }
>
> Now there are exactly _two_ possibilities, namely that H(D, D) returns true or it returns false, right?
>
> So let's (a) assume that H(D, D) returns true. If H(D, D) returns true, D(D) will not halt (since Halt_Status will be true in this case and that means that D(D) loops).
>
> So in this case D(D) does not halt, but main will produce the output ""D(D) halts: true", since H falsely "determines" that D(D) *will* halt.
>
> Now let's assume (b) that H(D, D) returns false. If H(D, D) returns false, D(D) will halt (since Halt_Status will be false in this case and that means that D(D) returns).
>
> So in this case D(D) does halt, but main will produce the output ""D(D) halts: false", since H falsely "determines" that D(D) *will not* halt.
>
> So in ANY CASE H does NOT correctly determine the behaviour of D (with input D).
>
> Conclusion H is not a correct halt decider (since H does not correctly determine the halt status of D (with input D)).
>
> ______________________________
>
> Could you, Mr. Olcott, please point out the error I made?
>
> P.S. Note that these considerations needn't take into account the "inner workings" of H.
>

NO ONE HERE UNDERSTANDS THIS
Anyone that sufficiently understands sound deductive inference knows
that when {a,b,c} are true and (d) is a necessary consequence of {a,b,c}
that nothing in the universe can possibly show that (d) is not true.

NO ONE HERE UNDERSTANDS THIS
Anyone that sufficiently understands sound deductive inference knows
that when {a,b,c} are true and (d) is a necessary consequence of {a,b,c}
that nothing in the universe can possibly show that (d) is not true.

NO ONE HERE UNDERSTANDS THIS
Anyone that sufficiently understands sound deductive inference knows
that when {a,b,c} are true and (d) is a necessary consequence of {a,b,c}
that nothing in the universe can possibly show that (d) is not true.

(a) A halt decider must report on the actual behavior specified by its
input.

(b) The definition of a universal Turing machine (UTM) specifies that
the correct simulation of a machine description provides the actual
behavior specified by this machine description.

(c) A correctly simulated input that would never stop running unless
aborted specifies non-halting behavior.

(d) H correctly determines that D specifies a non-halting behavior.

[Richard Damon]

On 11/17/22 11:19 AM, olcott wrote:
> On 11/17/2022 5:53 AM, wij wrote:
>> On Thursday, November 17, 2022 at 2:40:45 PM UTC+8, olcott wrote:
>>> *NO ONE HERE UNDERSTANDS THIS*
>>> It is impossible to have the necessary consequence of three premises to
>>> be false when the premises are true. (details below)
>>> ..[cut]
>>> Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see." Arthur Schopenhauer
>>
>> You said "H returns 0 to main()" means "H halts".
>> So, "D returns to main()" means "D halts". Do you agree?
>>
>> int main() {
>>    D(D);
>> }
>
> Because halt deciders compute the mapping from their inputs to
> an accept or reject state it is dishonest of you to slip in
> the behavior of non-inputs.

Right, H needs to answer about the D that is built from the H that is
claimed to be correc.

>
> In order for a simulating halt decider to be wrong it must provide
> the halt status of its correctly simulated input that does not
> correspond to the behavior of this correctly simulated input
>

For a simulatiion to BE correct, it must actually be correct, and for
this input.

This input is built on this H, and your arguement has a DIFFERENT H
"correctly" simulate a DIFFERENT D that is built on that DIFFERENT H.

So YOUR arguement is the one looking at the non-input.

Remember, program D includes the code of the H it calls, so you can not
change it when doing your simulation.

D is defined to call the ONE H that is being claimed to be correct (if
you claim multiple H's are correct, then you need to test each one
individually).

Thus, when you do your 1 to infinite steps, you need to give each of
those machins THAT D, that calls THAT H, not the H that is simulating
for some other number N steps.

[Richard Damon]

On 11/17/22 7:49 PM, olcott wrote:
>
> NO ONE HERE UNDERSTANDS THIS
> Anyone that sufficiently understands sound deductive inference knows
> that when {a,b,c} are true and (d) is a necessary consequence of {a,b,c}
> that nothing in the universe can possibly show that (d) is not true.
>
> NO ONE HERE UNDERSTANDS THIS
> Anyone that sufficiently understands sound deductive inference knows
> that when {a,b,c} are true and (d) is a necessary consequence of {a,b,c}
> that nothing in the universe can possibly show that (d) is not true.
>
> NO ONE HERE UNDERSTANDS THIS
> Anyone that sufficiently understands sound deductive inference knows
> that when {a,b,c} are true and (d) is a necessary consequence of {a,b,c}
> that nothing in the universe can possibly show that (d) is not true.
>
>
>
> (a) A halt decider must report on the actual behavior specified by its
> input.
>
> (b) The definition of a universal Turing machine (UTM) specifies that
> the correct simulation of a machine description provides the actual
> behavior specified by this machine description.
>
> (c) A correctly simulated input that would never stop running unless
> aborted specifies non-halting behavior.
>
> (d) H correctly determines that D specifies a non-halting behavior.
>

No, YOU don't seem to understand what you are saying,

NOWHERE in (a), (b), or (c) does ANY statement actually show that H
actually DID a correct simulation, but were all based on the need to DO
a correct simulaiton.

(b) DEFINES what a correct simulation is, which is contrary to the
definition you try to use to claim that H is correct, and thus is
DISPROVES your arguement that H is correct in its simulation.

You just seem to be too stupid to understand that fact.

The UTM definition says that the correct simulation of an input will
behave EXACTLY like the direct execution of the machine that the input
represents.

Thus the correct simulation of the input to H(P,P) is EXACTLY the
behavior of P(P), and even you have admitted that P(P) will Halt if
H(P,P) returns 0, that H can NEVER "prove" that the "correct simulaiton"
of the input to H(P,P) will never halt, as the input does halt.

You are just stuck in your illogic.

[Mikko]

On 2022-11-17 17:37:16 +0000, olcott said:

> On 11/17/2022 10:52 AM, Mikko wrote:
>> On 2022-11-17 06:40:23 +0000, olcott said:

>>> (b) The definition of a universal Turing machine (UTM) specifies that
>>> the correct simulation of a machine description provides the actual
>>> behavior specified by this machine description.

> (b) Is not about a UTM it is about the correct simulation of a machine
> description producing the actual behavior specified by this machine
> description.

It is not possible to express the meaning of (b) without mentioning "UTM"
by that or another name. If the UTM is removed from (b) then nothing i
left. Therefore (b) obviously is obout universal Turing machines.

Mikko

[Mikko]

On 2022-11-17 17:37:16 +0000, olcott said:

> On 11/17/2022 10:52 AM, Mikko wrote:
>> On 2022-11-17 06:40:23 +0000, olcott said:
>>
>>> (c) A correctly simulated input that would never stop running unless
>>> aborted specifies non-halting behavior.

>> (c) is counterfactual so its logical meaning is not
>
> Is not counter-factual, it may be beyond your comprehension.

The meaning of the word "would" is that the containing clause is
counterfactual. Otherwise there would be "does" instead.

> An alternative wording would be that H correctly predicts that
> D correctly simulated by H would not reach its own final state and
> terminate normally in 1 to ∞ steps of correct simulation.

That is counterfactual, too, and therefore no better for sound
deduction.

Mikko

[Mikko]

On 2022-11-17 17:37:16 +0000, olcott said:

>> On 2022-11-17 06:40:23 +0000, olcott said:
>>
>>> (a) A halt decider must report on the actual behavior specified by its input.

> (a) Specifically excludes the behavior of non-inputs when these
> non-inputs have behavior that differs from the behavior of D correctly
> simulated by H. This only happens with pathological inputs.

If a "non-input" is used for any purpose it is no longer a "non-input"
but an actual input. Therefore (a) does not say anything.

Mikko

[olcott]

It is not about universal Turing machines it is about how the definition
of a UTM validates one aspect of a simulating halt decider:

every correct simulation of a machine description (by a UTM or a
simulating halt decider ) does provide the actual behavior specified
by this machine description.

[olcott]

H: Begin Simulation Execution Trace Stored at:112afc
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000019e3][00112ae8][00112aec] 55 push ebp // begin D
[000019e4][00112ae8][00112aec] 8bec mov ebp,esp
[000019e6][00112ae4][00102ab8] 51 push ecx
[000019e7][00112ae4][00102ab8] 8b4508 mov eax,[ebp+08]
[000019ea][00112ae0][000019e3] 50 push eax // push D
[000019eb][00112ae0][000019e3] 8b4d08 mov ecx,[ebp+08]
[000019ee][00112adc][000019e3] 51 push ecx // push D
[000019ef][00112ad8][000019f4] e88ff9ffff call 00001383 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

We can see that the first seven instructions of D simulated by H
precisely match the first seven instructions of the x86 source-code of
D. This conclusively proves that these instructions were simulated
correctly.

Anyone sufficiently technically competent in the x86 programming
language will agree that the above execution trace of D simulated by H
shows that D will never stop running unless H aborts its simulation of D.

H detects that D is calling itself with the exact same arguments that H
was called with and there are no conditional branch instructions from
the beginning of D to its call to H that can possibly escape the
repetition of this recursive simulation.

[olcott]

Where do you get this crazy shit?

int sum(int x, int y)
{
return x + y;
}

THIS IS WHAT YOUR WORDS LITERALLY MEAN
When I say that (5,7) is not an input to sum(3,4)
then (5,7) magically becomes an input to sum(3,4).

[Mikko]

On 2022-11-18 15:24:25 +0000, olcott said:

> On 11/18/2022 5:19 AM, Mikko wrote:
>> On 2022-11-17 17:37:16 +0000, olcott said:
>>
>>>> On 2022-11-17 06:40:23 +0000, olcott said:
>>>>
>>>>> (a) A halt decider must report on the actual behavior specified by its input.
>>
>>> (a) Specifically excludes the behavior of non-inputs when these
>>> non-inputs have behavior that differs from the behavior of D correctly
>>> simulated by H. This only happens with pathological inputs.
>>
>> If a "non-input" is used for any purpose it is no longer a "non-input"
>> but an actual input. Therefore (a) does not say anything.
>>
>> Mikko
>>
>
> Where do you get this crazy shit?

From the meaning of the word "input" as that word is used when
discussing computations and related stuff; and from the common
meaning of the prefix "non-".

Mikko

[olcott]

When I say input to a function I mean its arguments.

H(D,D) does correctly determine the halt status of its arguments and the
following definition of a simulating halt decider.

MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):

If simulating halt decider H correctly simulates its input

D until H correctly determines that its simulated D would

never stop running unless aborted then H can abort its
simulation of D and correctly report that D specifies a
non-halting sequence of configurations.

According to that definition H(D,D) correctly determines that D
specifies a non-halting sequence of configurations.

[Mikko]

You need a very many intermediate steps if you try to use that as a
replacement of (c) in your deduction.

Mikko

[olcott]

The above steps provide conclusive proof that D correctly simulated by H
would never stop running unless aborted.

[Mikko]

On 2022-11-18 15:13:04 +0000, olcott said:

> On 11/18/2022 5:05 AM, Mikko wrote:
>> On 2022-11-17 17:37:16 +0000, olcott said:
>>
>>> On 11/17/2022 10:52 AM, Mikko wrote:
>>>> On 2022-11-17 06:40:23 +0000, olcott said:
>>
>>>>> (b) The definition of a universal Turing machine (UTM) specifies that
>>>>> the correct simulation of a machine description provides the actual
>>>>> behavior specified by this machine description.
>>
>>> (b) Is not about a UTM it is about the correct simulation of a machine
>>> description producing the actual behavior specified by this machine
>>> description.
>>
>> It is not possible to express the meaning of (b) without mentioning "UTM"
>> by that or another name. If the UTM is removed from (b) then nothing i
>> left. Therefore (b) obviously is obout universal Turing machines.
>>
>> Mikko
>>
>
> It is not about universal Turing machines it is about how the definition
> of a UTM validates one aspect of a simulating halt decider:
>
> every correct simulation of a machine description (by a UTM or a
> simulating halt decider ) does provide the actual behavior specified
> by this machine description.

Your "deduction" does not transfer any aspects of a UTM simulation to
any other simulation.

Mikko

[olcott]

Sure it does. I have already shown that above. Every correct simulation
of a machine description always provides the actual behavior specified
by the machine description.

[Richard Damon]

On 11/18/22 10:13 AM, olcott wrote:
> On 11/18/2022 5:05 AM, Mikko wrote:
>> On 2022-11-17 17:37:16 +0000, olcott said:
>>
>>> On 11/17/2022 10:52 AM, Mikko wrote:
>>>> On 2022-11-17 06:40:23 +0000, olcott said:
>>
>>>>> (b) The definition of a universal Turing machine (UTM) specifies
>>>>> that the correct simulation of a machine description provides the
>>>>> actual behavior specified by this machine description.
>>
>>> (b) Is not about a UTM it is about the correct simulation of a
>>> machine description producing the actual behavior specified by this
>>> machine description.
>>
>> It is not possible to express the meaning of (b) without mentioning "UTM"
>> by that or another name. If the UTM is removed from (b) then nothing i
>> left. Therefore (b) obviously is obout universal Turing machines.
>>
>> Mikko
>>
>
> It is not about universal Turing machines it is about how the definition
> of a UTM validates one aspect of a simulating halt decider:
>
> every correct simulation of a machine description (by a UTM or a
> simulating halt decider ) does provide the actual behavior specified
> by this machine description.
>

Says WHO? (about the SHD)

Unsupported claims from a proven liar don't mean anything, just that
they are the liar.

Since there is exact ONE correct simulation of a given input, and your
SHD gives a different ansswer than teh UTM, means you SHD is just wrong.

Your consistant habit of making unsubstatiated (and unsubstatiatable)
claims just proves you are totally ignorant of the material you are
talking about, and about the field of logic in general.

You are basically destroyer the ability of anyone with any intelegence
of taking anything you say seriously.

[Mikko]

No, it doesn't. It doesn't even mention any other simulation in the same
sentence with UTM.

Mikko

[olcott]

--
Copyright 2022 Olcott "Talent hits a target no one else can hit; Genius

[Mikko]

For a UTM that follows from the definition. For a "simulating halt decider"
that is not proven.

Mikko

[Richard Damon]

No, only COMPLETE correct simulations do that.

PARTIAL simulation indicated "Has Halted Already", or "Hasn't Halted
Yet", not "Halting" and "Non-Halting", as the definition of Halting is
that it will eventually reach a final state (in some finite but
unspecified number of steps) and non-halting is that it will NEVER reach
a final state, even if we run it for an unbounded number of steps.

Your ignorance of the behavior of the non-finite seems to be a source of
your problems.

[olcott]

The definition of a UTM specifies that the correct simulation of a
machine description always produces the actual behavior specified by
this machine description. You can comprehend this or fail to comprehend
it disagreement is incorrect.

[Richard Damon]

No, the definition of a UTM stipulates that a simulaiton of a machine
description is only correct if it produces the actual behavior of the
machine the description is of. It is defining a UTM based on that it
reproduces the original machine behavior, and thus implies what it meens
to be "correct"

This means that the only "Correct Simulation" by this definition is a
COMPLETE correct simulation.

You have your conditions reversed, because you don't seem to actually
understand how English works.

[olcott]

Your convoluted misdirection cannot possibly show that the simulation is
incorrect. For a simulation to be incorrect the simulator must execute
an instruction that the x86 source code of E does not specify.

void E(void (*x)())
{
H(x, x);
}

int main()
{
H(E,E);
}

_E()
[000019c3] 55 push ebp
[000019c4] 8bec mov ebp,esp
[000019c6] 8b4508 mov eax,[ebp+08]
[000019c9] 50 push eax
[000019ca] 8b4d08 mov ecx,[ebp+08]
[000019cd] 51 push ecx
[000019ce] e8b0f9ffff call 00001383
[000019d3] 83c408 add esp,+08
[000019d6] 5d pop ebp
[000019d7] c3 ret
Size in bytes:(0021) [000019d7]

_main()
[000019e3] 55 push ebp
[000019e4] 8bec mov ebp,esp
[000019e6] 68c3190000 push 000019c3
[000019eb] 68c3190000 push 000019c3
[000019f0] e88ef9ffff call 00001383
[000019f5] 83c408 add esp,+08
[000019f8] 33c0 xor eax,eax
[000019fa] 5d pop ebp
[000019fb] c3 ret
Size in bytes:(0025) [000019fb]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

[000019e3][00102a39][00000000] 55 push ebp
[000019e4][00102a39][00000000] 8bec mov ebp,esp
[000019e6][00102a35][000019c3] 68c3190000 push 000019c3
[000019eb][00102a31][000019c3] 68c3190000 push 000019c3
[000019f0][00102a2d][000019f5] e88ef9ffff call 00001383

H: Begin Simulation Execution Trace Stored at:112ae5
Address_of_H:1383
[000019c3][00112ad1][00112ad5] 55 push ebp // begin E
[000019c4][00112ad1][00112ad5] 8bec mov ebp,esp
[000019c6][00112ad1][00112ad5] 8b4508 mov eax,[ebp+08]
[000019c9][00112acd][000019c3] 50 push eax // push E
[000019ca][00112acd][000019c3] 8b4d08 mov ecx,[ebp+08]
[000019cd][00112ac9][000019c3] 51 push ecx // push E
[000019ce][00112ac5][000019d3] e8b0f9ffff call 00001383 // call H

H: Infinitely Recursive Simulation Detected Simulation Stopped

[000019f5][00102a39][00000000] 83c408 add esp,+08
[000019f8][00102a39][00000000] 33c0 xor eax,eax
[000019fa][00102a3d][00000018] 5d pop ebp
[000019fb][00102a41][00000000] c3 ret
Number of Instructions Executed(865) == 13 Pages

[Richard Damon]

"PROGRAM E"

Or that is doesn't correct simulate an instruction that it does.

You simulation doesn't correct simulate the CALL 00001383 instruction.

H has no sound logic to make its claim of infinite recursion.

a call 00001383 when CORRECTLY simulated (which H doesn't do) will show
that it will eventually result in a return to 000019D3 with a 0 in the
eax register, and E will then return.

This has been pointed out before, you have refused to show an actual
proof or even someone else claiming this "criteria" that you are using
so it just shows that you are lying in making an ignorant incorrect
claim of behaior.

By repeatedly doing this you are showing that you are ignorant of how
logic and proof actually work.

You are just PROVING your stupidity and ignorance of the material.

Sorry, you have just wasted the LAST 18 years of your life and destroyed
any reputation you might have had. You are going to be remembered as the
ignorant liar.

[olcott]

(a) simulating halt decider H correctly simulates its input D until H

correctly determines that its simulated D would never stop running
unless aborted

H correctly determines that the above premise is true at the machine
address [000019ce] of E. Everyone having sufficient technical
understanding can see that the above premise is true at this same
machine address. You can either agree or be incorrect.

(b) then H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.

NO ONE HERE UNDERSTANDS THIS

When (a) is true and (b) is a necessary consequence of (a) then (b) is
true even if everyone and everything in the universe disagrees.

[Richard Damon]

No, it did NOT "correct determine that it simulated D would never stop
running unless aborted".

It has determined that D would never stop running unless the H it is
calling aborts its simulation, which it will if this H does. Thus H has
NOT proved that it actually needed to abort the simulation here, even
though it does.

It is ok for the D to depend on the H that it is calling to abort its
simulation, even if that is a simulation of something that represents
itself, that still makes it halting.


It doesn't matter that a DIFFERENT input based on a DIFFERENT H that
doesn't abort would be non-halting, becuase that isn't the input it was
given.

Your looking at the behavior of that other input makes you, what did you
call it, a "despicable liar" I think?

>
> H correctly determines that the above premise is true at the machine
> address [000019ce] of E. Everyone having sufficient technical
> understanding can see that the above premise is true at this same
> machine address. You can either agree or be incorrect.

Nope, it made the logical error I just pointed out.

>
> (b) then H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
>

Nope, since it didn't actually prove what it needed.

> NO ONE HERE UNDERSTANDS THIS
> When (a) is true and (b) is a necessary consequence of (a) then (b) is
> true even if everyone and everything in the universe disagrees.
>
>

Except that (a) isn't true because H used unsound logic and a wrong
definiton of what it was trying to do.

YOU FAIL.

[olcott]

Everyone having sufficient expertise in the C programming language can
see that (ignoring stack overflow) E correctly simulated by H would
never stop running unless aborted.

That you disagree only proves that you do not have sufficient expertise
in the C programming language.

[Richard Damon]

On 11/19/22 11:44 AM, olcott wrote:

> void E(void (*x)())
> {
>   H(x, x);
> }
>
> int main()
> {
>   H(E,E);
> }
>
> Everyone having sufficient expertise in the C programming language can
> see that (ignoring stack overflow) E correctly simulated by H would
> never stop running unless aborted.
>
> That you disagree only proves that you do not have sufficient expertise
> in the C programming language.
>

Nope, since your H is defined to return 0 when it sees E calling H(E,E),
the correct simulation of the input, (which H doesn't do) is

1: call E(E)
2: calls H(E,E)
3: 2: simulates call E(E)
4: 2: simulates call H(E,E) which triggers abort of simulation 2:
5: call @2 returns 0
6: E returns and thus halts.


The fact that H stopped its simulation at 2 just shows that it didn't
simulate long enough to see the answer, because it was incorrectly
programmed.

H needs to use the CORRECT definition of H when it sees the call to H,
which it doesn't (and in fact it CAN'T and return an answer in finite time).

The is NO infinite simulation implied by your H, even if we assume that
THIS instance doesn't abort its simulation.

You aren't allowed to work with implications of other instances of H
behaving differently then they have been defined, as we are being asked
what THIS input does.

YOU are the one that doesn't understand what you are talking about.

Who knows, maybe Flibble is right about your past, if you can't keep
these things straight and are not honest about things that everyone can
see, why should be trust your claims about other things.

I liar can't defend himself by asking people to trust his words, he has
already destroyed that trust.

[olcott]

On 11/19/2022 11:08 AM, Richard Damon wrote:
> On 11/19/22 11:44 AM, olcott wrote:
>
>> void E(void (*x)())
>> {
>>    H(x, x);
>> }
>>
>> int main()
>> {
>>    H(E,E);
>> }
>>
>> Everyone having sufficient expertise in the C programming language can
>> see that (ignoring stack overflow) E correctly simulated by H would
>> never stop running unless aborted.
>>
>> That you disagree only proves that you do not have sufficient
>> expertise in the C programming language.
>>
>
> Nope, since your H is defined to return 0 when it sees E calling H(E,E),
> the correct simulation of the input, (which H doesn't do) is
>

*That this is over your head is no rebuttal what-so-ever*
H correctly determines that for every H/E pair of the infinite set of
H/E pairs where E is correctly simulated by H, E never stops running
unless aborted.

[Richard Damon]

On 11/19/22 12:18 PM, olcott wrote:
> On 11/19/2022 11:08 AM, Richard Damon wrote:
>> On 11/19/22 11:44 AM, olcott wrote:
>>
>>> void E(void (*x)())
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int main()
>>> {
>>>    H(E,E);
>>> }
>>>
>>> Everyone having sufficient expertise in the C programming language
>>> can see that (ignoring stack overflow) E correctly simulated by H
>>> would never stop running unless aborted.
>>>
>>> That you disagree only proves that you do not have sufficient
>>> expertise in the C programming language.
>>>
>>
>> Nope, since your H is defined to return 0 when it sees E calling
>> H(E,E), the correct simulation of the input, (which H doesn't do) is
>>
> *That this is over your head is no rebuttal what-so-ever*
> H correctly determines that for every H/E pair of the infinite set of
> H/E pairs where E is correctly simulated by H, E never stops running
> unless aborted.
>

Repeating incorrect statements doesn't make them true.

Ignorance is its own punishment.

YOU FAIL.

[Mikko]

On 2022-11-18 16:29:03 +0000, olcott said:

> On 11/18/2022 10:25 AM, Mikko wrote:
>> On 2022-11-18 15:24:25 +0000, olcott said:
>>
>>> On 11/18/2022 5:19 AM, Mikko wrote:
>>>> On 2022-11-17 17:37:16 +0000, olcott said:
>>>>
>>>>>> On 2022-11-17 06:40:23 +0000, olcott said:
>>>>>>
>>>>>>> (a) A halt decider must report on the actual behavior specified by its input.
>>>>
>>>>> (a) Specifically excludes the behavior of non-inputs when these
>>>>> non-inputs have behavior that differs from the behavior of D correctly
>>>>> simulated by H. This only happens with pathological inputs.
>>>>
>>>> If a "non-input" is used for any purpose it is no longer a "non-input"
>>>> but an actual input. Therefore (a) does not say anything.
>>>>
>>>> Mikko
>>>>
>>>
>>> Where do you get this crazy shit?
>>
>> From the meaning of the word "input" as that word is used when
>> discussing computations and related stuff; and from the common
>> meaning of the prefix "non-".
>>
>> Mikko
>>
>
> When I say input to a function I mean its arguments.

The word "input" is wrong for that purpose. The meaning of "input" is
more general. To mean 'arguments' the correct word is 'arguments' or,
if that is not clear enough, 'all arguments'. Functions can have other
inputs in addition to or instead of arguments. Functions, including
deciders, are allowed to use any input they can use except those
particular functions for which otherwise is specified.

Mikko

[Mikko]

They don't. They are not a proof and not contained in a proof. They are
a only a short fragment of a (real or simulated) program execution.

Mikko

[Mikko]

No, it doesn't. The definition of "UTM" specifies the meaning of the
abbreviation "UTM". It does not specify anything else.

Mikko

[olcott]

"Input" is the conventional term used by Sipser for computable functions.

A function f: Σ* → Σ* is a computable function if some Turing
machine M, on every input w, halts with just f(w) on the tape.

--
Copyright 2022 Olcott "Talent hits a target no one else can hit; Genius

[olcott]

It is clear to everyone knowing the x86 language that the above
execution trace proves that (ignoring stack overflow) D correctly
simulated by H would remain in recursive simulation until aborted.

--
Copyright 2022 Olcott "Talent hits a target no one else can hit; Genius

[olcott]

I shortened my proof to these words
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly

report that D specifies a non-halting sequence of configurations.

[Richard Damon]

And you have to show that your H HAS correctly determined that case.

Since D(D) will Halt when run, and thus halt when correctly simulated
per the definition of a UTM, it must halt when (if it is possible)
correctly simulated by H.

The problem is that for D, H can NEVER "Correctly Simulate" the input,
since it WILL abort it (since H is DEFINED to return an answer for all
inputs).

[Richard Damon]

Nope, because the ACTUAL correct x86 simulation of the input would
continue from that point into H, see it produce a simulation like above,
and then this simulated H will abort its simulated simulation and return
to the simulated D, which will then return (aka Halt).

If H generates any other results of simulation, it is just incorrect.

Remember, the input is fixed, and thus the H that D calls has its code
FIXED, and it WILL behave as I just described.

YOU are being the (to use your own words) despicable liar who is looking
at the behavior of a non-input (by changing the code of the H that D calls).

YOU FAIL.

[olcott]

On 10/17/2022 5:54 AM, Richard Damon wrote:
> On 10/17/22 1:11 AM, olcott wrote:
>> *Professor Sipser has agreed to these verbatim words* (and no more)

>> If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D would never stop running
>> unless aborted then H can abort its simulation of D and correctly
report
>> that D specifies a non-halting sequence of configurations.

*Ben trimmed the above context from his reply to you*

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> ...D(D) would not halt unless H stops the simulation.
> H /can/ correctly determine this ...

Anyone correctly understanding the ordinary software
engineering code analysis can verify that Ben and I
are correct. A failure to understand is no rebuttal at all.

[olcott]

On 11/20/2022 11:16 AM, Richard Damon wrote:

On 10/17/2022 5:54 AM, Richard Damon wrote:
> On 10/17/22 1:11 AM, olcott wrote:
>> *Professor Sipser has agreed to these verbatim words* (and no more)
>> If simulating halt decider H correctly simulates its input D until H
>> correctly determines that its simulated D would never stop running
>> unless aborted then H can abort its simulation of D and correctly report
>> that D specifies a non-halting sequence of configurations.

*Ben trimmed the above context from his reply to you*

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
> ...D(D) would not halt unless H stops the simulation.
> H /can/ correctly determine this ...

Anyone correctly understanding the ordinary software
engineering code analysis can verify that Ben and I
are correct. A failure to understand is no rebuttal at all.

[Richard Damon]

So, YOUR failure to understand the requirements is not a rebutal at all.

YOU claim H has given the right answer. For the answer TO be right, it
must come, by your logic, from a correct simulation.

But, the DEFINITION, of a "Correct Simulation", since you have invoked
UTMs in your discusion, is that the simulation must EXACT recreate the
behavior of the direct exectution of the machine the input represents.

Since D(D) Halts, the ONLY possible results of a correct simulation is
for it to halt, so your simulation that shows it doesn't is NOT CORRECT,
but definition.

The error seems to be in your simulation of the "CALL H" instruction,
but you don't seem to be smart enough to understand it.

You fail by your own rules.

Note, if you want to claim that "Software Engineering" is the discipline
you are working in, you will need to find the actual statement of a
Halting Problem in Software Engineering (instead of Computation Theory)
and find what the inplications of solving that DIFFERENT problem would be.

If it isn't the same problem as the one in Computation Theory, then
answering it just doesn't apply. If it is, then the definition from
Computation Theory apply, so your alternate definitions do not.

YOU FAIL.

[Richard Damon]

So previous answer given just a minute ago.

YOU fail to understand, so your rebutal isn't a febuttal at all per your
own rules.

YOU FAIL.

[olcott]

Between the Sipser approved criteria and Ben's agreement that H /can/
correctly determine that this criteria has been met then I am correct.
*Full disclosure: Ben does not agree that the criteria is correct*

[Richard Damon]

Nope.

H has NOT correctly determined that the correct simulation of its input
would never halt, it can't, because the direct exectution of the machine
represented by the input halts, so the correct simulaton will to, and
thus you can not correct determine that it doesn't.

You sort of have a problem when you ask about what something that never
happes does. This H NEVER does a correct simulation of this input, so
conditioning something on that happening means you can't establish it.

You are just proving you don't understand the basics of logic.

[Mikko]

That is not a proof. The first sentence of a proof must be a defintion,
axiom, postulate or hypthesis and the last sentence must be the conclusion
of the proof. Between them other sentences are usually needed.

Mikko

[Mikko]

It is not. The last traced instruction is a jump to an untraced
instruction. What happens next depends on the instructions that
are not traced, so cannot be inferred from the shown trace.

Mikko

[Mikko]

The use of the word "input" is not restricted to computable functions
and Turing machines.

Mikko

[Richard Damon]

I don't think he understands what Formal Logic is at all, but thinks
everything is just a general Philosophy where you use rhetorical
arguments to try to "prove" your statements. He does like throwing out
symbols like he knows what they mean, but I think he is just parroting them.

And, an important clarification, the starting
definitions/axioms/postulates etc must be from the ACCEPTED/established
set in the Formal System, or just previously proved by a proof in the
argument chain that is building up from established knowledge.

You can have the definition of a NEW term if you are creating a new concept.

[olcott]

It is proven that D specifies a non-halting sequence of configurations
on the basis of
(a) is proven true by CODE ANALYSIS shown below

(b) is a necessary consequence of (a)

(a) simulating halt decider H correctly simulates its input D until H

correctly determines that its simulated D would never stop running

unless aborted (*see code analysis below*)

(b) then H can abort its simulation of D and correctly

report that D specifies a non-halting sequence of configurations.

CODE ANALYSIS
-------------
void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

int main()
{
H(D,D);
}

_D()
[000019b3] 55 push ebp
[000019b4] 8bec mov ebp,esp
[000019b6] 51 push ecx
[000019b7] 8b4508 mov eax,[ebp+08]
[000019ba] 50 push eax
[000019bb] 8b4d08 mov ecx,[ebp+08]
[000019be] 51 push ecx
[000019bf] e8bff9ffff call 00001383
[000019c4] 83c408 add esp,+08
[000019c7] 8945fc mov [ebp-04],eax
[000019ca] 837dfc00 cmp dword [ebp-04],+00
[000019ce] 7402 jz 000019d2
[000019d0] ebfe jmp 000019d0
[000019d2] 8be5 mov esp,ebp
[000019d4] 5d pop ebp
[000019d5] c3 ret
Size in bytes:(0035) [000019d5]

_main()
[000019e3] 55 push ebp
[000019e4] 8bec mov ebp,esp

[000019e6] 68b3190000 push 000019b3 // push D
[000019eb] 68b3190000 push 000019b3 // push D
[000019f0] e88ef9ffff call 00001383 // call H

[000019f5] 83c408 add esp,+08
[000019f8] 33c0 xor eax,eax
[000019fa] 5d pop ebp
[000019fb] c3 ret
Size in bytes:(0025) [000019fb]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

[000019e3][00102a39][00000000] 55 push ebp // begin main

[000019e4][00102a39][00000000] 8bec mov ebp,esp

[000019e6][00102a35][000019b3] 68b3190000 push 000019b3 // push D
[000019eb][00102a31][000019b3] 68b3190000 push 000019b3 // push D
[000019f0][00102a2d][000019f5] e88ef9ffff call 00001383 // call H

When H correctly simulates D it finds that D remains stuck in recursive
simulation

H: Begin Simulation Execution Trace Stored at:112ae5
Address_of_H:1383
[000019b3][00112ad1][00112ad5] 55 push ebp // begin D
[000019b4][00112ad1][00112ad5] 8bec mov ebp,esp
[000019b6][00112acd][00102aa1] 51 push ecx
[000019b7][00112acd][00102aa1] 8b4508 mov eax,[ebp+08]
[000019ba][00112ac9][000019b3] 50 push eax // call D
[000019bb][00112ac9][000019b3] 8b4d08 mov ecx,[ebp+08]
[000019be][00112ac5][000019b3] 51 push ecx // push D
[000019bf][00112ac1][000019c4] e8bff9ffff call 00001383 // call H

H: Infinitely Recursive Simulation Detected Simulation Stopped

We can see that the first seven instructions of D simulated by H
precisely match the first seven instructions of the x86 source-code of
D. This conclusively proves that these instructions were simulated
correctly.

Anyone sufficiently technically competent in the x86 programming
language will agree that the above execution trace of D simulated by H
shows that D will never stop running unless H aborts its simulation of D.

H detects that D is calling itself with the exact same arguments that H
was called with and there are no conditional branch instructions from
the beginning of D to its call to H that can possibly escape the
repetition of this recursive simulation.

[000019f5][00102a39][00000000] 83c408 add esp,+08
[000019f8][00102a39][00000000] 33c0 xor eax,eax
[000019fa][00102a3d][00000018] 5d pop ebp

[000019fb][00102a41][00000000] c3 ret // end main
Number of Instructions Executed(972) == 15 Pages

[olcott]

None of the traced instructions are a jump to anywhere.
All jump instructions begin with a "j" "jmp" "je" "jge" et cetera.

[olcott]

For the C function proxy of a Turing machine the input is its arguments.

[Richard Damon]

or CALL which is a "Jump" instruction with extra actions (the saving of
a return address)

Or do you not think of a "Call" instruction as an instruction which
causes out of phyisical order instruction execution?

Maybe THAT is you problem.

[Richard Damon]

No, your CODE ANALYSIS is faulty as it uses the wrong analysi of a call
to H.

>
>
> (a) simulating halt decider H correctly simulates its input D until H
> correctly determines that its simulated D would never stop running
> unless aborted (*see code analysis below*)

Right, but your H fails to meet that requriement as the input to H WILL
stop running because the H called by D will eventaully return 0, so THIS
simulation does not NEED to be aborted, but will be because H makes an
incorrect deduction.

>
> (b) then H can abort its simulation of D and correctly
> report that D specifies a non-halting sequence of configurations.

Nope, since (a) wasn't trune, (b) does not follow.

Nope, incorrect deduction

>
> H: Begin Simulation   Execution Trace Stored at:112ae5
> Address_of_H:1383
> [000019b3][00112ad1][00112ad5] 55         push ebp       // begin D
> [000019b4][00112ad1][00112ad5] 8bec       mov ebp,esp
> [000019b6][00112acd][00102aa1] 51         push ecx
> [000019b7][00112acd][00102aa1] 8b4508     mov eax,[ebp+08]
> [000019ba][00112ac9][000019b3] 50         push eax       // call D
> [000019bb][00112ac9][000019b3] 8b4d08     mov ecx,[ebp+08]
> [000019be][00112ac5][000019b3] 51         push ecx       // push D
> [000019bf][00112ac1][000019c4] e8bff9ffff call 00001383  // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> We can see that the first seven instructions of D simulated by H
> precisely match the first seven instructions of the x86 source-code of
> D. This conclusively proves that these instructions were simulated
> correctly.
>
> Anyone sufficiently technically competent in the x86 programming
> language will agree that the above execution trace of D simulated by H
> shows that D will never stop running unless H aborts its simulation of D.

But since the H that D calls DOES abort its simulation, the D that is
simulating this H doesn't actually NEED to abort its simulation, but
does so because it as be so incorrectly programmed

You don't understand the meaning of the words you are using.

>
> H detects that D is calling itself with the exact same arguments that H
> was called with and there are no conditional branch instructions from
> the beginning of D to its call to H that can possibly escape the
> repetition of this recursive simulation.

Which is NOT a proven non-halting condition.

The condition you are thinking of includes the code of H that is in the
loop, or requires H to be something it isn't, an unconditional simulator.

>
> [000019f5][00102a39][00000000] 83c408     add esp,+08
> [000019f8][00102a39][00000000] 33c0       xor eax,eax
> [000019fa][00102a3d][00000018] 5d         pop ebp
> [000019fb][00102a41][00000000] c3         ret  // end main
> Number of Instructions Executed(972) == 15 Pages
>
>
>
>
> Copyright 2022 Olcott "Talent hits a target no one else can hit; Genius
> hits a target no one else can see." Arthur Schopenhauer
>

Genius can SHOW the others the target by hitting it.

insanity thinks there is a target that isn't there.

YOU FAIL.

[Mikko]

If you mean that a particular C function has no inputs other than its
arguments, say so. That is not a property of all C functions and does
not follow from the meaning of "input".

Mikko

[Mikko]

All variants of CALL and RET are jumps, too.

Mikko

[olcott]

Similar to yet not the same as.

[olcott]

Everything that I say assumes that one has read at least the first three
pages of this paper:

Simulating Halt Decider Applied to the Halting Theorem

https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem

[Richard Damon]

No, they all fall into the "class" of Jump Instructions. Yes, "Call"
instructions are a SUBCLASS of the Jump class, since they do the some
additional operations.

On some processors they are even call "Branch and Link" to make it clearer.

You obviously don't actually understand the x86 architecture.

Note, that in particular, the claim of your INCORRECT simulation still
holds, even if you have diverted things with your RED HERRING.

You are just proving your stupidity.

[Richard Damon]

Which just repeats all the errors that have been pointed out in this
Newsgroup.

Maybe you should put it somewhere where people can respond to its
incorrect claims, or are you afraid of that?

[Mikko]

Just like JE and JGE are similar yet not the same.

Mikko

[olcott]

Every JMP is not the same as a CALL AT ALL !!!

Edgar Dijkstra: Go To Statement Considered Harmful
https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

[Richard Damon]

Wrong Domain. That deals with High level structure of code. Not low
level processor operation.

You are just incredible limitations in your understanding of the field.