#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/21 11:00 AM, olcott wrote:
> #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;
> }
>

Yes.

So all you have proven is that if H unconditionally executes its input
you get infinite recursion.

And, H will never return.

If H isn't that function, then the computation of P changes so you have
no proof for what the behavior of that machine is.

This is just more of your POOP talk.

On 11/11/2021 10:14 AM, Richard Damon wrote:
> On 11/11/21 11:00 AM, olcott wrote:
>> #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;
>> }
>>
>
> Yes.
>
> So all you have proven is that if H unconditionally executes its input
> you get infinite recursion.
>
> And, H will never return.
>
> If H isn't that function, then the computation of P changes so you have
> no proof for what the behavior of that machine is.
>

_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]

If H simulates the x86 machine language of its input and sees that its
simulated P is calling H with the same parameters that H was called with
H can abort its simulation of P and correctly report that P would never
reach its final state at 1a72.

--
Copyright 2021 Pete Olcott

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

On 11/11/2021 10:14 AM, Richard Damon wrote:
> On 11/11/21 11:00 AM, olcott wrote:
>> #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;
>> }
>>
>
> Yes.
>
> So all you have proven is that if H unconditionally executes its input
> you get infinite recursion.
>
> And, H will never return.
>
> If H isn't that function, then the computation of P changes so you have
> no proof for what the behavior of that machine is.

_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]

If H simulates the x86 machine language of its input and sees that its
simulated P is calling H with the same parameters that H was called with
H can abort its simulation of P and correctly report that P would never
reach its final state at 1a72.

--
Copyright 2021 Pete Olcott "Great spirits have always encountered
violent opposition from mediocre minds." Einstein

On 11/11/21 11:31 AM, olcott wrote:
> On 11/11/2021 10:14 AM, Richard Damon wrote:
>> On 11/11/21 11:00 AM, olcott wrote:
>>> #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;
>>> }
>>>
>>
>> Yes.
>>
>> So all you have proven is that if H unconditionally executes its input
>> you get infinite recursion.
>>
>> And, H will never return.
>>
>> If H isn't that function, then the computation of P changes so you
>> have no proof for what the behavior of that machine is.
>>
>
> _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]
>
>
> If H simulates the x86 machine language of its input and sees that its
> simulated P is calling H with the same parameters that H was called with
> H can abort its simulation of P and correctly report that P would never
> reach its final state at 1a72.
>
>

No it can't.

If H can abort its simulation, then it needs to take into account that H
can abort its simulation. PERIOD.

H, in making that conclusion, is PRESUMING that the called H will not
abort its simulation, which it is wrong about.

Youy are basing your argument on LIES, thus you are a LIAR.

You need to decide which behavior H has.

1) Does it abort its simulation and return 0 in this case, in which case
when H sees the call to H here it needs to assume that H will return the
value 0. Of course then when it continues to follow the path after the
call, it sees that H stops, but it has already committed itsself to
returning 0, so it can figure out that it will be wrong.

2) Does in NEVER abort its simulation, in which case it isn't allowed to
abort its simulation, and thus even though it can see that Pn(Pn) will
be non-halting, it has no way to return that result without breaking its
assumptions.

3) A path you aren't following is it could presume that H(P,P) returns
1, and then continue the trace following that premise, and see that
P1(P1) goes into an infinite loop, so it knows that when it gives the
Halting answer it will be wrong.

Thus H might be able to correctly determine the right answer to the
problem, but only by commiting itself to returning the wrong answer and
thus knowing it has failed.

In all cases, the outside observer, looking at the answer the H
provides, which is the only answer that really matters, and comparing it
to the acutal behavior of the machine provided in the input, will see
that H is always wrong.

FAIL

On 11/11/21 11:38 AM, olcott wrote:
> On 11/11/2021 10:14 AM, Richard Damon wrote:
>> On 11/11/21 11:00 AM, olcott wrote:
>>> #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;
>>> }
>>>
>>
>> Yes.
>>
>> So all you have proven is that if H unconditionally executes its input
>> you get infinite recursion.
>>
>> And, H will never return.
>>
>> If H isn't that function, then the computation of P changes so you
>> have no proof for what the behavior of that machine is.
>
>
> _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]
>
>
> If H simulates the x86 machine language of its input and sees that its
> simulated P is calling H with the same parameters that H was called with
> H can abort its simulation of P and correctly report that P would never
> reach its final state at 1a72.
>

FALSE.

See other response.

You are just talking about POOP here.

On 11/11/2021 10:46 AM, Richard Damon wrote:
> On 11/11/21 11:31 AM, olcott wrote:
>> On 11/11/2021 10:14 AM, Richard Damon wrote:
>>> On 11/11/21 11:00 AM, olcott wrote:
>>>> #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;
>>>> }
>>>>
>>>
>>> Yes.
>>>
>>> So all you have proven is that if H unconditionally executes its
>>> input you get infinite recursion.
>>>
>>> And, H will never return.
>>>
>>> If H isn't that function, then the computation of P changes so you
>>> have no proof for what the behavior of that machine is.
>>>
>>
>> _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]
>>
>>
>> If H simulates the x86 machine language of its input and sees that its
>> simulated P is calling H with the same parameters that H was called
>> with H can abort its simulation of P and correctly report that P would
>> never reach its final state at 1a72.
>>
>>
>
> No it can't.
>
> If H can abort its simulation, then it needs to take into account that H
> can abort its simulation. PERIOD.
>
> H, in making that conclusion, is PRESUMING that the called H will not
> abort its simulation, which it is wrong about.

