On 7/22/2022 5:41 PM, Ben Bacarisse wrote:
> om@iki.fi (Otto J. Makela) writes:
>
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> https://www.liarparadox.org/2022_07_22.zip
>>
>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>> small errors from decode.c, because of two variable loop declarations.
>>
>> decode.c: In function ‘x86emu_run’:
>> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
>> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
>> ^
>
> And so on...
>
> But this code a distraction because:
>
> (a) Every file that defines H will dump core as soon as any allocated
> storage is used. (Look at the definition of Allocate.)
>
> (b) (And I can't stress this enough...) *He has already told us that H
> gives the wrong answer*. There is no dispute about the fact that H(P,P)
> == false even though P(P) halts.
>

*Thanks for coming back here is your first review of my work*
[Re: A Possible "solution" to the Halting Problem]
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
On 10/17/2006 7:03 PM, Ben Bacarisse wrote:

Much longer than anyone else.

> The only reason to look at this junk code would be to work out what PO
> thinks is the justification for claiming the wrong answer is the right
> one. But there's no need to do that either has he has published the
> criterion by which H gets the wrong answer. Presumably, the complete
> code, when posted, will implement this incorrect criterion.
>

*What is your rebuttal to this* ?
If a simulating halt decider continues to correctly simulate its input
until it correctly matches a non-halting behavior pattern then this SHD
is necessarily correct when it aborts its simulation and reports
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/22/22 7:03 PM, olcott wrote:
> On 7/22/2022 5:41 PM, Ben Bacarisse wrote:
>> om@iki.fi (Otto J. Makela) writes:
>>
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> https://www.liarparadox.org/2022_07_22.zip
>>>
>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>> small errors from decode.c, because of two variable loop declarations.
>>>
>>> decode.c: In function ‘x86emu_run’:
>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
>>> allowed in C99 mode
>>>       for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text);
>>> N++)
>>>       ^
>>
>> And so on...
>>
>> But this code a distraction because:
>>
>> (a) Every file that defines H will dump core as soon as any allocated
>> storage is used.  (Look at the definition of Allocate.)
>>
>> (b) (And I can't stress this enough...) *He has already told us that H
>> gives the wrong answer*.  There is no dispute about the fact that H(P,P)
>> == false even though P(P) halts.
>>
>
> *Thanks for coming back here is your first review of my work*
> [Re: A Possible "solution" to the Halting Problem]
> > "Peter Olcott" <NoSpam@SeeScreen.com> writes:
> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
>
> Much longer than anyone else.
>
>> The only reason to look at this junk code would be to work out what PO
>> thinks is the justification for claiming the wrong answer is the right
>> one.  But there's no need to do that either has he has published the
>> criterion by which H gets the wrong answer.  Presumably, the complete
>> code, when posted, will implement this incorrect criterion.
>>
>
> *What is your rebuttal to this* ?
> If a simulating halt decider continues to correctly simulate its input
> until it correctly matches a non-halting behavior pattern then this SHD
> is necessarily correct when it aborts its simulation and reports
> non-halting.
>

You mean the fact that H never actually does determine that its
simulation matchs a finite correct non-halting pattern? Thus, if H
aborts it has failed to meet the conditions that allow it to CORRECTLY
return 0, and if it waits until it does prove it, it never answers?

The pattern you have programmed, that when P(P) calls H(P,P) is proved
incorrect by the fact that P(P) will halt when H(P,P) returns 0 to it.

On 22/07/2022 23:41, Ben Bacarisse wrote:
> om@iki.fi (Otto J. Makela) writes:
>
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> https://www.liarparadox.org/2022_07_22.zip
>>
>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>> small errors from decode.c, because of two variable loop declarations.
>>
>> decode.c: In function ‘x86emu_run’:
>> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
>> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
>> ^
>
> And so on...
>
> But this code a distraction because:
>
> (a) Every file that defines H will dump core as soon as any allocated
> storage is used. (Look at the definition of Allocate.)

You are looking at the definition in halt7.c:

u32* Allocate(u32 size) { return 0; }
?

That code isn't actually "executed" by x86utm - it's intercepted somehow and actioned somewhere
within x86utm. (Remember, halt7.c is only compiled (not linked) and then the coff file is loaded
and "executed" within PO's x86 simulator x86utm.exe.)

>
> (b) (And I can't stress this enough...) *He has already told us that H
> gives the wrong answer*. There is no dispute about the fact that H(P,P)
> == false even though P(P) halts.

Yes, there's no need to go further than this. If H(P,P) cheated somehow to give the right answer
for P(P) halting, there might be an incentive for someone to pin down the cheat details, but given
that H gives exactly the answer in line with the Linz (and similar) proofs, there's not really
anything more that /needs/ to be done here.

Of course, people might just be curious.

I'm not clear what his .zip file contains: is it the full source for x86utm, or just for the
halt7.c file (containing H() and P() implementations? [When I say source for x86utm, clearly that
depends on the open source project libx86emu, or whatever it's called, which isn't in the zip file...]

Mike.

On 7/22/22 10:21 PM, Mike Terry wrote:
> On 22/07/2022 23:41, Ben Bacarisse wrote:
>> om@iki.fi (Otto J. Makela) writes:
>>
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> https://www.liarparadox.org/2022_07_22.zip
>>>
>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>> small errors from decode.c, because of two variable loop declarations.
>>>
>>> decode.c: In function ‘x86emu_run’:
>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
>>> allowed in C99 mode
>>>       for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text);
>>> N++)
>>>       ^
>>
>> And so on...
>>
>> But this code a distraction because:
>>
>> (a) Every file that defines H will dump core as soon as any allocated
>> storage is used.  (Look at the definition of Allocate.)
>
> You are looking at the definition in halt7.c:
>
>     u32* Allocate(u32 size) { return 0; }
> ?
>
> That code isn't actually "executed" by x86utm - it's intercepted somehow
> and actioned somewhere within x86utm.  (Remember, halt7.c is only
> compiled (not linked) and then the coff file is loaded and "executed"
> within PO's x86 simulator x86utm.exe.)
>
>>
>> (b) (And I can't stress this enough...) *He has already told us that H
>> gives the wrong answer*.  There is no dispute about the fact that H(P,P)
>> == false even though P(P) halts.
>
> Yes, there's no need to go further than this.  If H(P,P) cheated somehow
> to give the right answer for P(P) halting, there might be an incentive
> for someone to pin down the cheat details, but given that H gives
> exactly the answer in line with the Linz (and similar) proofs, there's
> not really anything more that /needs/ to be done here.
>
> Of course, people might just be curious.
>
> I'm not clear what his .zip file contains:  is it the full source for
> x86utm, or just for the halt7.c file (containing H() and P()
> implementations?  [When I say source for x86utm, clearly that depends on
> the open source project libx86emu, or whatever it's called, which isn't
> in the zip file...]
>
> Mike.

There is a 72 kb x86utm.cpp file in there that I haven't had a chance to
look at, so my guess is that is the actual x86utm program. There is also
a precompilled and linked fie x86utm.exe

I think this gives us everything to actually run his program.

On 7/22/2022 9:21 PM, Mike Terry wrote:
> On 22/07/2022 23:41, Ben Bacarisse wrote:
>> om@iki.fi (Otto J. Makela) writes:
>>
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> https://www.liarparadox.org/2022_07_22.zip
>>>
>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>> small errors from decode.c, because of two variable loop declarations.
>>>
>>> decode.c: In function ‘x86emu_run’:
>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
>>> allowed in C99 mode
>>>       for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text);
>>> N++)
>>>       ^
>>
>> And so on...
>>
>> But this code a distraction because:
>>
>> (a) Every file that defines H will dump core as soon as any allocated
>> storage is used.  (Look at the definition of Allocate.)
>
> You are looking at the definition in halt7.c:
>
>     u32* Allocate(u32 size) { return 0; }
> ?
>
> That code isn't actually "executed" by x86utm - it's intercepted somehow
> and actioned somewhere within x86utm.  (Remember, halt7.c is only
> compiled (not linked) and then the coff file is loaded and "executed"
> within PO's x86 simulator x86utm.exe.)
>
>>
>> (b) (And I can't stress this enough...) *He has already told us that H
>> gives the wrong answer*.  There is no dispute about the fact that H(P,P)
>> == false even though P(P) halts.
>
> Yes, there's no need to go further than this.  If H(P,P) cheated somehow
> to give the right answer for P(P) halting, there might be an incentive
> for someone to pin down the cheat details, but given that H gives
> exactly the answer in line with the Linz (and similar) proofs, there's
> not really anything more that /needs/ to be done here.
>
> Of course, people might just be curious.
>
> I'm not clear what his .zip file contains:  is it the full source for
> x86utm, or just for the halt7.c file (containing H() and P()
> implementations?  [When I say source for x86utm, clearly that depends on
> the open source project libx86emu, or whatever it's called, which isn't
> in the zip file...]
>
> Mike.

*Halt Decider*
07/22/2022 07:05 AM 10,390 Halt7.c

*x86utm operating system*
07/22/2022 07:08 AM 72,499 x86utm.cpp
07/01/2022 03:40 PM 32,931 Read_COFF_Object.h

*x86 emulator source-code*
10/04/2020 07:44 PM 17,240 api.c
05/03/2021 02:33 PM 58,872 decode.c
06/28/2020 05:22 PM 20,495 mem.c
06/30/2020 12:06 AM 141,330 ops.c
06/27/2022 11:15 AM 63,704 ops2.c
06/30/2020 12:09 AM 73,787 prim_ops.c
01/28/2020 06:19 AM 5,542 decode.h
02/17/2020 08:56 PM 18,558 getopt.h
01/28/2020 06:19 AM 1,859 mem.h
01/28/2020 06:19 AM 1,954 ops.h
01/28/2020 06:19 AM 6,133 prim_ops.h
02/09/2021 10:40 PM 19,596 x86emu.h
10/04/2020 07:34 PM 4,996 x86emu_int.h

--
Copyright 2022 Pete Olcott

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

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

> On 22/07/2022 23:41, Ben Bacarisse wrote:
>> om@iki.fi (Otto J. Makela) writes:
>>
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> https://www.liarparadox.org/2022_07_22.zip
>>>
>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>> small errors from decode.c, because of two variable loop declarations.
>>>
>>> decode.c: In function ‘x86emu_run’:
>>> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
>>> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
>>> ^
>> And so on...
>> But this code a distraction because:
>> (a) Every file that defines H will dump core as soon as any allocated
>> storage is used. (Look at the definition of Allocate.)
>
> You are looking at the definition in halt7.c:
>
> u32* Allocate(u32 size) { return 0; }
> ?

Yes.

> That code isn't actually "executed" by x86utm - it's intercepted
> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
> only compiled (not linked) and then the coff file is loaded and
> "executed" within PO's x86 simulator x86utm.exe.)

The C source for H should be code that follows C's semantics. The only
C function called H calls a function that accesses that null pointer.
The fact that we don't have a clear algorithm is to be expected. We'll
never see the simple snippet of C-like code that expressed the algorithm
the PO claimed to have in Dec 2018 because that was a... er... an
alternative fact.

What we have here is a tar-pit for people to get sucked into to keep the
discussion of the wrong answer going. I'll give PO credit, though. I
had no idea he could admit to H giving the wrong answer and still have
people talking about it years later.

> I'm not clear what his .zip file contains...

And that's not an accident. Every crank learns fast that clarity is
their number one enemy.

--
Ben.

On Saturday, July 23, 2022 at 4:52:25 PM UTC-5, Ben Bacarisse wrote:
> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>
> > On 22/07/2022 23:41, Ben Bacarisse wrote:
> >> o...@iki.fi (Otto J. Makela) writes:
> >>
> >>> olcott <No...@NoWhere.com> wrote:
> >>>
> >>>> https://www.liarparadox.org/2022_07_22.zip
> >>>
> >>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> >>> small errors from decode.c, because of two variable loop declarations..
> >>>
> >>> decode.c: In function ‘x86emu_run’:
> >>> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
> >>> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
> >>> ^
> >> And so on...
> >> But this code a distraction because:
> >> (a) Every file that defines H will dump core as soon as any allocated
> >> storage is used. (Look at the definition of Allocate.)
> >
> > You are looking at the definition in halt7.c:
> >
> > u32* Allocate(u32 size) { return 0; }
> > ?
> Yes.
> > That code isn't actually "executed" by x86utm - it's intercepted
> > somehow and actioned somewhere within x86utm. (Remember, halt7.c is
> > only compiled (not linked) and then the coff file is loaded and
> > "executed" within PO's x86 simulator x86utm.exe.)
> The C source for H should be code that follows C's semantics. The only
> C function called H calls a function that accesses that null pointer.
> The fact that we don't have a clear algorithm is to be expected. We'll
> never see the simple snippet of C-like code that expressed the algorithm
> the PO claimed to have in Dec 2018 because that was a... er... an
> alternative fact.
>
> What we have here is a tar-pit for people to get sucked into to keep the
> discussion of the wrong answer going. I'll give PO credit, though. I
> had no idea he could admit to H giving the wrong answer and still have
> people talking about it years later.
>
> > I'm not clear what his .zip file contains...
>
> And that's not an accident. Every crank learns fast that clarity is
> their number one enemy.
>
> --
> Ben.

The "snippet" of C source code for H is on pages 6-10 of my paper.

*Halting problem proofs refuted on the basis of software engineering* ?
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering

*Halt Decider and P*
07/22/2022 07:05 AM 10,390 Halt7.c

*x86utm operating system*
07/22/2022 07:08 AM 72,499 x86utm.cpp
07/01/2022 03:40 PM 32,931 Read_COFF_Object.h

*x86 emulator source-code*
10/04/2020 07:44 PM 17,240 api.c
05/03/2021 02:33 PM 58,872 decode.c
06/28/2020 05:22 PM 20,495 mem.c
06/30/2020 12:06 AM 141,330 ops.c
06/27/2022 11:15 AM 63,704 ops2.c
06/30/2020 12:09 AM 73,787 prim_ops.c
01/28/2020 06:19 AM 5,542 decode.h
02/17/2020 08:56 PM 18,558 getopt.h
01/28/2020 06:19 AM 1,859 mem.h
01/28/2020 06:19 AM 1,954 ops.h
01/28/2020 06:19 AM 6,133 prim_ops.h
02/09/2021 10:40 PM 19,596 x86emu.h
10/04/2020 07:34 PM 4,996 x86emu_int.h

Compiles into x86utm.exe

On 23/07/2022 22:52, Ben Bacarisse wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>
>> On 22/07/2022 23:41, Ben Bacarisse wrote:
>>> om@iki.fi (Otto J. Makela) writes:
>>>
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> https://www.liarparadox.org/2022_07_22.zip
>>>>
>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>>> small errors from decode.c, because of two variable loop declarations.
>>>>
>>>> decode.c: In function ‘x86emu_run’:
>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
>>>> for (int N = 0; N < sizeof(emu->line_of_code.Disassembly_text); N++)
>>>> ^
>>> And so on...
>>> But this code a distraction because:
>>> (a) Every file that defines H will dump core as soon as any allocated
>>> storage is used. (Look at the definition of Allocate.)
>>
>> You are looking at the definition in halt7.c:
>>
>> u32* Allocate(u32 size) { return 0; }
>> ?
>
> Yes.
>
>> That code isn't actually "executed" by x86utm - it's intercepted
>> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
>> only compiled (not linked) and then the coff file is loaded and
>> "executed" within PO's x86 simulator x86utm.exe.)
>
> The C source for H should be code that follows C's semantics. The only
> C function called H calls a function that accesses that null pointer.

Well, it's up to PO to define the semantics for his chosen programming model, and he doesn't really
understand what that would mean, so there's nothing to be done about this.

In any case, within his model, there are some primatives not present in C language semantics, like
single stepping a simulation, allocating a block of memory, outputing message strings, whatever.
Those primatives are handled by his x86utm. He has to have a convention for how the C code is to
invoke one of those primatives, just like an OS has conventions on how its kernal routines should be
invoked from user code. PO has chosen to reserve some function names as primatives, and to invoke
the primative the code makes a regular call to a function with that name. (That's fairly normal.
x86utm loads the coff file and can identify points where those primative calls are being made.)
Then, to make his code compile he decided to actually include a real function in the user code with
that name!

So the strange choice perhaps was the inclusion of an actual dummy function in the user code. I
mean, he could just have declared a function prototype line for Alloc and left it at that - the code
would still compile ok. That's what I would have done probably, or maybe provided an actual Alloc
"library" stub routine to wrap whatever it takes to actually invoke the primative [maybe issue a
reserved x86 instruction, or an actual x86 gate-type instruction like a real OS might, which would
be intercepted by x86utm.]. But it's the least of all PO's sins!

> The fact that we don't have a clear algorithm is to be expected.

Isn't the algorithm clear now? It's just what he's been saying for ages. (Checking for calls to
H's own address from within simulated P with the same parameters blah blah - we have the code now,
and nothing has changed because the exact code was never the issue.)

Yeah, I suppose PO might at some point need to specify exactly what his primatives do, but it seems
we could work that out ourselves from the code if we really had to... [we don't :) ]

> We'll
> never see the simple snippet of C-like code that expressed the algorithm
> the PO claimed to have in Dec 2018 because that was a... er... an
> alternative fact.
>
> What we have here is a tar-pit for people to get sucked into to keep the
> discussion of the wrong answer going. I'll give PO credit, though. I
> had no idea he could admit to H giving the wrong answer and still have
> people talking about it years later.
>
>> I'm not clear what his .zip file contains...
>
> And that's not an accident. 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.
(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'll probably give it a try at some point, just because I
like playing with code, not because I need to learn where PO has gone wrong...)

I'm not sure if I would need to download a version of libx86emu - there are a handful of files in
the zip file that seem to be from libx86emu, but I would have thought that project would be Much
bigger! [Looking on github it seems at first glance the project is actually just the handful of
files in the zipfile! We'll see.]

Mike.

On 7/23/2022 6:22 PM, Mike Terry wrote:
> On 23/07/2022 22:52, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 22/07/2022 23:41, Ben Bacarisse wrote:
>>>> om@iki.fi (Otto J. Makela) writes:
>>>>
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> https://www.liarparadox.org/2022_07_22.zip
>>>>>
>>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>>>> small errors from decode.c, because of two variable loop declarations.
>>>>>
>>>>> decode.c: In function ‘x86emu_run’:
>>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
>>>>> allowed in C99 mode
>>>>>        for (int N = 0; N <
>>>>> sizeof(emu->line_of_code.Disassembly_text); N++)
>>>>>        ^
>>>> And so on...
>>>> But this code a distraction because:
>>>> (a) Every file that defines H will dump core as soon as any allocated
>>>> storage is used.  (Look at the definition of Allocate.)
>>>
>>> You are looking at the definition in halt7.c:
>>>
>>>      u32* Allocate(u32 size) { return 0; }
>>> ?
>>
>> Yes.
>>
>>> That code isn't actually "executed" by x86utm - it's intercepted
>>> somehow and actioned somewhere within x86utm.  (Remember, halt7.c is
>>> only compiled (not linked) and then the coff file is loaded and
>>> "executed" within PO's x86 simulator x86utm.exe.)
>>
>> The C source for H should be code that follows C's semantics.  The only
>> C function called H calls a function that accesses that null pointer.
>
> Well, it's up to PO to define the semantics for his chosen programming
> model, and he doesn't really understand what that would mean, so there's
> nothing to be done about this.
>
> In any case, within his model, there are some primatives not present in
> C language semantics, like single stepping a simulation, allocating a
> block of memory, outputing message strings, whatever. Those primatives
> are handled by his x86utm.  He has to have a convention for how the C
> code is to invoke one of those primatives, just like an OS has
> conventions on how its kernal routines should be invoked from user
> code.  PO has chosen to reserve some function names as primatives, and
> to invoke the primative the code makes a regular call to a function with
> that name.  (That's fairly normal. x86utm loads the coff file and can
> identify points where those primative calls are being made.) Then, to
> make his code compile he decided to actually include a real function in
> the user code with that name!
>
> So the strange choice perhaps was the inclusion of an actual dummy
> function in the user code.  I mean, he could just have declared a
> function prototype line for Alloc and left it at that - the code would
> still compile ok.  That's what I would have done probably, or maybe
> provided an actual Alloc "library" stub routine to wrap whatever it
> takes to actually invoke the primative [maybe issue a reserved x86
> instruction, or an actual x86 gate-type instruction like a real OS
> might, which would be intercepted by x86utm.].  But it's the least of
> all PO's sins!
>
>
>> The fact that we don't have a clear algorithm is to be expected.
>
> Isn't the algorithm clear now?  It's just what he's been saying for
> ages.  (Checking for calls to H's own address from within simulated P
> with the same parameters blah blah - we have the code now, and nothing
> has changed because the exact code was never the issue.)
>
> Yeah, I suppose PO might at some point need to specify exactly what his
> primatives do, but it seems we could work that out ourselves from the
> code if we really had to... [we don't :) ]
>
>> We'll
>> never see the simple snippet of C-like code that expressed the algorithm
>> the PO claimed to have in Dec 2018 because that was a...  er... an
>> alternative fact.
>>
>> What we have here is a tar-pit for people to get sucked into to keep the
>> discussion of the wrong answer going.  I'll give PO credit, though.  I
>> had no idea he could admit to H giving the wrong answer and still have
>> people talking about it years later.
>>
>>> I'm not clear what his .zip file contains...
>>
>> And that's not an accident.  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. (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'll probably give it a try at some point, just
> because I like playing with code, not because I need to learn where PO
> has gone wrong...)
>
> I'm not sure if I would need to download a version of libx86emu - there
> are a handful of files in the zip file that seem to be from libx86emu,
> but I would have thought that project would be Much bigger!  [Looking on
> github it seems at first glance the project is actually just the handful
> of files in the zipfile!  We'll see.]
>
> Mike.
>

*Halt Decider and P*
07/22/2022 07:05 AM 10,390 Halt7.c
07/22/2022 07:09 AM 3,989 Halt7.obj

*x86utm operating system*
07/22/2022 07:08 AM 72,499 x86utm.cpp
07/01/2022 03:40 PM 32,931 Read_COFF_Object.h

*x86 emulator source-code*
10/04/2020 07:44 PM 17,240 api.c
05/03/2021 02:33 PM 58,872 decode.c
06/28/2020 05:22 PM 20,495 mem.c
06/30/2020 12:06 AM 141,330 ops.c
06/27/2022 11:15 AM 63,704 ops2.c
06/30/2020 12:09 AM 73,787 prim_ops.c
01/28/2020 06:19 AM 5,542 decode.h
02/17/2020 08:56 PM 18,558 getopt.h
01/28/2020 06:19 AM 1,859 mem.h
01/28/2020 06:19 AM 1,954 ops.h
01/28/2020 06:19 AM 6,133 prim_ops.h
02/09/2021 10:40 PM 19,596 x86emu.h
10/04/2020 07:34 PM 4,996 x86emu_int.h

Compiles into x86utm.exe and takes Halt7.obj as its only argument

--
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 Sunday, 24 July 2022 at 01:27:29 UTC+2, olcott wrote:
> On 7/23/2022 6:22 PM, Mike Terry wrote:
> > On 23/07/2022 22:52, Ben Bacarisse wrote:
> >> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
> >>
> >>> On 22/07/2022 23:41, Ben Bacarisse wrote:
> >>>> o...@iki.fi (Otto J. Makela) writes:
> >>>>
> >>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>
> >>>>>> https://www.liarparadox.org/2022_07_22.zip
> >>>>>
> >>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> >>>>> small errors from decode.c, because of two variable loop declarations.
> >>>>>
> >>>>> decode.c: In function ‘x86emu_run’:
> >>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
> >>>>> allowed in C99 mode
> >>>>> for (int N = 0; N <
> >>>>> sizeof(emu->line_of_code.Disassembly_text); N++)
> >>>>> ^
> >>>> And so on...
> >>>> But this code a distraction because:
> >>>> (a) Every file that defines H will dump core as soon as any allocated
> >>>> storage is used. (Look at the definition of Allocate.)
> >>>
> >>> You are looking at the definition in halt7.c:
> >>>
> >>> u32* Allocate(u32 size) { return 0; }
> >>> ?
> >>
> >> Yes.
> >>
> >>> That code isn't actually "executed" by x86utm - it's intercepted
> >>> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
> >>> only compiled (not linked) and then the coff file is loaded and
> >>> "executed" within PO's x86 simulator x86utm.exe.)
> >>
> >> The C source for H should be code that follows C's semantics. The only
> >> C function called H calls a function that accesses that null pointer.
> >
> > Well, it's up to PO to define the semantics for his chosen programming
> > model, and he doesn't really understand what that would mean, so there's
> > nothing to be done about this.
> >
> > In any case, within his model, there are some primatives not present in
> > C language semantics, like single stepping a simulation, allocating a
> > block of memory, outputing message strings, whatever. Those primatives
> > are handled by his x86utm. He has to have a convention for how the C
> > code is to invoke one of those primatives, just like an OS has
> > conventions on how its kernal routines should be invoked from user
> > code. PO has chosen to reserve some function names as primatives, and
> > to invoke the primative the code makes a regular call to a function with
> > that name. (That's fairly normal. x86utm loads the coff file and can
> > identify points where those primative calls are being made.) Then, to
> > make his code compile he decided to actually include a real function in
> > the user code with that name!
> >
> > So the strange choice perhaps was the inclusion of an actual dummy
> > function in the user code. I mean, he could just have declared a
> > function prototype line for Alloc and left it at that - the code would
> > still compile ok. That's what I would have done probably, or maybe
> > provided an actual Alloc "library" stub routine to wrap whatever it
> > takes to actually invoke the primative [maybe issue a reserved x86
> > instruction, or an actual x86 gate-type instruction like a real OS
> > might, which would be intercepted by x86utm.]. But it's the least of
> > all PO's sins!
> >
> >
> >> The fact that we don't have a clear algorithm is to be expected.
> >
> > Isn't the algorithm clear now? It's just what he's been saying for
> > ages. (Checking for calls to H's own address from within simulated P
> > with the same parameters blah blah - we have the code now, and nothing
> > has changed because the exact code was never the issue.)
> >
> > Yeah, I suppose PO might at some point need to specify exactly what his
> > primatives do, but it seems we could work that out ourselves from the
> > code if we really had to... [we don't :) ]
> >
> >> We'll
> >> never see the simple snippet of C-like code that expressed the algorithm
> >> the PO claimed to have in Dec 2018 because that was a... er... an
> >> alternative fact.
> >>
> >> What we have here is a tar-pit for people to get sucked into to keep the
> >> discussion of the wrong answer going. I'll give PO credit, though. I
> >> had no idea he could admit to H giving the wrong answer and still have
> >> people talking about it years later.
> >>
> >>> I'm not clear what his .zip file contains...
> >>
> >> And that's not an accident. 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. (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'll probably give it a try at some point, just
> > because I like playing with code, not because I need to learn where PO
> > has gone wrong...)
> >
> > I'm not sure if I would need to download a version of libx86emu - there
> > are a handful of files in the zip file that seem to be from libx86emu,
> > but I would have thought that project would be Much bigger! [Looking on
> > github it seems at first glance the project is actually just the handful
> > of files in the zipfile! We'll see.]
> >
> > Mike.
> >
> *Halt Decider and P*
> 07/22/2022 07:05 AM 10,390 Halt7.c
> 07/22/2022 07:09 AM 3,989 Halt7.obj
> *x86utm operating system*
> 07/22/2022 07:08 AM 72,499 x86utm.cpp
> 07/01/2022 03:40 PM 32,931 Read_COFF_Object.h
>
> *x86 emulator source-code*
> 10/04/2020 07:44 PM 17,240 api.c
> 05/03/2021 02:33 PM 58,872 decode.c
> 06/28/2020 05:22 PM 20,495 mem.c
> 06/30/2020 12:06 AM 141,330 ops.c
> 06/27/2022 11:15 AM 63,704 ops2.c
> 06/30/2020 12:09 AM 73,787 prim_ops.c
> 01/28/2020 06:19 AM 5,542 decode.h
> 02/17/2020 08:56 PM 18,558 getopt.h
> 01/28/2020 06:19 AM 1,859 mem.h
> 01/28/2020 06:19 AM 1,954 ops.h
> 01/28/2020 06:19 AM 6,133 prim_ops.h
> 02/09/2021 10:40 PM 19,596 x86emu.h
> 10/04/2020 07:34 PM 4,996 x86emu_int.h
> Compiles into x86utm.exe and takes Halt7.obj as its only argument

Why all the shenanigans? Why not just give us h.exe which takes p.c (the source code of the pathological case) as its only argument?

On 7/24/2022 12:17 AM, Skep Dick wrote:
> On Sunday, 24 July 2022 at 01:27:29 UTC+2, olcott wrote:
>> On 7/23/2022 6:22 PM, Mike Terry wrote:
>>> On 23/07/2022 22:52, Ben Bacarisse wrote:
>>>> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>>>>
>>>>> On 22/07/2022 23:41, Ben Bacarisse wrote:
>>>>>> o...@iki.fi (Otto J. Makela) writes:
>>>>>>
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> https://www.liarparadox.org/2022_07_22.zip
>>>>>>>
>>>>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>>>>>> small errors from decode.c, because of two variable loop declarations.
>>>>>>>
>>>>>>> decode.c: In function ‘x86emu_run’:
>>>>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
>>>>>>> allowed in C99 mode
>>>>>>> for (int N = 0; N <
>>>>>>> sizeof(emu->line_of_code.Disassembly_text); N++)
>>>>>>> ^
>>>>>> And so on...
>>>>>> But this code a distraction because:
>>>>>> (a) Every file that defines H will dump core as soon as any allocated
>>>>>> storage is used. (Look at the definition of Allocate.)
>>>>>
>>>>> You are looking at the definition in halt7.c:
>>>>>
>>>>> u32* Allocate(u32 size) { return 0; }
>>>>> ?
>>>>
>>>> Yes.
>>>>
>>>>> That code isn't actually "executed" by x86utm - it's intercepted
>>>>> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
>>>>> only compiled (not linked) and then the coff file is loaded and
>>>>> "executed" within PO's x86 simulator x86utm.exe.)
>>>>
>>>> The C source for H should be code that follows C's semantics. The only
>>>> C function called H calls a function that accesses that null pointer.
>>>
>>> Well, it's up to PO to define the semantics for his chosen programming
>>> model, and he doesn't really understand what that would mean, so there's
>>> nothing to be done about this.
>>>
>>> In any case, within his model, there are some primatives not present in
>>> C language semantics, like single stepping a simulation, allocating a
>>> block of memory, outputing message strings, whatever. Those primatives
>>> are handled by his x86utm. He has to have a convention for how the C
>>> code is to invoke one of those primatives, just like an OS has
>>> conventions on how its kernal routines should be invoked from user
>>> code. PO has chosen to reserve some function names as primatives, and
>>> to invoke the primative the code makes a regular call to a function with
>>> that name. (That's fairly normal. x86utm loads the coff file and can
>>> identify points where those primative calls are being made.) Then, to
>>> make his code compile he decided to actually include a real function in
>>> the user code with that name!
>>>
>>> So the strange choice perhaps was the inclusion of an actual dummy
>>> function in the user code. I mean, he could just have declared a
>>> function prototype line for Alloc and left it at that - the code would
>>> still compile ok. That's what I would have done probably, or maybe
>>> provided an actual Alloc "library" stub routine to wrap whatever it
>>> takes to actually invoke the primative [maybe issue a reserved x86
>>> instruction, or an actual x86 gate-type instruction like a real OS
>>> might, which would be intercepted by x86utm.]. But it's the least of
>>> all PO's sins!
>>>
>>>
>>>> The fact that we don't have a clear algorithm is to be expected.
>>>
>>> Isn't the algorithm clear now? It's just what he's been saying for
>>> ages. (Checking for calls to H's own address from within simulated P
>>> with the same parameters blah blah - we have the code now, and nothing
>>> has changed because the exact code was never the issue.)
>>>
>>> Yeah, I suppose PO might at some point need to specify exactly what his
>>> primatives do, but it seems we could work that out ourselves from the
>>> code if we really had to... [we don't :) ]
>>>
>>>> We'll
>>>> never see the simple snippet of C-like code that expressed the algorithm
>>>> the PO claimed to have in Dec 2018 because that was a... er... an
>>>> alternative fact.
>>>>
>>>> What we have here is a tar-pit for people to get sucked into to keep the
>>>> discussion of the wrong answer going. I'll give PO credit, though. I
>>>> had no idea he could admit to H giving the wrong answer and still have
>>>> people talking about it years later.
>>>>
>>>>> I'm not clear what his .zip file contains...
>>>>
>>>> And that's not an accident. 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. (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'll probably give it a try at some point, just
>>> because I like playing with code, not because I need to learn where PO
>>> has gone wrong...)
>>>
>>> I'm not sure if I would need to download a version of libx86emu - there
>>> are a handful of files in the zip file that seem to be from libx86emu,
>>> but I would have thought that project would be Much bigger! [Looking on
>>> github it seems at first glance the project is actually just the handful
>>> of files in the zipfile! We'll see.]
>>>
>>> Mike.
>>>
>> *Halt Decider and P*
>> 07/22/2022 07:05 AM 10,390 Halt7.c
>> 07/22/2022 07:09 AM 3,989 Halt7.obj

>> *x86utm operating system*
>> 07/22/2022 07:08 AM 72,499 x86utm.cpp
>> 07/01/2022 03:40 PM 32,931 Read_COFF_Object.h
>>
>> *x86 emulator source-code*
>> 10/04/2020 07:44 PM 17,240 api.c
>> 05/03/2021 02:33 PM 58,872 decode.c
>> 06/28/2020 05:22 PM 20,495 mem.c
>> 06/30/2020 12:06 AM 141,330 ops.c
>> 06/27/2022 11:15 AM 63,704 ops2.c
>> 06/30/2020 12:09 AM 73,787 prim_ops.c
>> 01/28/2020 06:19 AM 5,542 decode.h
>> 02/17/2020 08:56 PM 18,558 getopt.h
>> 01/28/2020 06:19 AM 1,859 mem.h
>> 01/28/2020 06:19 AM 1,954 ops.h
>> 01/28/2020 06:19 AM 6,133 prim_ops.h
>> 02/09/2021 10:40 PM 19,596 x86emu.h
>> 10/04/2020 07:34 PM 4,996 x86emu_int.h
>> Compiles into x86utm.exe and takes Halt7.obj as its only argument
>
> Why all the shenanigans? Why not just give us h.exe which takes p.c (the source code of the pathological case) as its only argument?

To understand what I say you have to actually pay attention to what I
say. H and P are in Halt7.c. x86utm.exe takes Halt7.obj as its input.

--
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 Sunday, 24 July 2022 at 16:57:12 UTC+2, olcott wrote:
> On 7/24/2022 12:17 AM, Skep Dick wrote:
> > On Sunday, 24 July 2022 at 01:27:29 UTC+2, olcott wrote:
> >> On 7/23/2022 6:22 PM, Mike Terry wrote:
> >>> On 23/07/2022 22:52, Ben Bacarisse wrote:
> >>>> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
> >>>>
> >>>>> On 22/07/2022 23:41, Ben Bacarisse wrote:
> >>>>>> o...@iki.fi (Otto J. Makela) writes:
> >>>>>>
> >>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>
> >>>>>>>> https://www.liarparadox.org/2022_07_22.zip
> >>>>>>>
> >>>>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> >>>>>>> small errors from decode.c, because of two variable loop declarations.
> >>>>>>>
> >>>>>>> decode.c: In function ‘x86emu_run’:
> >>>>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
> >>>>>>> allowed in C99 mode
> >>>>>>> for (int N = 0; N <
> >>>>>>> sizeof(emu->line_of_code.Disassembly_text); N++)
> >>>>>>> ^
> >>>>>> And so on...
> >>>>>> But this code a distraction because:
> >>>>>> (a) Every file that defines H will dump core as soon as any allocated
> >>>>>> storage is used. (Look at the definition of Allocate.)
> >>>>>
> >>>>> You are looking at the definition in halt7.c:
> >>>>>
> >>>>> u32* Allocate(u32 size) { return 0; }
> >>>>> ?
> >>>>
> >>>> Yes.
> >>>>
> >>>>> That code isn't actually "executed" by x86utm - it's intercepted
> >>>>> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
> >>>>> only compiled (not linked) and then the coff file is loaded and
> >>>>> "executed" within PO's x86 simulator x86utm.exe.)
> >>>>
> >>>> The C source for H should be code that follows C's semantics. The only
> >>>> C function called H calls a function that accesses that null pointer..
> >>>
> >>> Well, it's up to PO to define the semantics for his chosen programming
> >>> model, and he doesn't really understand what that would mean, so there's
> >>> nothing to be done about this.
> >>>
> >>> In any case, within his model, there are some primatives not present in
> >>> C language semantics, like single stepping a simulation, allocating a
> >>> block of memory, outputing message strings, whatever. Those primatives
> >>> are handled by his x86utm. He has to have a convention for how the C
> >>> code is to invoke one of those primatives, just like an OS has
> >>> conventions on how its kernal routines should be invoked from user
> >>> code. PO has chosen to reserve some function names as primatives, and
> >>> to invoke the primative the code makes a regular call to a function with
> >>> that name. (That's fairly normal. x86utm loads the coff file and can
> >>> identify points where those primative calls are being made.) Then, to
> >>> make his code compile he decided to actually include a real function in
> >>> the user code with that name!
> >>>
> >>> So the strange choice perhaps was the inclusion of an actual dummy
> >>> function in the user code. I mean, he could just have declared a
> >>> function prototype line for Alloc and left it at that - the code would
> >>> still compile ok. That's what I would have done probably, or maybe
> >>> provided an actual Alloc "library" stub routine to wrap whatever it
> >>> takes to actually invoke the primative [maybe issue a reserved x86
> >>> instruction, or an actual x86 gate-type instruction like a real OS
> >>> might, which would be intercepted by x86utm.]. But it's the least of
> >>> all PO's sins!
> >>>
> >>>
> >>>> The fact that we don't have a clear algorithm is to be expected.
> >>>
> >>> Isn't the algorithm clear now? It's just what he's been saying for
> >>> ages. (Checking for calls to H's own address from within simulated P
> >>> with the same parameters blah blah - we have the code now, and nothing
> >>> has changed because the exact code was never the issue.)
> >>>
> >>> Yeah, I suppose PO might at some point need to specify exactly what his
> >>> primatives do, but it seems we could work that out ourselves from the
> >>> code if we really had to... [we don't :) ]
> >>>
> >>>> We'll
> >>>> never see the simple snippet of C-like code that expressed the algorithm
> >>>> the PO claimed to have in Dec 2018 because that was a... er... an
> >>>> alternative fact.
> >>>>
> >>>> What we have here is a tar-pit for people to get sucked into to keep the
> >>>> discussion of the wrong answer going. I'll give PO credit, though. I
> >>>> had no idea he could admit to H giving the wrong answer and still have
> >>>> people talking about it years later.
> >>>>
> >>>>> I'm not clear what his .zip file contains...
> >>>>
> >>>> And that's not an accident. 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. (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'll probably give it a try at some point, just
> >>> because I like playing with code, not because I need to learn where PO
> >>> has gone wrong...)
> >>>
> >>> I'm not sure if I would need to download a version of libx86emu - there
> >>> are a handful of files in the zip file that seem to be from libx86emu,
> >>> but I would have thought that project would be Much bigger! [Looking on
> >>> github it seems at first glance the project is actually just the handful
> >>> of files in the zipfile! We'll see.]
> >>>
> >>> Mike.
> >>>
> >> *Halt Decider and P*
> >> 07/22/2022 07:05 AM 10,390 Halt7.c
> >> 07/22/2022 07:09 AM 3,989 Halt7.obj
>
> >> *x86utm operating system*
> >> 07/22/2022 07:08 AM 72,499 x86utm.cpp
> >> 07/01/2022 03:40 PM 32,931 Read_COFF_Object.h
> >>
> >> *x86 emulator source-code*
> >> 10/04/2020 07:44 PM 17,240 api.c
> >> 05/03/2021 02:33 PM 58,872 decode.c
> >> 06/28/2020 05:22 PM 20,495 mem.c
> >> 06/30/2020 12:06 AM 141,330 ops.c
> >> 06/27/2022 11:15 AM 63,704 ops2.c
> >> 06/30/2020 12:09 AM 73,787 prim_ops.c
> >> 01/28/2020 06:19 AM 5,542 decode.h
> >> 02/17/2020 08:56 PM 18,558 getopt.h
> >> 01/28/2020 06:19 AM 1,859 mem.h
> >> 01/28/2020 06:19 AM 1,954 ops.h
> >> 01/28/2020 06:19 AM 6,133 prim_ops.h
> >> 02/09/2021 10:40 PM 19,596 x86emu.h
> >> 10/04/2020 07:34 PM 4,996 x86emu_int.h
> >> Compiles into x86utm.exe and takes Halt7.obj as its only argument
> >
> > Why all the shenanigans? Why not just give us h.exe which takes p.c (the source code of the pathological case) as its only argument?
> To understand what I say you have to actually pay attention to what I
> say. H and P are in Halt7.c. x86utm.exe takes Halt7.obj as its input.

That doesn't address my question.

On 7/24/2022 10:31 AM, Skep Dick wrote:
> On Sunday, 24 July 2022 at 16:57:12 UTC+2, olcott wrote:
>> On 7/24/2022 12:17 AM, Skep Dick wrote:
>>> On Sunday, 24 July 2022 at 01:27:29 UTC+2, olcott wrote:
>>>> On 7/23/2022 6:22 PM, Mike Terry wrote:
>>>>> On 23/07/2022 22:52, Ben Bacarisse wrote:
>>>>>> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>>>>>>
>>>>>>> On 22/07/2022 23:41, Ben Bacarisse wrote:
>>>>>>>> o...@iki.fi (Otto J. Makela) writes:
>>>>>>>>
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> https://www.liarparadox.org/2022_07_22.zip
>>>>>>>>>
>>>>>>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
>>>>>>>>> small errors from decode.c, because of two variable loop declarations.
>>>>>>>>>
>>>>>>>>> decode.c: In function ‘x86emu_run’:
>>>>>>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
>>>>>>>>> allowed in C99 mode
>>>>>>>>> for (int N = 0; N <
>>>>>>>>> sizeof(emu->line_of_code.Disassembly_text); N++)
>>>>>>>>> ^
>>>>>>>> And so on...
>>>>>>>> But this code a distraction because:
>>>>>>>> (a) Every file that defines H will dump core as soon as any allocated
>>>>>>>> storage is used. (Look at the definition of Allocate.)
>>>>>>>
>>>>>>> You are looking at the definition in halt7.c:
>>>>>>>
>>>>>>> u32* Allocate(u32 size) { return 0; }
>>>>>>> ?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>> That code isn't actually "executed" by x86utm - it's intercepted
>>>>>>> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
>>>>>>> only compiled (not linked) and then the coff file is loaded and
>>>>>>> "executed" within PO's x86 simulator x86utm.exe.)
>>>>>>
>>>>>> The C source for H should be code that follows C's semantics. The only
>>>>>> C function called H calls a function that accesses that null pointer.
>>>>>
>>>>> Well, it's up to PO to define the semantics for his chosen programming
>>>>> model, and he doesn't really understand what that would mean, so there's
>>>>> nothing to be done about this.
>>>>>
>>>>> In any case, within his model, there are some primatives not present in
>>>>> C language semantics, like single stepping a simulation, allocating a
>>>>> block of memory, outputing message strings, whatever. Those primatives
>>>>> are handled by his x86utm. He has to have a convention for how the C
>>>>> code is to invoke one of those primatives, just like an OS has
>>>>> conventions on how its kernal routines should be invoked from user
>>>>> code. PO has chosen to reserve some function names as primatives, and
>>>>> to invoke the primative the code makes a regular call to a function with
>>>>> that name. (That's fairly normal. x86utm loads the coff file and can
>>>>> identify points where those primative calls are being made.) Then, to
>>>>> make his code compile he decided to actually include a real function in
>>>>> the user code with that name!
>>>>>
>>>>> So the strange choice perhaps was the inclusion of an actual dummy
>>>>> function in the user code. I mean, he could just have declared a
>>>>> function prototype line for Alloc and left it at that - the code would
>>>>> still compile ok. That's what I would have done probably, or maybe
>>>>> provided an actual Alloc "library" stub routine to wrap whatever it
>>>>> takes to actually invoke the primative [maybe issue a reserved x86
>>>>> instruction, or an actual x86 gate-type instruction like a real OS
>>>>> might, which would be intercepted by x86utm.]. But it's the least of
>>>>> all PO's sins!
>>>>>
>>>>>
>>>>>> The fact that we don't have a clear algorithm is to be expected.
>>>>>
>>>>> Isn't the algorithm clear now? It's just what he's been saying for
>>>>> ages. (Checking for calls to H's own address from within simulated P
>>>>> with the same parameters blah blah - we have the code now, and nothing
>>>>> has changed because the exact code was never the issue.)
>>>>>
>>>>> Yeah, I suppose PO might at some point need to specify exactly what his
>>>>> primatives do, but it seems we could work that out ourselves from the
>>>>> code if we really had to... [we don't :) ]
>>>>>
>>>>>> We'll
>>>>>> never see the simple snippet of C-like code that expressed the algorithm
>>>>>> the PO claimed to have in Dec 2018 because that was a... er... an
>>>>>> alternative fact.
>>>>>>
>>>>>> What we have here is a tar-pit for people to get sucked into to keep the
>>>>>> discussion of the wrong answer going. I'll give PO credit, though. I
>>>>>> had no idea he could admit to H giving the wrong answer and still have
>>>>>> people talking about it years later.
>>>>>>
>>>>>>> I'm not clear what his .zip file contains...
>>>>>>
>>>>>> And that's not an accident. 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. (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'll probably give it a try at some point, just
>>>>> because I like playing with code, not because I need to learn where PO
>>>>> has gone wrong...)
>>>>>
>>>>> I'm not sure if I would need to download a version of libx86emu - there
>>>>> are a handful of files in the zip file that seem to be from libx86emu,
>>>>> but I would have thought that project would be Much bigger! [Looking on
>>>>> github it seems at first glance the project is actually just the handful
>>>>> of files in the zipfile! We'll see.]
>>>>>
>>>>> Mike.
>>>>>
>>>> *Halt Decider and P*
>>>> 07/22/2022 07:05 AM 10,390 Halt7.c
>>>> 07/22/2022 07:09 AM 3,989 Halt7.obj
>>
>>>> *x86utm operating system*
>>>> 07/22/2022 07:08 AM 72,499 x86utm.cpp
>>>> 07/01/2022 03:40 PM 32,931 Read_COFF_Object.h
>>>>
>>>> *x86 emulator source-code*
>>>> 10/04/2020 07:44 PM 17,240 api.c
>>>> 05/03/2021 02:33 PM 58,872 decode.c
>>>> 06/28/2020 05:22 PM 20,495 mem.c
>>>> 06/30/2020 12:06 AM 141,330 ops.c
>>>> 06/27/2022 11:15 AM 63,704 ops2.c
>>>> 06/30/2020 12:09 AM 73,787 prim_ops.c
>>>> 01/28/2020 06:19 AM 5,542 decode.h
>>>> 02/17/2020 08:56 PM 18,558 getopt.h
>>>> 01/28/2020 06:19 AM 1,859 mem.h
>>>> 01/28/2020 06:19 AM 1,954 ops.h
>>>> 01/28/2020 06:19 AM 6,133 prim_ops.h
>>>> 02/09/2021 10:40 PM 19,596 x86emu.h
>>>> 10/04/2020 07:34 PM 4,996 x86emu_int.h
>>>> Compiles into x86utm.exe and takes Halt7.obj as its only argument
>>>
>>> Why all the shenanigans? Why not just give us h.exe which takes p.c (the source code of the pathological case) as its only argument?
>> To understand what I say you have to actually pay attention to what I
>> say. H and P are in Halt7.c. x86utm.exe takes Halt7.obj as its input.
>
> That doesn't address my question.

You question was entirely based on a false assumption.

On Sunday, 24 July 2022 at 17:42:27 UTC+2, olcott wrote:
> On 7/24/2022 10:31 AM, Skep Dick wrote:
> > On Sunday, 24 July 2022 at 16:57:12 UTC+2, olcott wrote:
> >> On 7/24/2022 12:17 AM, Skep Dick wrote:
> >>> On Sunday, 24 July 2022 at 01:27:29 UTC+2, olcott wrote:
> >>>> On 7/23/2022 6:22 PM, Mike Terry wrote:
> >>>>> On 23/07/2022 22:52, Ben Bacarisse wrote:
> >>>>>> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
> >>>>>>
> >>>>>>> On 22/07/2022 23:41, Ben Bacarisse wrote:
> >>>>>>>> o...@iki.fi (Otto J. Makela) writes:
> >>>>>>>>
> >>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> https://www.liarparadox.org/2022_07_22.zip
> >>>>>>>>>
> >>>>>>>>> Under CentOS Linux release 7.9.2009 (Core) and gcc-4.8.5-44 I got some
> >>>>>>>>> small errors from decode.c, because of two variable loop declarations.
> >>>>>>>>>
> >>>>>>>>> decode.c: In function ‘x86emu_run’:
> >>>>>>>>> decode.c:251:5: error: ‘for’ loop initial declarations are only
> >>>>>>>>> allowed in C99 mode
> >>>>>>>>> for (int N = 0; N <
> >>>>>>>>> sizeof(emu->line_of_code.Disassembly_text); N++)
> >>>>>>>>> ^
> >>>>>>>> And so on...
> >>>>>>>> But this code a distraction because:
> >>>>>>>> (a) Every file that defines H will dump core as soon as any allocated
> >>>>>>>> storage is used. (Look at the definition of Allocate.)
> >>>>>>>
> >>>>>>> You are looking at the definition in halt7.c:
> >>>>>>>
> >>>>>>> u32* Allocate(u32 size) { return 0; }
> >>>>>>> ?
> >>>>>>
> >>>>>> Yes.
> >>>>>>
> >>>>>>> That code isn't actually "executed" by x86utm - it's intercepted
> >>>>>>> somehow and actioned somewhere within x86utm. (Remember, halt7.c is
> >>>>>>> only compiled (not linked) and then the coff file is loaded and
> >>>>>>> "executed" within PO's x86 simulator x86utm.exe.)
> >>>>>>
> >>>>>> The C source for H should be code that follows C's semantics. The only
> >>>>>> C function called H calls a function that accesses that null pointer.
> >>>>>
> >>>>> Well, it's up to PO to define the semantics for his chosen programming
> >>>>> model, and he doesn't really understand what that would mean, so there's
> >>>>> nothing to be done about this.
> >>>>>
> >>>>> In any case, within his model, there are some primatives not present in
> >>>>> C language semantics, like single stepping a simulation, allocating a
> >>>>> block of memory, outputing message strings, whatever. Those primatives
> >>>>> are handled by his x86utm. He has to have a convention for how the C
> >>>>> code is to invoke one of those primatives, just like an OS has
> >>>>> conventions on how its kernal routines should be invoked from user
> >>>>> code. PO has chosen to reserve some function names as primatives, and
> >>>>> to invoke the primative the code makes a regular call to a function with
> >>>>> that name. (That's fairly normal. x86utm loads the coff file and can
> >>>>> identify points where those primative calls are being made.) Then, to
> >>>>> make his code compile he decided to actually include a real function in
> >>>>> the user code with that name!
> >>>>>
> >>>>> So the strange choice perhaps was the inclusion of an actual dummy
> >>>>> function in the user code. I mean, he could just have declared a
> >>>>> function prototype line for Alloc and left it at that - the code would
> >>>>> still compile ok. That's what I would have done probably, or maybe
> >>>>> provided an actual Alloc "library" stub routine to wrap whatever it
> >>>>> takes to actually invoke the primative [maybe issue a reserved x86
> >>>>> instruction, or an actual x86 gate-type instruction like a real OS
> >>>>> might, which would be intercepted by x86utm.]. But it's the least of
> >>>>> all PO's sins!
> >>>>>
> >>>>>
> >>>>>> The fact that we don't have a clear algorithm is to be expected.
> >>>>>
> >>>>> Isn't the algorithm clear now? It's just what he's been saying for
> >>>>> ages. (Checking for calls to H's own address from within simulated P
> >>>>> with the same parameters blah blah - we have the code now, and nothing
> >>>>> has changed because the exact code was never the issue.)
> >>>>>
> >>>>> Yeah, I suppose PO might at some point need to specify exactly what his
> >>>>> primatives do, but it seems we could work that out ourselves from the
> >>>>> code if we really had to... [we don't :) ]
> >>>>>
> >>>>>> We'll
> >>>>>> never see the simple snippet of C-like code that expressed the algorithm
> >>>>>> the PO claimed to have in Dec 2018 because that was a... er... an
> >>>>>> alternative fact.
> >>>>>>
> >>>>>> What we have here is a tar-pit for people to get sucked into to keep the
> >>>>>> discussion of the wrong answer going. I'll give PO credit, though. I
> >>>>>> had no idea he could admit to H giving the wrong answer and still have
> >>>>>> people talking about it years later.
> >>>>>>
> >>>>>>> I'm not clear what his .zip file contains...
> >>>>>>
> >>>>>> And that's not an accident. 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. (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'll probably give it a try at some point, just
> >>>>> because I like playing with code, not because I need to learn where PO
> >>>>> has gone wrong...)
> >>>>>
> >>>>> I'm not sure if I would need to download a version of libx86emu - there
> >>>>> are a handful of files in the zip file that seem to be from libx86emu,
> >>>>> but I would have thought that project would be Much bigger! [Looking on
> >>>>> github it seems at first glance the project is actually just the handful
> >>>>> of files in the zipfile! We'll see.]
> >>>>>
> >>>>> Mike.
> >>>>>
> >>>> *Halt Decider and P*
> >>>> 07/22/2022 07:05 AM 10,390 Halt7.c
> >>>> 07/22/2022 07:09 AM 3,989 Halt7.obj
> >>
> >>>> *x86utm operating system*
> >>>> 07/22/2022 07:08 AM 72,499 x86utm.cpp
> >>>> 07/01/2022 03:40 PM 32,931 Read_COFF_Object.h
> >>>>
> >>>> *x86 emulator source-code*
> >>>> 10/04/2020 07:44 PM 17,240 api.c
> >>>> 05/03/2021 02:33 PM 58,872 decode.c
> >>>> 06/28/2020 05:22 PM 20,495 mem.c
> >>>> 06/30/2020 12:06 AM 141,330 ops.c
> >>>> 06/27/2022 11:15 AM 63,704 ops2.c
> >>>> 06/30/2020 12:09 AM 73,787 prim_ops.c
> >>>> 01/28/2020 06:19 AM 5,542 decode.h
> >>>> 02/17/2020 08:56 PM 18,558 getopt.h
> >>>> 01/28/2020 06:19 AM 1,859 mem.h
> >>>> 01/28/2020 06:19 AM 1,954 ops.h
> >>>> 01/28/2020 06:19 AM 6,133 prim_ops.h
> >>>> 02/09/2021 10:40 PM 19,596 x86emu.h
> >>>> 10/04/2020 07:34 PM 4,996 x86emu_int.h
> >>>> Compiles into x86utm.exe and takes Halt7.obj as its only argument
> >>>
> >>> Why all the shenanigans? Why not just give us h.exe which takes p.c (the source code of the pathological case) as its only argument?
> >> To understand what I say you have to actually pay attention to what I
> >> say. H and P are in Halt7.c. x86utm.exe takes Halt7.obj as its input.
> >
> > That doesn't address my question.
> You question was entirely based on a false assumption.

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.

--
Ben.

On 7/24/2022 2:29 PM, 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.
>

It probably also compiles under Ubuntu 1604.
I have not checked this for many months.

The Halt7.c file must be compiled under Windows
because it must be COFF object file format.
Halt7.obj is provided in the release.

Read_COFF_Object.h obtains all of the data from
the COFF object file.

This runs main() in Halt7.c
D:\>x86utm.exe Halt7.obj

--
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 Sunday, 24 July 2022 at 21:30:00 UTC+2, Ben Bacarisse wrote:
> Mike Terry <news.dead.p...@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.
>
> --
> Ben.

His objective has been pretty clear from the get go (and even more so after he explicitly stepped out of character to beg me to disagree with him and continue to engage him).

He's taking Cunningham's law to the extreme so he doesn't have to learn the theory in solitude.

On 7/24/2022 3:06 PM, Skep Dick wrote:
> On Sunday, 24 July 2022 at 21:30:00 UTC+2, Ben Bacarisse wrote:
>> Mike Terry <news.dead.p...@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.
>>
>> --
>> Ben.
>
> His objective has been pretty clear from the get go (and even more so after he explicitly stepped out of character to beg me to disagree with him and continue to engage him).
>
> He's taking Cunningham's law to the extreme so he doesn't have to learn the theory in solitude.

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* ?

--
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 4:06 PM, Skep Dick wrote:
> On Sunday, 24 July 2022 at 21:30:00 UTC+2, Ben Bacarisse wrote:
>> Mike Terry <news.dead.p...@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.
>>
>> --
>> Ben.
>
> His objective has been pretty clear from the get go (and even more so after he explicitly stepped out of character to beg me to disagree with him and continue to engage him).
>
> He's taking Cunningham's law to the extreme so he doesn't have to learn the theory in solitude.

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.

Maybe he hopes someone else can disprove the well established Theorem,
but that is like spitting into the wind.

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.

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.

On 7/24/2022 2: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.

That statement is probably not right in two ways:

1. Humans might or might not be able to spot or prove non-terminating
loops by inspection of traces and/or source code. (Let' skip the silly
nonsense of compiler output unless it supplies some serious help.) If
humans could do this, many of those juicy Number Theory conjectures,
such as the 3-1 problem, would have been settled ages ago.

2. In fact, TM are ideal for spotting infinite loops. Consider how a TM
determines halting on programs built with inferior architectures -
linear bounded on down the hierarchy: The TM takes a representation of
the program and its input and acts like an interpreter (e.g., a UTM but
simulating inferior class programs). Since the size of the state is
bounded its rather simple: after a state transition, put the new state
in "storage" on the TMs tape. That state includes the execution state,
tape contents, tape position, etc. Then you search prior state storage
to see if you are at a repeat; if you are, halt and proclaim "LOOP",
otherwise do the next transition, etc. Since the amount of storage to
represent one stage is bounded, you either detect halting or a repeat at
some point. Say the bounds on size of storing a complete state is b,
then the absolute upper bound on the possible different states is 2^b,
where "^" means exponentiation.

What you cannot do is determine halting of all machines of one class
using a machine in that class. Recall the halt problem hierarchy where a
TM is the bottom class. The machines in the next-up class are given an
oracle for the machines in the next lower class; etc. No machine in
class n can determine halting in its own class but can for all classes < n.

>> 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.

+1
--
Jeff Barnett

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.

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.

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.

--
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 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.

On 7/24/22 7:03 PM, 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.

No, everyone see that the pattern has ONE repeat, that is H(P,P)
simulates till it sees P(P) call H(P,P) and because H sees ONE repeat it
aborts, so that a CORRECT simulation of P(P) will never have more than:

P(P) call H(P,P) which simulates P(P) which calls H(P,P), and the first
H aborts its simulation and returns to P(P) which Halt.

Thus there NEVER is "Infinite Recursion" or Non-Halting Behavior because
H(P,P) aborted its simulation and returned non-halting to P(P).

Yes, if you had a DIFFERENT H, that DIDN'T abort, then P(P) would be
non-halting, but THAT H never answer and so fails differently.

With ANY H that DOES abort it simulation and returns 0 for H(P,P) then
P(P) will Halt.

No one cares about the theoretical other H that this P isn't built on, H
needs to handle the P built on it.

>
>>
>> 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.
>
>