On 7/24/2022 6:11 PM, Paul N wrote:
> On Monday, July 25, 2022 at 12:03:13 AM UTC+1, olcott wrote:
>> On 7/24/2022 5:55 PM, Paul N wrote:
>>> On Sunday, July 24, 2022 at 9:11:38 PM UTC+1, olcott wrote:
>>>> We have to do this at the C level.
>>>> void P(ptr x)
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>> (a) H(P,P) simulates its input
>>>> (b) P calls H(P,P) to simulate itself *again*
>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>> (d) P calls H(P,P) to simulate itself *again*
>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>
>>>> *Can you see the repeating pattern* ?
>>>
>>> But that's not what H does. You've told us numerous times that H spots the repeating and aborts the simulation, reporting that P does not halt.
>> You are the only one that has ever acknowledged that there is any
>> repeating pattern. H aborts its simulation BECAUSE it spots the
>> repeating pattern that would never stop unless H aborts its simulation.
>>>
>>> It's incorrect to say "H(P,P) would simulate its input" if H does not simulate its input. H would not simulate its input all these many times.
>>>
>>> You're attempting to say what would happen if H did not spot the recursion, while using an H which does spot the recursion. IE you are considering the wrong H.
>
> I stick by this. If you change H to allow it to abort when it spots a repeating pattern, you must reflect this when considering what P actually does.

When P stops running because it has been aborted this does not count as
halting otherwise this infinite loop halts.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

Halting is defined are reaching the final state at machine address 1108.

Because the correctly simulated input to H(P,P) never stops running
unless H aborts its simulation we know the P never halts.

Every input that never stops running unless is simulation is aborted is
correctly determined to be non-halting.

