#define ptr uintptr_t

void P(ptr x)
{ H(x, x);
}

int H(ptr x, ptr y)
{ ((void(*)(ptr))x)(y);
return 1;
}

int main()
{ H((ptr)P, (ptr)P);
return 0;
}

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Am 11.11.21 um 17:00 schrieb olcott:
> #define ptr uintptr_t
>
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int H(ptr x, ptr y)
> {
>   ((void(*)(ptr))x)(y);
>   return 1;
> }
>
> int main()
> {
>   H((ptr)P, (ptr)P);
>   return 0;
> }

Besides the fact that there is no good reason to write that type unsafe
code in C++ did you test it? The code will never compile because of the
forward reference to H.

And well, H calls P and P calls H. What do you expect?

Marcel

On 11/11/2021 12:01 PM, Marcel Mueller wrote:
> Am 11.11.21 um 17:00 schrieb olcott:
>> #define ptr uintptr_t
>>
>> void P(ptr x)
>> {
>>    H(x, x);
>> }
>>
>> int H(ptr x, ptr y)
>> {
>>    ((void(*)(ptr))x)(y);
>>    return 1;
>> }
>>
>> int main()
>> {
>>    H((ptr)P, (ptr)P);
>>    return 0;
>> }
>
> Besides the fact that there is no good reason to write that type unsafe
> code in C++ did you test it? The code will never compile because of the
> forward reference to H.
>
> And well, H calls P and P calls H. What do you expect?
>
>
> Marcel

Yes the code does compile and I did test it.
This is the pure C part of my halting theorem refutation. I wanted to
get some C experts to weigh in on the the analysis of the C code.

I won't be discussing anything besides the pure C aspects here because
people here get upset.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/2021 11:01 AM, Marcel Mueller wrote:
> Am 11.11.21 um 17:00 schrieb olcott:
>> #define ptr uintptr_t
>>
>> void P(ptr x)
>> {
>>    H(x, x);
>> }
>>
>> int H(ptr x, ptr y)
>> {
>>    ((void(*)(ptr))x)(y);
>>    return 1;
>> }
>>
>> int main()
>> {
>>    H((ptr)P, (ptr)P);
>>    return 0;
>> }
>
> Besides the fact that there is no good reason to write that type unsafe
> code in C++ did you test it? The code will never compile because of the
> forward reference to H.
>
> And well, H calls P and P calls H. What do you expect?
I expect that PO (the OP) is nuts and lonesome. This crap is just
another bid for attention and companionship, no matter the quality of
the interaction.
However many programing languages allow 'mutual recursion" and it's very
useful. Common LISP, for example, has two different forms for lexically
binding functions. One makes the bound functions only visible within the
body of the binding form; the other makes these functions visible in the
bodies of the bound functions themselves as well as the body of the
binding form. Further, the batch compilers do not output "missing
function definition" warnings or errors until the entire batch has been
compiled. Together these features allow incremental development and
debugging as well as mutual recursion.
And as an aside, I think that Common LISP has at least as flexible and
powerful an object system as does any of the C variants.
--
Jeff Barnett

On 11/11/21 1:52 PM, olcott wrote:
> On 11/11/2021 12:01 PM, Marcel Mueller wrote:
>> Am 11.11.21 um 17:00 schrieb olcott:
>>> #define ptr uintptr_t
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    ((void(*)(ptr))x)(y);
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((ptr)P, (ptr)P);
>>>    return 0;
>>> }
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
>>
>>
>> Marcel
>
> Yes the code does compile and I did test it.
> This is the pure C part of my halting theorem refutation. I wanted to
> get some C experts to weigh in on the the analysis of the C code.
>
> I won't be discussing anything besides the pure C aspects here because
> people here get upset.
>

First, this CAN'T be the complete definition of the source file, as at
minimum it needs a #include <stdint.h> to get the definition of uintptr_t

Second, if you are using a version of C that has uintptr_t defined, (C99
or later) then the lack of a declaration for H in P is an error

Only C90 and before allowed the calling of a function with no
declaration before it.

It might 'compile', but if it does, it will include a manditory
diagnostic, and that means that if the compiler still produced an output
file, if you run that program, the behavior of that program is BY
DEFINITON of the Standard, Undefined.

Thus, there ARE NO 'C aspects' of this 'program' as the C standard has
declared that it suppies NO definition of what it does.

FAIL.