Because I keep repeating these same words dozens of times and you never
acknowledge that you have ever seen them I really believe that you
actually have attention deficit disorder (ADD):

(a) P only halts if it reaches its final state at 1a72.

(b) If H does not abort its simulation of P then P never reaches its
final state at 1a72.

(c) If H aborts its simulation of P then P never reaches its final state
as 1a72.

Because P never halts in all possible cases H(P,P)==0 is always correct.

--
Copyright 2021 Pete Olcott

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

On 11/11/21 12:14 PM, olcott wrote:
> On 11/11/2021 10:46 AM, Richard Damon wrote:
>> On 11/11/21 11:31 AM, olcott wrote:
>>> On 11/11/2021 10:14 AM, Richard Damon wrote:
>>>> On 11/11/21 11:00 AM, olcott wrote:
>>>>> #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;
>>>>> }
>>>>>
>>>>
>>>> Yes.
>>>>
>>>> So all you have proven is that if H unconditionally executes its
>>>> input you get infinite recursion.
>>>>
>>>> And, H will never return.
>>>>
>>>> If H isn't that function, then the computation of P changes so you
>>>> have no proof for what the behavior of that machine is.
>>>>
>>>
>>> _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]
>>>
>>>
>>> If H simulates the x86 machine language of its input and sees that
>>> its simulated P is calling H with the same parameters that H was
>>> called with H can abort its simulation of P and correctly report that
>>> P would never reach its final state at 1a72.
>>>
>>>
>>
>> No it can't.
>>
>> If H can abort its simulation, then it needs to take into account that
>> H can abort its simulation. PERIOD.
>>
>> H, in making that conclusion, is PRESUMING that the called H will not
>> abort its simulation, which it is wrong about.
>
> Because I keep repeating these same words dozens of times and you never
> acknowledge that you have ever seen them I really believe that you
> actually have attention deficit disorder (ADD):
>
> (a) P only halts if it reaches its final state at 1a72.
>
> (b) If H does not abort its simulation of P then P never reaches its
> final state at 1a72.
>
> (c) If H aborts its simulation of P then P never reaches its final state
> as 1a72.
>
> Because P never halts in all possible cases H(P,P)==0 is always correct.
>
>

So, which H is H?

For B, yes Pb(Pb) doesn't halt, but Hb(Pb,Pb) doesn't answer, so it
wasn't right.

For C, We do have the Hc(Pc,Pc) return 0, but we also have that if we
actually run Pc(Pc) then the actual execution trace of Pc when run as an
independent machine, or simulated by a REAL pure simulator will call H
at 1A69, and then that H WILL return 0, and Pc will reach the final
return at 1a72 and halt.

You make the mistake that in assuming that the aborted simulation that H
did means anything,

Read the ACTUAL definition of the problem, does the machine represented
by the input halt, not does the simulation done by H reach the final
state of the machine it is simulating. All you have shown is that H
can't prove that its input is halting, so it makes the WRONG choice in
assuming it is not.

AGAIN, you make the error of not definie which H you are talking about
so not only are you WRONG, but you are DOUBLELY WRONG.

Maybe even Triple wrong as you not only haven't proven what you claim,
you show that you don't understand what Halting really is or even how to
make a proof.

FAIL.

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

On 11/11/21 3:16 PM, olcott wrote:
> 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.
>

Right, so you should be trying to do something meaningfull.

If the last decades of your life we just filled with non-sense, that is
what you will be remembered for.

You actions ARE LITERALLY writing your real obituary. Maybe not the one
that is publisned in the paper, as that tends to get whitewashed as not
talk about the foibles of the individual, but the obituary in the minds
of those that know you will be filled with what you actually did.

You don't seem to be able to see who you really are. You seem to have
lost you sense of what is really true, and what is important.

Face it, you don't have the background to even attempt the proof you are
trying to do, as I have mentioned before, if you real basis is that you
disagree with the fundamental logic uses in mathematics, then you can't
start at late stage proofs that prove things you find inconvenient,
because to talk about those you actually DO need to accept the logic
system they were built on. You can't say that it was ok to use the
standard logics to get you to that point, but not any farther.

You seem to not understand that there HAVE been a number of great minds
working on Maths with different base logics to try and avoid some of the
results that you don't like (things like there being unprovable truths).
All that has been found is that none of these can express the fullness
that the mathematics you want to change can express.

If you really think you can do better than those people, go ahead, but
that means starting at the bottom and working up. And, those people
spent a life time working on these things, and it sounds like you don't
have much time.

Take you last days and do something PRODUCTIVE, something that you can
actually DO (something that others say you can do) and end on a positive
note, not as the crazy man who doesn't understand what he has been
talking about.

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

> 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

I am sorry to learn about this. I am assuming that what you are saying is true. I hope you will find it encouraging to hear: the theory of everything I've been working will be very likely, assuming it is one day published or used in the right ways, to facilitate the technology to bring all people who have ever died back to life.

Best wishes,
Philip White

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

On Thursday, November 11, 2021 at 12:16:42 PM UTC-8, olcott wrote:

> ... I have terminal cancer in its advanced stages.

I hope that doesn't mean exactly what it says. If it does I am sorry
to hear it. Have as decent health as possible for as long as possible.