--
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 7/24/22 7:21 PM, olcott wrote:
> On 7/24/2022 6:11 PM, Paul N wrote:
>> On Monday, July 25, 2022 at 12:03:13 AM UTC+1, olcott wrote:
>>> On 7/24/2022 5:55 PM, Paul N wrote:
>>>> On Sunday, July 24, 2022 at 9:11:38 PM UTC+1, olcott wrote:
>>>>> We have to do this at the C level.
>>>>> void P(ptr x)
>>>>> {
>>>>> int Halt_Status = H(x, x);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>> (a) H(P,P) simulates its input
>>>>> (b) P calls H(P,P) to simulate itself *again*
>>>>> (c) H(P,P) would simulate its input if it does what P asks
>>>>> (d) P calls H(P,P) to simulate itself *again*
>>>>> (e) H(P,P) would simulate its input if it does what P asks
>>>>> (f) P calls H(P,P) to simulate itself *again* ...
>>>>>
>>>>> *Can you see the repeating pattern* ?
>>>>
>>>> But that's not what H does. You've told us numerous times that H
>>>> spots the repeating and aborts the simulation, reporting that P does
>>>> not halt.
>>> You are the only one that has ever acknowledged that there is any
>>> repeating pattern. H aborts its simulation BECAUSE it spots the
>>> repeating pattern that would never stop unless H aborts its simulation.
>>>>
>>>> It's incorrect to say "H(P,P) would simulate its input" if H does
>>>> not simulate its input. H would not simulate its input all these
>>>> many times.
>>>>
>>>> You're attempting to say what would happen if H did not spot the
>>>> recursion, while using an H which does spot the recursion. IE you
>>>> are considering the wrong H.
>>
>> I stick by this. If you change H to allow it to abort when it spots a
>> repeating pattern, you must reflect this when considering what P
>> actually does.
>
> When P stops running because it has been aborted this does not count as
> halting otherwise this infinite loop halts.

No, but the P(P) that calls H and halts by getting to the return
instruction does.

REMEMBER, Halting is DEFINED by the behavior of the MACHINE, not a
simulation, and especially not by a partial simulation.

>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
> Halting is defined are reaching the final state at machine address 1108.
>
> Because the correctly simulated input to H(P,P) never stops running
> unless H aborts its simulation we know the P never halts.

No, we know that P never halts because we can show that P can never get
to a final state.

That is independent of if H needs to abort its simulation or not.

>
> Every input that never stops running unless is simulation is aborted is
> correctly determined to be non-halting.
>

Only under the proper interpretation of those words.

If H can abort its simulation and show that the same input given to an
unconditional simulator would never halt (aka a UTM equivalent), then YES.

If H can only show that if you CHANGE H and ALL REFERENCES TO IT, then
NO, not if the input gets changed by doing that.

Remember, P includes H as part of it, so changing H changes the input P,
by definition, thus any argument based on changing THAT H to something
other that what it was, is invalid.

On 7/24/22 4:40 PM, Skep Dick wrote:
> On Sunday, 24 July 2022 at 22:24:00 UTC+2, richar...@gmail.com wrote:
>> Except he doesn't WANT the right answer, because he knows it and it is
>> well established but interferes with his own ideas of some alternate
>> idea of Truth.
> The "right answer" is always theory-dependent.
>
> Different definitions/theories would produce different conclusions/answers etc.
>
> What he's simply demonstrating (which is trivial and boring) is that particular instances of the halting problem are solvable, but everyone knows this.
> Which is why we have oracle machines. You (the human) can identify an infinite loop, but a Turing machine can't.
>
>> Maybe he hopes someone else can disprove the well established Theorem
> Theorems only hold if you accept their axioms/premises.
>
>> Somone MIGHT have been willing to help him with his alternate logic and
>> see what it might amount to but he has nuked those bridges.
> Yeah, but he doesn't want you to give him the right answer.
>
> He wants to debug his own misunderstanding, but he can't grok the problem.
>
> Parroting the textbook answer doesn't amount to understanding.

It seems he is more throwing buzz words at the wall to see if any stick
well enough to hide his deceptions.

I notice key points that he just refuses to talk about, because they so
glaringly point out his errors.

Of course, I presume everyone one else with half a brain sees his
obvious dodging of the questions, and his labeling them as "off topic"
so all he is doing is proving to the world is duplicity.

On 24/07/2022 20:29, Ben Bacarisse wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>
>> On 23/07/2022 22:52, Ben Bacarisse wrote:
>
>>> The fact that we don't have a clear algorithm is to be expected.
>>
>> Isn't the algorithm clear now?
>
> We all know what the algorithm is, so in that sense "it's clear". What
> I meant was that I was not expecting the code to express the algorithm
> clearly.
>
>>> ... Every crank learns fast that clarity is
>>> their number one enemy.
>>
>> PO's clarified what it contains in another response, and it looks like
>> we could build it all.
>
> Yes, over the years he's given the game away. That's why new forms of
> obfuscation come along to keep people talking. And it works.
>
> He was once clear about having a TM exactly and precisely as in Linz
> that gets the H(H^, H^) case right. But that was a huge mistake (made,
> I am sure, at a time of great distress), so it was followed by months of
> frantic backpedalling, ending up here with no TM, and some code, nothing
> like Linz, that gives the wrong answer.
>
>> (Well, if you have a Windows environment. For me it could be straight
>> forward as I also have Visual Studio 2017 so it might all just work.
>
> I would probably have given that a go too, but I have no Windows system
> (other than a rather slow VM for testing IE), and no VS compiler.
> That's too much pain to go though for this.
>

I would expect it might compile outside windows, as the starting point (libx86emu) was originally
Linux based. In any case the number of code files is TINY, so you would be capable of sorting out
any compile errors I'd think. Many of the files in the zip are not needed, e.g. the vs project
files, makefiles, version/license files, bat files and the like.

To make it as simple as possible, you just need to do two compile/link commands in a shell window:

> [compilelink] x86utm.cpp api.c decode.c mem.c ops.c ops2.c prim_ops.c

> [compile] halt7.c

Those 8 files plus the headers in /include are all that's needed.

The compilelink command needs options to build a console (non-gui) program, with your preferred
debug mode settings so it behaves well under debugging etc. I targeted the code as 32-bit exe,
because PO said he did that. (Perhaps libx86emu source requires 32-bit build, not sure...).

The halt7.c just needs to be compiled to a COFF format obj file. It must target 32-bit x86 code
because that's what libx86emu works with. (Also, probably generate an assembly-style listing, and
minimal optimisation so the object code is simple.) Hmmm, halt7.c contains a few _asm directives -
hopefully your compiler can handle those?

Finally, x86utm halt7.coff runs everything (output goes to stdout). Probably step this in a
debugger if you're worried PO might be doing something malicious, but I haven't seen anything like
that...

Biggest worries would be :
a) whether your compiler's COFF file halt7.o works with PO's COFF-reading code.
If it doesn't you can test with the halt7.obj file in the zip, but then you won't
be able to play much with H, P etc.
b) whether any assumptions behind logic of _asm directives are correct in your environment
c) or in fact any other assumptions PO has made about how the compiled x86 code is
layed out??? or exactly what instructions sequences the compiler generates for calls,
proglog/epilog code etc.
(calling conventions?? C supports several for 32-bit code. Just have to suck it
and see!)
d) hmm, line endings in all the files? (just thought of that, but I'm sure you're used to
sorting that)

