On 2022-06-19 18:09:44 +0000, olcott said:

> On 6/19/2022 12:35 PM, Mikko wrote:

>> On 2022-06-19 15:59:55 +0000, olcott said:

>>> It will halt whenever it reaches final state means
>>> if and only if it reaches its final state it halts.

>> Dosn't matter if you can't write a publishable proof.

> The code <is> the proof.

Hardly a proof that a respectable publisher would accept.

Mikko

On 6/19/22 11:14 PM, olcott wrote:
> On 6/19/2022 9:27 PM, André G. Isaak wrote:
>> On 2022-06-19 16:18, olcott wrote:
>>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>>>> On 2022-06-19 14:43, olcott wrote:
>>>>
>>>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>>>> project on a downloadable link.
>>>>
>>>> I see no link anywhere.
>>>>
>>>> André
>>>>
>>>
>>> Are you sure maybe you didn't look hard enough?
>>> Maybe there is an invisible link between "131K" and "zip"
>>
>> If you posted it somewhere, wouldn't it be easier to simply repost the
>> link rather than make snide comments?
>>
>> Or if you don't intend to post the link, then say so.
>>
>> André
>>
>
> I do not intend to post the link very soon.
> Because reviewers here have been so consistently disparaging of my work
> they will be last in line to be able to have access to this code.
>
> When I boiled my claims down to two easily verified facts of software
> engineering and everyone consistently still disagreed then I knew that
> none of my reviewers were both sufficiently technically competent and
> honest.

No, you haven't, because you can't actually verify them, just claim
them, because they aren't actually correct.

>
> It is a very easily verified fact that the correct and complete x86
> emulation of the input to H(P,P) by H would never reach the "ret"
> instruction of P. Only one reviewer out of 100 reviewers in a dozen
> different forums over the period of a year would acknowledge that.

ONLY if H actually does a correct and complete x86 emulation, which it
actually doesn't, not if it returns 0 for a non-halting input. So, the
statement is actually illogical.

>
> The x86 emulator code is immaculate because I was very cautious in my
> slight changes to keep it very clean. H is the one halt decider that has
> all of its code quite clean and finally a pure function of its inputs.
> The x86utm operating system code is very reliable yet quite messy.

Some how, from what you have shown in the past, I doubt the the code for
H is "clean". I say this based on what code you have published and how
bad the basic structure of the code has been.

>
> At this point I have provided enough evidence that reasonable people
> would conclude that all of my claims of having actual code have been
> sufficiently proven. I decided that posting this code as a Google Drive
> downloadable link to a complete Visual Studio project is the way to go.

>
> The solution is defined so that immediately after the build the halt
> decider can be directly run from inside Visual Studio. The halt decider
> file itself can be edited to run different halt deciders on a small
> library of sample inputs. Right out of the box H(P,P) is executed.
>

And none of this shows that H(P,P) returning 0 is the right answer for H
to give as a Halt Decider, we don't need code to see that, we can go by
definitions.

The DEFINITION of a Halt decider is that it is a computation (so always
gives the same answer for the same inputs) that answer whether a given
algorithm + input combination will halt in a finite number of steps or not.

Typically, the computation to be decided is provided as a representation
of the algorithm and a representation of the input to be given to that
algorithm.

The Halting Theorem states that no such finite algorithm exist that can
be a correct halting decider for all possible algorithm + input
combinations.

The proof, is to imagine that we create a algorithm and input that asks
the proposed Halt Decider what this algorithm will do with its input,
and then do the opposite.

Said algorithm is clearly possible to build, if the halt decider
algorithm exists, as the steps are clearly defined.

Since your P is the embodyment of this counter example algorithm, and
P(P) calls H(P,P), that means that H(P,P) must mean that H(P,P) is
defined to answer about what P(P) does.

You claim otherwise just shows that you just don't understand the proof,
and are just being a dumb parrot about your code pieces and not
understanding them. (One reason I doubt your code is "clean").

Since we can easily prove that P(P) will Halt if H(P,P) returns 0, we
can show that H(P,P) returning 0 is clearly the wrong answer for a P
built by the counter argument algorithm, which is what is claimed.

Thus, either you have lied that this test was actually built to the
specifications (perhaps because you actually don't understand what
specifications actually mean) or your H is just an incorrect algorithm.