On 11/11/2021 1:06 PM, Jeff Barnett wrote:
> On 11/11/2021 11:01 AM, Marcel Mueller wrote:
>> Am 11.11.21 um 17:00 schrieb olcott:
>>> #define ptr uintptr_t
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    ((void(*)(ptr))x)(y);
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((ptr)P, (ptr)P);
>>>    return 0;
>>> }
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
> I expect that PO (the OP) is nuts and lonesome. This crap is just
> another bid for attention and companionship, no matter the quality of
> the interaction.
>

(Attacking the person): This fallacy occurs when, instead of addressing
someone's argument or position, you irrelevantly attack the person or
some aspect of the person who is making the argument.

https://www.txstate.edu/philosophy/resources/fallacy-definitions/Ad-Hominem.html

> However many programing languages allow 'mutual recursion" and it's very
> useful. Common LISP, for example, has two different forms for lexically
> binding functions. One makes the bound functions only visible within the
> body of the binding form; the other makes these functions visible in the
> bodies of the bound functions themselves as well as the body of the
> binding form. Further, the batch compilers do not output "missing
> function definition" warnings or errors until the entire batch has been
> compiled. Together these features allow incremental development and
> debugging as well as mutual recursion.
>
> And as an aside, I think that Common LISP has at least as flexible and
> powerful an object system as does any of the C variants.

That is the strawman error. I am only referring to the x86 machine code
specified by this Microsoft C source-code.

#define ptr uintptr_t

void P(ptr x)
{ H(x, x);
}

int H(ptr x, ptr y)
{ ((void(*)(ptr))x)(y);
return 1;
}

int main()
{ H((ptr)P, (ptr)P);
return 0;
}

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/2021 1:20 PM, Richard Damon wrote:
> On 11/11/21 1:52 PM, olcott wrote:
>> On 11/11/2021 12:01 PM, Marcel Mueller wrote:
>>> Am 11.11.21 um 17:00 schrieb olcott:
>>>> #define ptr uintptr_t
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    H(x, x);
>>>> }
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>>    ((void(*)(ptr))x)(y);
>>>>    return 1;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    H((ptr)P, (ptr)P);
>>>>    return 0;
>>>> }
>>>
>>> Besides the fact that there is no good reason to write that type
>>> unsafe code in C++ did you test it? The code will never compile
>>> because of the forward reference to H.
>>>
>>> And well, H calls P and P calls H. What do you expect?
>>>
>>>
>>> Marcel
>>
>> Yes the code does compile and I did test it.
>> This is the pure C part of my halting theorem refutation. I wanted to
>> get some C experts to weigh in on the the analysis of the C code.
>>
>> I won't be discussing anything besides the pure C aspects here because
>> people here get upset.
>>
>
> First, this CAN'T be the complete definition of the source file, as at
> minimum it needs a #include <stdint.h> to get the definition of uintptr_t
>
> Second, if you are using a version of C that has uintptr_t defined, (C99
> or later) then the lack of a declaration for H in P is an error
>
> Only C90 and before allowed the calling of a function with no
> declaration before it.
>
> It might 'compile', but if it does, it will include a manditory
> diagnostic, and that means that if the compiler still produced an output
> file, if you run that program, the behavior of that program is BY
> DEFINITON of the Standard, Undefined.
>
> Thus, there ARE NO 'C aspects' of this 'program' as the C standard has
> declared that it suppies NO definition of what it does.
>
> FAIL.

I added this: #include <stdint.h>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/21 2:30 PM, olcott wrote:
> On 11/11/2021 1:20 PM, Richard Damon wrote:
>> On 11/11/21 1:52 PM, olcott wrote:
>>> On 11/11/2021 12:01 PM, Marcel Mueller wrote:
>>>> Am 11.11.21 um 17:00 schrieb olcott:
>>>>> #define ptr uintptr_t
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>>    ((void(*)(ptr))x)(y);
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    H((ptr)P, (ptr)P);
>>>>>    return 0;
>>>>> }
>>>>
>>>> Besides the fact that there is no good reason to write that type
>>>> unsafe code in C++ did you test it? The code will never compile
>>>> because of the forward reference to H.
>>>>
>>>> And well, H calls P and P calls H. What do you expect?
>>>>
>>>>
>>>> Marcel
>>>
>>> Yes the code does compile and I did test it.
>>> This is the pure C part of my halting theorem refutation. I wanted to
>>> get some C experts to weigh in on the the analysis of the C code.
>>>
>>> I won't be discussing anything besides the pure C aspects here
>>> because people here get upset.
>>>
>>
>> First, this CAN'T be the complete definition of the source file, as at
>> minimum it needs a #include <stdint.h> to get the definition of uintptr_t
>>
>> Second, if you are using a version of C that has uintptr_t defined,
>> (C99 or later) then the lack of a declaration for H in P is an error
>>
>> Only C90 and before allowed the calling of a function with no
>> declaration before it.
>>
>> It might 'compile', but if it does, it will include a manditory
>> diagnostic, and that means that if the compiler still produced an
>> output file, if you run that program, the behavior of that program is
>> BY DEFINITON of the Standard, Undefined.
>>
>> Thus, there ARE NO 'C aspects' of this 'program' as the C standard has
>> declared that it suppies NO definition of what it does.
>>
>> FAIL.
>
> I added this: #include <stdint.h>
>