Mike.

On 7/24/2022 8:04 PM, Mike Terry wrote:
> On 24/07/2022 20:29, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 23/07/2022 22:52, Ben Bacarisse wrote:
>>
>>>> The fact that we don't have a clear algorithm is to be expected.
>>>
>>> Isn't the algorithm clear now?
>>
>> We all know what the algorithm is, so in that sense "it's clear".  What
>> I meant was that I was not expecting the code to express the algorithm
>> clearly.
>>
>>>> ...  Every crank learns fast that clarity is
>>>> their number one enemy.
>>>
>>> PO's clarified what it contains in another response, and it looks like
>>> we could build it all.
>>
>> Yes, over the years he's given the game away.  That's why new forms of
>> obfuscation come along to keep people talking.  And it works.
>>
>> He was once clear about having a TM exactly and precisely as in Linz
>> that gets the H(H^, H^) case right.  But that was a huge mistake (made,
>> I am sure, at a time of great distress), so it was followed by months of
>> frantic backpedalling, ending up here with no TM, and some code, nothing
>> like Linz, that gives the wrong answer.
>>
>>> (Well, if you have a Windows environment.  For me it could be straight
>>> forward as I also have Visual Studio 2017 so it might all just work.
>>
>> I would probably have given that a go too, but I have no Windows system
>> (other than a rather slow VM for testing IE), and no VS compiler.
>> That's too much pain to go though for this.
>>
>
> I would expect it might compile outside windows, as the starting point
> (libx86emu) was originally Linux based.  In any case the number of code
> files is TINY, so you would be capable of sorting out any compile errors
> I'd think.  Many of the files in the zip are not needed, e.g. the vs
> project files, makefiles, version/license files, bat files and the like.
>
> To make it as simple as possible, you just need to do two compile/link
> commands in a shell window:
>
>   > [compilelink] x86utm.cpp api.c decode.c mem.c ops.c ops2.c prim_ops.c
>
>   > [compile] halt7.c
>
> Those 8 files plus the headers in /include are all that's needed.
>
> The compilelink command needs options to build a console (non-gui)
> program, with your preferred debug mode settings so it behaves well
> under debugging etc.  I targeted the code as 32-bit exe, because PO said
> he did that.  (Perhaps libx86emu source requires 32-bit build, not
> sure...).
>
> The halt7.c just needs to be compiled to a COFF format obj file.  It
> must target 32-bit x86 code because that's what libx86emu works with.
> (Also, probably generate an assembly-style listing, and minimal
> optimisation so the object code is simple.)   Hmmm, halt7.c contains a
> few _asm directives - hopefully your compiler can handle those?
>
> Finally, x86utm halt7.coff runs everything (output goes to stdout).
> Probably step this in a debugger if you're worried PO might be doing
> something malicious, but I haven't seen anything like that...
>
> Biggest worries would be :
> a) whether your compiler's COFF file halt7.o works with PO's
> COFF-reading code.
>    If it doesn't you can test with the halt7.obj file in the zip, but
> then you won't
>    be able to play much with H, P etc.
> b) whether any assumptions behind logic of _asm directives are correct
> in your environment
> c) or in fact any other assumptions PO has made about how the compiled
> x86 code is
>    layed out???  or exactly what instructions sequences the compiler
> generates for calls,
>    proglog/epilog code etc.
>    (calling conventions??  C supports several for 32-bit code.  Just
> have to suck it
>    and see!)
> d) hmm, line endings in all the files? (just thought of that, but I'm
> sure you're used to
>    sorting that)
>
> Mike.

Yes that is all correct.
Halt7.c must be compiled under Windows.
There is a utility that converts files to COFF object format.
I forgot how far that I got with that. I think that I installed it.

In your case the project file does everything including compiling
Halt7.c using the command line compiler.

I included __Run_7.bat that does everything from the command line, this
is always the way that I work with my system.

I will compile it under Ubuntu 16.04 very soon to make sure that it
still compiles. I had to adapt libx86emu very slightly to get it to
compile under Windows. I also enhanced it to provide an x86 source
listing of every function in the COFF object file. Those are the only
two changes that I made to the original libx86emu system.

I really appreciate that you are reviewing my work again.
I really only want closure even if this proves that I am wrong.

--
Copyright 2022 Pete Olcott

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