On 6/20/2022 6:18 AM, Richard Damon wrote:
>
> On 6/19/22 11:14 PM, olcott wrote:
>> On 6/19/2022 9:27 PM, André G. Isaak wrote:
>>> On 2022-06-19 16:18, olcott wrote:
>>>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>>>>> On 2022-06-19 14:43, olcott wrote:
>>>>>
>>>>>> My whole system is now wrapped in 131K zip file as a Visual Studio
>>>>>> project on a downloadable link.
>>>>>
>>>>> I see no link anywhere.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Are you sure maybe you didn't look hard enough?
>>>> Maybe there is an invisible link between "131K" and "zip"
>>>
>>> If you posted it somewhere, wouldn't it be easier to simply repost
>>> the link rather than make snide comments?
>>>
>>> Or if you don't intend to post the link, then say so.
>>>
>>> André
>>>
>>
>> I do not intend to post the link very soon.
>> Because reviewers here have been so consistently disparaging of my
>> work they will be last in line to be able to have access to this code.
>>
>> When I boiled my claims down to two easily verified facts of software
>> engineering and everyone consistently still disagreed then I knew that
>> none of my reviewers were both sufficiently technically competent and
>> honest.
>
> No, you haven't, because you can't actually verify them, just claim
> them, because they aren't actually correct.
>
>>
>> It is a very easily verified fact that the correct and complete x86
>> emulation of the input to H(P,P) by H would never reach the "ret"
>> instruction of P. Only one reviewer out of 100 reviewers in a dozen
>> different forums over the period of a year would acknowledge that.
>
> ONLY if H actually does a correct and complete x86 emulation,
This is the part where you prove that you do not have sufficient
technical competence in software engineering.

H correctly detects in a finite number of steps that its complete and
correct x86 emulation of its input would never reach the "ret"
instruction of P.

H knows its own machine address and on this basis:
(a) H recognizes that P is calling H with the same arguments that H was
called with.
(b) There are no instructions in P that could possibly escape this
infinitely recursive emulation.
(c) H aborts its emulation of P before its call to H is invoked.

The proof that I am correct is that no counter-example can possibly exist.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Mon, 20 Jun 2022 09:07:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/20/2022 6:18 AM, Richard Damon wrote:
> >
> > On 6/19/22 11:14 PM, olcott wrote:
> >> On 6/19/2022 9:27 PM, André G. Isaak wrote:
> >>> On 2022-06-19 16:18, olcott wrote:
> >>>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
> >>>>> On 2022-06-19 14:43, olcott wrote:
> >>>>>
> >>>>>> My whole system is now wrapped in 131K zip file as a Visual
> >>>>>> Studio project on a downloadable link.
> >>>>>
> >>>>> I see no link anywhere.
> >>>>>
> >>>>> André
> >>>>>
> >>>>
> >>>> Are you sure maybe you didn't look hard enough?
> >>>> Maybe there is an invisible link between "131K" and "zip"
> >>>
> >>> If you posted it somewhere, wouldn't it be easier to simply
> >>> repost the link rather than make snide comments?
> >>>
> >>> Or if you don't intend to post the link, then say so.
> >>>
> >>> André
> >>>
> >>
> >> I do not intend to post the link very soon.
> >> Because reviewers here have been so consistently disparaging of my
> >> work they will be last in line to be able to have access to this
> >> code.
> >>
> >> When I boiled my claims down to two easily verified facts of
> >> software engineering and everyone consistently still disagreed
> >> then I knew that none of my reviewers were both sufficiently
> >> technically competent and honest.
> >
> > No, you haven't, because you can't actually verify them, just claim
> > them, because they aren't actually correct.
> >
> >>
> >> It is a very easily verified fact that the correct and complete
> >> x86 emulation of the input to H(P,P) by H would never reach the
> >> "ret" instruction of P. Only one reviewer out of 100 reviewers in
> >> a dozen different forums over the period of a year would
> >> acknowledge that.
> >
> > ONLY if H actually does a correct and complete x86 emulation,
> This is the part where you prove that you do not have sufficient
> technical competence in software engineering.
>
> H correctly detects in a finite number of steps that its complete and
> correct x86 emulation of its input would never reach the "ret"
> instruction of P.
>
> H knows its own machine address and on this basis:
> (a) H recognizes that P is calling H with the same arguments that H
> was called with.
> (b) There are no instructions in P that could possibly escape this
> infinitely recursive emulation.
> (c) H aborts its emulation of P before its call to H is invoked.
>
> The proof that I am correct is that no counter-example can possibly
> exist.
void Px(u32 x)
{ H(x, x);
return;
}

int main()
{ Output("Input_Halts = ", H((u32)Px, (u32)Px));
}