But it still fails and will get a mandatory diagnostic, and the
execution is undefined. P can not use the symbol H without it being
prior declaired in any version of C that defines uintptr_t.

You either need the definition of H before the definition of P or you
need a forward decleration for the function H before the call.

C90 allowed this, which is why you may be just getting a warning, but
the actual meaning is that the C Standard has disavowed any definition
to the program.

And, all this shows is that for a H that just calls its input, you do
get an infinite recursion, but such an H never gives the answer about it.

Since the behavior of P depends on the behavior of H, if you change H to
be able to give an answer, you have changed the behavior of P so you
'proof' doesn't apply any more.

Show your level of skill as a junior programmer.

On 11/11/2021 1:38 PM, Richard Damon wrote:
> On 11/11/21 2:30 PM, olcott wrote:
>> On 11/11/2021 1:20 PM, Richard Damon wrote:
>>> On 11/11/21 1:52 PM, olcott wrote:
>>>> On 11/11/2021 12:01 PM, Marcel Mueller wrote:
>>>>> Am 11.11.21 um 17:00 schrieb olcott:
>>>>>> #define ptr uintptr_t
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    H(x, x);
>>>>>> }
>>>>>>
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    ((void(*)(ptr))x)(y);
>>>>>>    return 1;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    H((ptr)P, (ptr)P);
>>>>>>    return 0;
>>>>>> }
>>>>>
>>>>> Besides the fact that there is no good reason to write that type
>>>>> unsafe code in C++ did you test it? The code will never compile
>>>>> because of the forward reference to H.
>>>>>
>>>>> And well, H calls P and P calls H. What do you expect?
>>>>>
>>>>>
>>>>> Marcel
>>>>
>>>> Yes the code does compile and I did test it.
>>>> This is the pure C part of my halting theorem refutation. I wanted
>>>> to get some C experts to weigh in on the the analysis of the C code.
>>>>
>>>> I won't be discussing anything besides the pure C aspects here
>>>> because people here get upset.
>>>>
>>>
>>> First, this CAN'T be the complete definition of the source file, as
>>> at minimum it needs a #include <stdint.h> to get the definition of
>>> uintptr_t
>>>
>>> Second, if you are using a version of C that has uintptr_t defined,
>>> (C99 or later) then the lack of a declaration for H in P is an error
>>>
>>> Only C90 and before allowed the calling of a function with no
>>> declaration before it.
>>>
>>> It might 'compile', but if it does, it will include a manditory
>>> diagnostic, and that means that if the compiler still produced an
>>> output file, if you run that program, the behavior of that program is
>>> BY DEFINITON of the Standard, Undefined.
>>>
>>> Thus, there ARE NO 'C aspects' of this 'program' as the C standard
>>> has declared that it suppies NO definition of what it does.
>>>
>>> FAIL.
>>
>> I added this: #include <stdint.h>
>>
>
> But it still fails and will get a mandatory diagnostic, and the
> execution is undefined. P can not use the symbol H without it being
> prior declaired in any version of C that defines uintptr_t.
>
> You either need the definition of H before the definition of P or you
> need a forward decleration for the function H before the call.
>

#include <stdint.h>
#define ptr uintptr_t

int H(ptr x, ptr y)
{ ((void(*)(ptr))x)(y);
return 1;
}

void P(ptr x)
{ H(x, x);
}

int main()
{ H((ptr)P, (ptr)P);
return 0;
}

I embedded the above in a whole other program so these "errors"
were corrected in code that I did not know about.

> C90 allowed this, which is why you may be just getting a warning, but
> the actual meaning is that the C Standard has disavowed any definition
> to the program.
>
> And, all this shows is that for a H that just calls its input, you do
> get an infinite recursion, but such an H never gives the answer about it.
>
> Since the behavior of P depends on the behavior of H, if you change H to
> be able to give an answer, you have changed the behavior of P so you
> 'proof' doesn't apply any more.
>
> Show your level of skill as a junior programmer.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/21 2:59 PM, olcott wrote:
>
>
> I embedded the above in a whole other program so these "errors"
> were corrected in code that I did not know about.

In other words, you don't know how to do a controlled experiment so we
really need to deman FULL disclosure of exactly what you are doing
before we can accept any 'experimental' evidence.

You are writing your obituary here.

On 11/11/2021 2:11 PM, Richard Damon wrote:
>
> On 11/11/21 2:59 PM, olcott wrote:
>>
>>
>> I embedded the above in a whole other program so these "errors"
>> were corrected in code that I did not know about.
>
> In other words, you don't know how to do a controlled experiment so we
> really need to deman FULL disclosure of exactly what you are doing
> before we can accept any 'experimental' evidence.
>
> You are writing your obituary here.

Don't say that. I have terminal cancer in its advanced stages.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Jeff Barnett <jbb@notatt.com> writes:

> On 11/11/2021 11:01 AM, Marcel Mueller wrote:

>> The code will never compile because of the forward reference to H.
>> And well, H calls P and P calls H. What do you expect?

> However many programing languages allow 'mutual recursion" and it's
> very useful.

Just in case there is any confusion, both C and C++ allow mutual
recursion.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> #include <stdint.h>
> #define ptr uintptr_t
>
> int H(ptr x, ptr y)
> {
> ((void(*)(ptr))x)(y);
> return 1;
> }
>
> void P(ptr x)
> {
> H(x, x);
> }
>
> int main()
> {
> H((ptr)P, (ptr)P);
> return 0;
> }

It's clearer without all the casts:

#include <stdint.h>

typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y);
return 1;
}

void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

--
Ben.

On 11/11/2021 2:31 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> #include <stdint.h>
>> #define ptr uintptr_t
>>
>> int H(ptr x, ptr y)
>> {
>> ((void(*)(ptr))x)(y);
>> return 1;
>> }
>>
>> void P(ptr x)
>> {
>> H(x, x);
>> }
>>
>> int main()
>> {
>> H((ptr)P, (ptr)P);
>> return 0;
>> }
>
> It's clearer without all the casts:
>
> #include <stdint.h>
>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
> x(y);
> return 1;
> }
>
> void P(ptr x)
> {
> H(x, x);
> }
>
> int main(void)
> {
> H(P, P);
> }
>

Brilliant !!!

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/2021 12:26 PM, olcott wrote:
> On 11/11/2021 1:06 PM, Jeff Barnett wrote:

<SNIP>

>> I expect that PO (the OP) is nuts and lonesome. This crap is just
>> another bid for attention and companionship, no matter the quality of
>> the interaction.
>>
>
> (Attacking the person): This fallacy occurs when, instead of addressing
> someone's argument or position, you irrelevantly attack the person or
> some aspect of the person who is making the argument.

I was not attacking your argument; I was attacking you as a demonstrable
idiot. Therefore this was/is not an example of Ad Hominem argument. You
are nuts, you are lonesome, you are making a bid for attention, and the
quality of the interaction, no matter how negative, is what you grave.
All facts. Find a qualified mental health professional, show them your
posts - any half dozen or so will do - and ask for an evaluation. I bet
they wont let you leave the office without a lifetime prescription for
"happy" pills.

Most of my message was to Mueller about relative approaches to mutual
recursion in different languages. In fact what I said, technically,
might have been a slight defense of your abysmal code. There is no straw
man here unless it was you with straw in your head for brains. You
really should read and understand before criticizing.

I haven't ask you this for a long time but I think it is appropriate
now: Are you typing with one hand in your pants, playing with yourself?
Your not very good at multitasking; so one thing at a time. Go slow,
very slow else you will out run your brain.
--
Jeff Barnett