....[000013e8][00102357][00000000] 83c408 add esp,+08
....[000013eb][00102353][00000000] 50 push eax
....[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
....[000013f6][00102357][00000000] 83c408 add esp,+08
....[000013f9][00102357][00000000] 33c0 xor eax,eax
....[000013fb][0010235b][00100000] 5d pop ebp
....[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)

It gets the answer wrong, i.e. input has not been decided correctly.
QED.

/Flibble

On Mon, 20 Jun 2022 11:48:47 +0300
Mikko <mikko.levanto@iki.fi> wrote:

> On 2022-06-19 18:09:44 +0000, olcott said:
>
> > On 6/19/2022 12:35 PM, Mikko wrote:
>
> >> On 2022-06-19 15:59:55 +0000, olcott said:
>
> >>> It will halt whenever it reaches final state means
> >>> if and only if it reaches its final state it halts.
>
> >> Dosn't matter if you can't write a publishable proof.
>
> > The code <is> the proof.
>
> Hardly a proof that a respectable publisher would accept.

A proof with a fundamental error is no proof at all:

On Mon, 20 Jun 2022 11:48:47 +0300
Mikko <mikko.levanto@iki.fi> wrote:

> On 2022-06-19 18:09:44 +0000, olcott said:
>
> > On 6/19/2022 12:35 PM, Mikko wrote:
>
> >> On 2022-06-19 15:59:55 +0000, olcott said:
>
> >>> It will halt whenever it reaches final state means
> >>> if and only if it reaches its final state it halts.
>
> >> Dosn't matter if you can't write a publishable proof.
>
> > The code <is> the proof.
>
> Hardly a proof that a respectable publisher would accept.

A proof with a fundamental error is no proof at all:

void Px(u32 x)
{ H(x, x);
return;
}

int main()
{ Output("Input_Halts = ", H((u32)Px, (u32)Px));
}

....[000013e8][00102357][00000000] 83c408 add esp,+08
....[000013eb][00102353][00000000] 50 push eax
....[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
....[000013f6][00102357][00000000] 83c408 add esp,+08
....[000013f9][00102357][00000000] 33c0 xor eax,eax
....[000013fb][0010235b][00100000] 5d pop ebp
....[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)

It gets the answer wrong, i.e. input has not been decided correctly.
QED.

/Flibble

On 6/20/22 10:07 AM, olcott wrote:
> On 6/20/2022 6:18 AM, Richard Damon wrote:
>>
>> On 6/19/22 11:14 PM, olcott wrote:
>>> On 6/19/2022 9:27 PM, André G. Isaak wrote:
>>>> On 2022-06-19 16:18, olcott wrote:
>>>>> On 6/19/2022 5:02 PM, André G. Isaak wrote:
>>>>>> On 2022-06-19 14:43, olcott wrote:
>>>>>>
>>>>>>> My whole system is now wrapped in 131K zip file as a Visual
>>>>>>> Studio project on a downloadable link.
>>>>>>
>>>>>> I see no link anywhere.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Are you sure maybe you didn't look hard enough?
>>>>> Maybe there is an invisible link between "131K" and "zip"
>>>>
>>>> If you posted it somewhere, wouldn't it be easier to simply repost
>>>> the link rather than make snide comments?
>>>>
>>>> Or if you don't intend to post the link, then say so.
>>>>
>>>> André
>>>>
>>>
>>> I do not intend to post the link very soon.
>>> Because reviewers here have been so consistently disparaging of my
>>> work they will be last in line to be able to have access to this code.
>>>
>>> When I boiled my claims down to two easily verified facts of software
>>> engineering and everyone consistently still disagreed then I knew
>>> that none of my reviewers were both sufficiently technically
>>> competent and honest.
>>
>> No, you haven't, because you can't actually verify them, just claim
>> them, because they aren't actually correct.
>>
>>>
>>> It is a very easily verified fact that the correct and complete x86
>>> emulation of the input to H(P,P) by H would never reach the "ret"
>>> instruction of P. Only one reviewer out of 100 reviewers in a dozen
>>> different forums over the period of a year would acknowledge that.
>>
>> ONLY if H actually does a correct and complete x86 emulation,
> This is the part where you prove that you do not have sufficient
> technical competence in software engineering.
>
> H correctly detects in a finite number of steps that its complete and
> correct x86 emulation of its input would never reach the "ret"
> instruction of P.

How can it correct detect something that isn't true.

SInce you have stipulated that H(P,P) "Correctly" returns 0, and it is
proven that P(P) will halt when H(P,P) returns 0, it is proven that
H(P,P) returning 0 is not correct, because the input is NOT a
non-halting input.

>
> H knows its own machine address and on this basis:
> (a) H recognizes that P is calling H with the same arguments that H was
> called with.
> (b) There are no instructions in P that could possibly escape this
> infinitely recursive emulation.

FALSE Criteria, pleae provide your sourc for this "rule"

FALSE Premise -> UNSOUND LOGIC.

> (c) H aborts its emulation of P before its call to H is invoked.
>
> The proof that I am correct is that no counter-example can possibly exist.
>

LIE. P(P) is. Since P(P) Halts when H(P,P) returns 0.

If H(P,P) isn't refering to the compuation P(P), then you have just been
lying that P was built per Linz requirements.

Also, lack of counter example is not proof of truth, and that just shows
you are just a lying hypocrite, as YOU are the one that says that all
Truth needs to be Provable.

That fact that you can't live with youtr own rules shows that you dont
understand what Truth actually is.