On 11/11/2021 1:06 PM, Jeff Barnett wrote:
> On 11/11/2021 11:01 AM, Marcel Mueller wrote:
>> Am 11.11.21 um 17:00 schrieb olcott:
>>> #define ptr uintptr_t
>>>
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    ((void(*)(ptr))x)(y);
>>>    return 1;
>>> }
>>>
>>> int main()
>>> {
>>>    H((ptr)P, (ptr)P);
>>>    return 0;
>>> }
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
> I expect that PO (the OP) is nuts and lonesome.

> This crap is just

A conclusion was formed about the quality of my work and the only basis
provided for this conclusion was the personal attack that preceded it.

> another bid for attention and companionship, no matter the quality of
> the interaction.
>
> However many programing languages allow 'mutual recursion" and it's very
> useful. Common LISP, for example, has two different forms for lexically
> binding functions. One makes the bound functions only visible within the
> body of the binding form; the other makes these functions visible in the
> bodies of the bound functions themselves as well as the body of the
> binding form. Further, the batch compilers do not output "missing
> function definition" warnings or errors until the entire batch has been
> compiled. Together these features allow incremental development and
> debugging as well as mutual recursion.
>
> And as an aside, I think that Common LISP has at least as flexible and
> powerful an object system as does any of the C variants.

This is an example of the strawman error in that the concrete code that
I precisely specified never halts because of infinite recursion.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/2021 3:55 PM, Jeff Barnett wrote:
> On 11/11/2021 12:26 PM, olcott wrote:
>> On 11/11/2021 1:06 PM, Jeff Barnett wrote:
>
> <SNIP>
>
>>> I expect that PO (the OP) is nuts and lonesome. This crap is just
>>> another bid for attention and companionship, no matter the quality of
>>> the interaction.
>>>
>>
>> (Attacking the person): This fallacy occurs when, instead of
>> addressing someone's argument or position, you irrelevantly attack the
>> person or some aspect of the person who is making the argument.
>
> I was not attacking your argument; I was attacking you as a demonstrable
> idiot. Therefore this was/is not an example of Ad Hominem argument. You

On 11/11/2021 1:06 PM, Jeff Barnett wrote:
> I expect that PO (the OP) is nuts and lonesome.

> This crap is just

a conclusion about the quality of my work that only has the personal
attack that precedes it as its basis.

> another bid for attention and companionship, no matter the quality of
> the interaction.

> are nuts, you are lonesome, you are making a bid for attention, and the
> quality of the interaction, no matter how negative, is what you grave.
> All facts. Find a qualified mental health professional, show them your
> posts - any half dozen or so will do - and ask for an evaluation. I bet
> they wont let you leave the office without a lifetime prescription for
> "happy" pills.
>
> Most of my message was to Mueller about relative approaches to mutual
> recursion in different languages. In fact what I said, technically,
> might have been a slight defense of your abysmal code. There is no straw
> man here unless it was you with straw in your head for brains. You
> really should read and understand before criticizing.
>
> I haven't ask you this for a long time but I think it is appropriate
> now: Are you typing with one hand in your pants, playing with yourself?
> Your not very good at multitasking; so one thing at a time. Go slow,
> very slow else you will out run your brain.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Marcel Mueller <news.5.maazl@spamgourmet.org> writes:
>
> Besides the fact that there is no good reason to write that type
> unsafe code in C++ did you test it? The code will never compile
> because of the forward reference to H.
>
> And well, H calls P and P calls H. What do you expect?

He's imagining he can solve the Halting Problem if he uses the x86
instruction set instead of a Turing Machine. Many people have tried to
explain the flaws in his argument; he doesn't listen. There is nothing
to do but killfile him.

On 11/11/2021 6:47 PM, Joe Pfeiffer wrote:
> Marcel Mueller <news.5.maazl@spamgourmet.org> writes:
>>
>> Besides the fact that there is no good reason to write that type
>> unsafe code in C++ did you test it? The code will never compile
>> because of the forward reference to H.
>>
>> And well, H calls P and P calls H. What do you expect?
>
> He's imagining he can solve the Halting Problem if he uses the x86
> instruction set instead of a Turing Machine. Many people have tried to
> explain the flaws in his argument; he doesn't listen. There is nothing
> to do but killfile him.
>

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

Arthur Schopenhauer

People that cannot see the target are unqualified to judge hits from
misses.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/11/2021 2:31 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> #include <stdint.h>
>> #define ptr uintptr_t
>>
>> int H(ptr x, ptr y)
>> {
>> ((void(*)(ptr))x)(y);
>> return 1;
>> }
>>
>> void P(ptr x)
>> {
>> H(x, x);
>> }
>>
>> int main()
>> {
>> H((ptr)P, (ptr)P);
>> return 0;
>> }
>
> It's clearer without all the casts:
>
> #include <stdint.h>
>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
> x(y);
> return 1;
> }
>
> void P(ptr x)
> {
> H(x, x);
> }
>
> int main(void)
> {
> H(P, P);
> }
>

That is much cleaner syntax than mine.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 11/13/2021 12:24 PM, Tim Rentsch wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>
> [..wanting to solve the halting problem..]
>
>> You do understand that if the halting problem were solvable, and
>> someone solved it,

Because I didn't see these last three words my reply was incorrect.

I am not trying to solve the halting problem merely show how this
simplest possible equivalent to the halting theorem counter-examples can
have its halt status correctly decided by H.

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

H simulates its input and as soon as its input calls H with the same
parameters that H was called with H aborts this simulation and returns 0
for not halting, infinite recursion detected. It took me 16,000 hours
since 2004 to get it this simple.

> it would be the Holy Grail of mathematics?
>> Pretty much every single unsolved mathematical hypothesis that can
>> be expressed as a computer program could be solved just like that.
>> [...] The Collatz conjecture? Solved. [...]
>
> Can you explain what program would serve to provide a solution to
> the Collatz conjecture?
>

--
Copyright 2021 Pete Olcott

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

On 11/14/2021 9:58 AM, David Brown wrote:
> On 14/11/2021 15:09, wij wrote:
>> On Sunday, 14 November 2021 at 18:31:39 UTC+8, Keith Thompson wrote:
>>> wij <wyn...@gmail.com> writes:
>>>> On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:
>>> [...]
>>>>> Basic truth: No one can duplicate your 'experiment'.
>>>>
>>>> Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar
>>> Which is why most of us don't read anything he posts in comp.lang.c++
>>> and are not interested in seeing replies here.
>>
>> Is it? As I knew, not so.
>> I used to see Mr Flibble in comp.c++. He posted "Halting problem as defined is
>> erroneous" in comp.theory, which made me worry about C++ people.
>>
>
> Mr. Flibble does not speak for "C++ people". In fact, Mr. Flibble often
> does not speak for himself, but posts things just to provoke a reaction.
> I don't really know what he means by his comments on the halting
> problem, but they are certainly not C++ related - I'm sure if he
> actually wants to discuss it, then comp.theory is a better place.
>
>>> Post in comp.theory if you want to engage with him.
>>>
>>
>> Anyone is of the same right posting message on any google forum one think
>> appropriate, is that correct? Has olcott the right? I think so. Do you?
>> That said, I don't really enjoy engaging with olcott, he is sometimes very cunny.
>>
>
> Usenet is a bastion of free speech - there is no sensor of who posts
> here, or what they post. Yes, Olcott has the right to post anything
> here. Equally, people who would prefer that a C++ newsgroup is for C++
> topics have the right to ask others to refrain from off-topic posting or
> encouraging impolite and disruptive posters.
>
> Olcott is delusional. He is not the first, nor the last, to believe
> that he has found a proof or counter-proof that contradicts a long
> established mathematical theorem. Like all such people, rational
> arguments bounce off him with no effect, except perhaps to strengthen
> his resolve. Replying to and encouraging him does not help anyone - not
> him, nor anyone else interested in computational theory, nor other
> people frequenting these newsgroups. There is a famous essay "beware
> the trisectors" that can be found on the net, which covers the
> difficulties in dealing with those like Olcott.
>
> Despite using a limited subset of C and C++ as his programming language
> (rather than more traditional choices such as Turing machines), Olcott's
> posts are not remote topical here - just as they are not topical in a
> newsgroup for English Literature despite being written in English.
>
> Olcott is never going to listen to anyone else's advice or suggestions,
> including the suggestion to take his ramblings elsewhere. But perhaps
> you might.
>

I stripped off everything not directly pertaining to the correct
analysis of C code.

The only thing that I post here requires technical competence in the C
programming language and nothing more.

People in the comp.theory forum lack sufficient technical competence in
the C programming language.

#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

It is obvious that whether or not the above code is directly executed or
H performs a pure simulation of its input that the above code specifies
infinite recursion. Everyone here knows this.

The only other step is confirming that the simulated or executed P never
reaches its final state of 00001a72 even when its execution or
simulation has been aborted at some point.

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

--
Copyright 2021 Pete Olcott

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