Flibble> Does this C program halt?

bool program_halts(void(*p)(void*), void* i)
{ // this function is a halt decider that returns @true if p(i) halts
}

bool h(void(*p)(void*), void* i)
{ return program_halts(p, i);
}

void p(void* i)
{ if (h(p, i))
here: goto here;
}

int main()
{ h(p, (void*)42);
}

ChatGPT> This C program contains a circular reference between the
functions p and h, which means that it is not possible to determine
whether it will halt or not.

The h function calls the program_halts function with p as its first
argument and i as its second argument. The program_halts function then
calls the p function with i as its argument. The p function then calls the
h function with itself as the first argument and i as the second argument.
This creates a circular reference between the two functions, and they will
continue to call each other indefinitely.

Since this program contains an infinite loop, it will not halt.

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> Flibble> Does this C program halt?

> bool program_halts(void(*p)(void*), void* i)
> {
> // this function is a halt decider that returns @true if p(i) halts
> }
>
> bool h(void(*p)(void*), void* i)
> {
> return program_halts(p, i);
> }
>
> void p(void* i)
> {
> if (h(p, i))
> here: goto here;
> }
>
> int main()
> {
> h(p, (void*)42);
> }

> Since this program contains an infinite loop, it will not halt.

If program_halts is, as the comment suggests, a decider, then the call
to h in main always returns. You probably meant that program_halts is
not a decider but just a function that does not always give an answer.

--
Ben.

On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:

> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> Flibble> Does this C program halt?
>
>> bool program_halts(void(*p)(void*), void* i)
>> {
>> // this function is a halt decider that returns @true if p(i) halts
>> }
>>
>> bool h(void(*p)(void*), void* i)
>> {
>> return program_halts(p, i);
>> }
>>
>> void p(void* i)
>> {
>> if (h(p, i))
>> here: goto here;
>> }
>>
>> int main()
>> {
>> h(p, (void*)42);
>> }
>
>> Since this program contains an infinite loop, it will not halt.
>
> If program_halts is, as the comment suggests, a decider, then the call
> to h in main always returns. You probably meant that program_halts is
> not a decider but just a function that does not always give an answer.

I meant exactly what i meant, nothing more, nothing less.

I am sure you are well aware that when you include an edited version of
what you are replying to in your reply it is just common fucking curtosy
to indicate the edits: your reply made it look like I said "Since this
program contains an infinite loop, it will not halt." rather than ChatGPT.

/Flibble

On 1/1/23 4:08 PM, Mr Flibble wrote:
> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>>> Flibble> Does this C program halt?
>>
>>> bool program_halts(void(*p)(void*), void* i)
>>> {
>>> // this function is a halt decider that returns @true if p(i) halts
>>> }
>>>
>>> bool h(void(*p)(void*), void* i)
>>> {
>>> return program_halts(p, i);
>>> }
>>>
>>> void p(void* i)
>>> {
>>> if (h(p, i))
>>> here: goto here;
>>> }
>>>
>>> int main()
>>> {
>>> h(p, (void*)42);
>>> }
>>
>>> Since this program contains an infinite loop, it will not halt.
>>
>> If program_halts is, as the comment suggests, a decider, then the call
>> to h in main always returns. You probably meant that program_halts is
>> not a decider but just a function that does not always give an answer.
>
> I meant exactly what i meant, nothing more, nothing less.
>
> I am sure you are well aware that when you include an edited version of
> what you are replying to in your reply it is just common fucking curtosy
> to indicate the edits: your reply made it look like I said "Since this
> program contains an infinite loop, it will not halt." rather than ChatGPT.
>
> /Flibble

The problem is that program_halts is just buggy, because it doesn't
match its documentation.

Just putting a comment in a function to say it should be a Halt Decider,
doesn't make it one.

You could try entering all of PO's Halt Decider as the code, and if the
system is smart enough, it will be able to tell you that main will halt,
and if you ask the right other questions that h is saying its input will
not halt but the program that is that input will halt (because h says it
won't),

Of course, PO thinks that the program given as an input isn't an input
to the decider, which means his halt decider isn't answering the
question that it is supposed to anyway.

On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:

> On 1/1/23 4:08 PM, Mr Flibble wrote:
>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>
>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>
>>>> Flibble> Does this C program halt?
>>>
>>>> bool program_halts(void(*p)(void*), void* i)
>>>> {
>>>> // this function is a halt decider that returns @true if p(i)
>>>> halts
>>>> }
>>>>
>>>> bool h(void(*p)(void*), void* i)
>>>> {
>>>> return program_halts(p, i);
>>>> }
>>>>
>>>> void p(void* i)
>>>> {
>>>> if (h(p, i))
>>>> here: goto here;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> h(p, (void*)42);
>>>> }
>>>
>>>> Since this program contains an infinite loop, it will not halt.
>>>
>>> If program_halts is, as the comment suggests, a decider, then the call
>>> to h in main always returns. You probably meant that program_halts is
>>> not a decider but just a function that does not always give an answer.
>>
>> I meant exactly what i meant, nothing more, nothing less.
>>
>> I am sure you are well aware that when you include an edited version of
>> what you are replying to in your reply it is just common fucking
>> curtosy to indicate the edits: your reply made it look like I said
>> "Since this program contains an infinite loop, it will not halt."
>> rather than ChatGPT.
>>
>> /Flibble
>
> The problem is that program_halts is just buggy, because it doesn't
> match its documentation.

How fucking stupid are you? This was input to an AI and amazingly the AI
was more clever than you in being able to workout that the comment was in
lieu of a working implementation. It is official: you are not as clever as
the ChatGPT AI which achieved an IQ score of 85. Amazing. This explains
why you cannot stop arguing with the pervert: you have a lower IQ than him.

/Flibble

On 1/1/23 4:57 PM, Mr Flibble wrote:
> On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:
>
>> On 1/1/23 4:08 PM, Mr Flibble wrote:
>>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>>
>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>>
>>>>> Flibble> Does this C program halt?
>>>>
>>>>> bool program_halts(void(*p)(void*), void* i)
>>>>> {
>>>>> // this function is a halt decider that returns @true if p(i)
>>>>> halts
>>>>> }
>>>>>
>>>>> bool h(void(*p)(void*), void* i)
>>>>> {
>>>>> return program_halts(p, i);
>>>>> }
>>>>>
>>>>> void p(void* i)
>>>>> {
>>>>> if (h(p, i))
>>>>> here: goto here;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> h(p, (void*)42);
>>>>> }
>>>>
>>>>> Since this program contains an infinite loop, it will not halt.
>>>>
>>>> If program_halts is, as the comment suggests, a decider, then the call
>>>> to h in main always returns. You probably meant that program_halts is
>>>> not a decider but just a function that does not always give an answer.
>>>
>>> I meant exactly what i meant, nothing more, nothing less.
>>>
>>> I am sure you are well aware that when you include an edited version of
>>> what you are replying to in your reply it is just common fucking
>>> curtosy to indicate the edits: your reply made it look like I said
>>> "Since this program contains an infinite loop, it will not halt."
>>> rather than ChatGPT.
>>>
>>> /Flibble
>>
>> The problem is that program_halts is just buggy, because it doesn't
>> match its documentation.
>
> How fucking stupid are you? This was input to an AI and amazingly the AI
> was more clever than you in being able to workout that the comment was in
> lieu of a working implementation. It is official: you are not as clever as
> the ChatGPT AI which achieved an IQ score of 85. Amazing. This explains
> why you cannot stop arguing with the pervert: you have a lower IQ than him.
>
> /Flibble

My last rated IQ score what 185.

Read the results of ChatAI.

First, it is unclear where the ChatAI results end and your comentary
begins,

In the first paragraph, which I presume is from ChatAI, it says the
answer is indeterminate by it. That is a reasonable answer. It gives a
reasonable reason why the program is beyond its ability.

The following two paragraphs seem to be a commentary extrapolation
making an error, as it says that program_halts calls the function p,
when there is actually no such code in the function (or even implied by
the comment, halt deciders do not need to, and in fact can't, just run
their inputs).

I do not belive that the last two paragraphs to be from Chat AI, or it
is signs that it has serious problems (not out of the question), as I
would not expect it to so directly contradict itself in a single answer.

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:
>
>> On 1/1/23 4:08 PM, Mr Flibble wrote:
>>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>>
>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>>
>>>>> Flibble> Does this C program halt?
>>>>
>>>>> bool program_halts(void(*p)(void*), void* i)
>>>>> {
>>>>> // this function is a halt decider that returns @true if p(i)
>>>>> halts
>>>>> }
>>>>>
>>>>> bool h(void(*p)(void*), void* i)
>>>>> {
>>>>> return program_halts(p, i);
>>>>> }
>>>>>
>>>>> void p(void* i)
>>>>> {
>>>>> if (h(p, i))
>>>>> here: goto here;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> h(p, (void*)42);
>>>>> }
<cut>
>>>>> Since this program contains an infinite loop, it will not halt.
>>>>
>>>> If program_halts is, as the comment suggests, a decider, then the call
>>>> to h in main always returns. You probably meant that program_halts is
>>>> not a decider but just a function that does not always give an answer.
<cut>
(I've indicated my edits. I don't usually bother when replying to
cranks.)

>> The problem is that program_halts is just buggy, because it doesn't
>> match its documentation.
>
> How fucking stupid are you? This was input to an AI and amazingly the AI
> was more clever than you in being able to workout that the comment was in
> lieu of a working implementation.

There are no implementations of the program_halts function that match
the comment:

// this function is a halt decider that returns @true if p(i) halts

because there are no halt deciders. Did the chat bot not spot that
error? Did it assume that a function can be implemented because it can
be described in English?

A human can interpret the bogus comments and decide which part to
ignore. For example, any function that implements

// this function is a decider that returns @true if p(i) halts

makes the answer to your question yes (as I said before).

Does the chat bot tell you that this program

bool are_these_next_weeks_lottery_numbers(int n[6]) {
// a decider that returns true iff n contains next Saturday's
// lottery numbers.
}

will make you rich?

--
Ben.

On Sun, 01 Jan 2023 17:10:11 -0500, Richard Damon wrote:

> On 1/1/23 4:57 PM, Mr Flibble wrote:
>> On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:
>>
>>> On 1/1/23 4:08 PM, Mr Flibble wrote:
>>>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>>>
>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>>>
>>>>>> Flibble> Does this C program halt?
>>>>>
>>>>>> bool program_halts(void(*p)(void*), void* i)
>>>>>> {
>>>>>> // this function is a halt decider that returns @true if p(i)
>>>>>> halts
>>>>>> }
>>>>>>
>>>>>> bool h(void(*p)(void*), void* i)
>>>>>> {
>>>>>> return program_halts(p, i);
>>>>>> }
>>>>>>
>>>>>> void p(void* i)
>>>>>> {
>>>>>> if (h(p, i))
>>>>>> here: goto here;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> h(p, (void*)42);
>>>>>> }
>>>>>
>>>>>> Since this program contains an infinite loop, it will not halt.
>>>>>
>>>>> If program_halts is, as the comment suggests, a decider, then the
>>>>> call to h in main always returns. You probably meant that
>>>>> program_halts is not a decider but just a function that does not
>>>>> always give an answer.
>>>>
>>>> I meant exactly what i meant, nothing more, nothing less.
>>>>
>>>> I am sure you are well aware that when you include an edited version
>>>> of what you are replying to in your reply it is just common fucking
>>>> curtosy to indicate the edits: your reply made it look like I said
>>>> "Since this program contains an infinite loop, it will not halt."
>>>> rather than ChatGPT.
>>>>
>>>> /Flibble
>>>
>>> The problem is that program_halts is just buggy, because it doesn't
>>> match its documentation.
>>
>> How fucking stupid are you? This was input to an AI and amazingly the
>> AI was more clever than you in being able to workout that the comment
>> was in lieu of a working implementation. It is official: you are not as
>> clever as the ChatGPT AI which achieved an IQ score of 85. Amazing.
>> This explains why you cannot stop arguing with the pervert: you have a
>> lower IQ than him.
>>
>> /Flibble
>
>
> My last rated IQ score what 185.
>
> Read the results of ChatAI.
>
> First, it is unclear where the ChatAI results end and your comentary
> begins,
>
> In the first paragraph, which I presume is from ChatAI, it says the
> answer is indeterminate by it. That is a reasonable answer. It gives a
> reasonable reason why the program is beyond its ability.
>
>
> The following two paragraphs seem to be a commentary extrapolation
> making an error, as it says that program_halts calls the function p,
> when there is actually no such code in the function (or even implied by
> the comment, halt deciders do not need to, and in fact can't, just run
> their inputs).
>
> I do not belive that the last two paragraphs to be from Chat AI, or it
> is signs that it has serious problems (not out of the question), as I
> would not expect it to so directly contradict itself in a single answer.

An IQ of 185 and yet you were unable to discern which paragraphs were from
me and which were from the AI: all three paragraphs were from the AI;
there was no commentary from me.

An IQ of 185? LOL. You are quite possibly the first human being to fail
the Turing Test, mate.

Proof that all three paragraphs were from ChatGPT:

https://twitter.com/i42Software/status/1609626194273525760

/Flibble

On Sun, 01 Jan 2023 22:31:02 +0000, Ben Bacarisse wrote:

> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:
>>
>>> On 1/1/23 4:08 PM, Mr Flibble wrote:
>>>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>>>
>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>>>
>>>>>> Flibble> Does this C program halt?
>>>>>
>>>>>> bool program_halts(void(*p)(void*), void* i)
>>>>>> {
>>>>>> // this function is a halt decider that returns @true if p(i)
>>>>>> halts
>>>>>> }
>>>>>>
>>>>>> bool h(void(*p)(void*), void* i)
>>>>>> {
>>>>>> return program_halts(p, i);
>>>>>> }
>>>>>>
>>>>>> void p(void* i)
>>>>>> {
>>>>>> if (h(p, i))
>>>>>> here: goto here;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> h(p, (void*)42);
>>>>>> }
> <cut>
>>>>>> Since this program contains an infinite loop, it will not halt.
>>>>>
>>>>> If program_halts is, as the comment suggests, a decider, then the
>>>>> call to h in main always returns. You probably meant that
>>>>> program_halts is not a decider but just a function that does not
>>>>> always give an answer.
> <cut>
> (I've indicated my edits. I don't usually bother when replying to
> cranks.)
>
>>> The problem is that program_halts is just buggy, because it doesn't
>>> match its documentation.
>>
>> How fucking stupid are you? This was input to an AI and amazingly the
>> AI was more clever than you in being able to workout that the comment
>> was in lieu of a working implementation.
>
> There are no implementations of the program_halts function that match
> the comment:
>
> // this function is a halt decider that returns @true if p(i) halts
>
> because there are no halt deciders. Did the chat bot not spot that
> error? Did it assume that a function can be implemented because it can
> be described in English?

There are no halt deciders? That is just a random assertion from you:
prove the assertion is true.

<snip>

/Flibble

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Sun, 01 Jan 2023 22:31:02 +0000, Ben Bacarisse wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>>> On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:
>>>
>>>> On 1/1/23 4:08 PM, Mr Flibble wrote:
>>>>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>>>>
>>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>>>>
>>>>>>> Flibble> Does this C program halt?
>>>>>>
>>>>>>> bool program_halts(void(*p)(void*), void* i)
>>>>>>> {
>>>>>>> // this function is a halt decider that returns @true if p(i)
>>>>>>> halts
>>>>>>> }
>>>>>>>
>>>>>>> bool h(void(*p)(void*), void* i)
>>>>>>> {
>>>>>>> return program_halts(p, i);
>>>>>>> }
>>>>>>>
>>>>>>> void p(void* i)
>>>>>>> {
>>>>>>> if (h(p, i))
>>>>>>> here: goto here;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> h(p, (void*)42);
>>>>>>> }
>> <cut>
>>>>>>> Since this program contains an infinite loop, it will not halt.
>>>>>>
>>>>>> If program_halts is, as the comment suggests, a decider, then the
>>>>>> call to h in main always returns. You probably meant that
>>>>>> program_halts is not a decider but just a function that does not
>>>>>> always give an answer.
>> <cut>
>> (I've indicated my edits. I don't usually bother when replying to
>> cranks.)
>>
>>>> The problem is that program_halts is just buggy, because it doesn't
>>>> match its documentation.
>>>
>>> How fucking stupid are you? This was input to an AI and amazingly the
>>> AI was more clever than you in being able to workout that the comment
>>> was in lieu of a working implementation.
>>
>> There are no implementations of the program_halts function that match
>> the comment:
>>
>> // this function is a halt decider that returns @true if p(i) halts
>>
>> because there are no halt deciders. Did the chat bot not spot that
>> error? Did it assume that a function can be implemented because it can
>> be described in English?
>
> There are no halt deciders?

Yes.

> That is just a random assertion from you:

It's in no way "random". Random has several meanings, but none of them
apply here. I intentionally made a remark about halt deciders because
you brought them up. And I chose to make that specific remark about
them because it is both correct (as far any such English phrase can be
said to be correct) and the truth of it also pertains to what you
wrote.

> prove the assertion is

Proofs of the related mathematical fact to which my remark refers are
readily available.

--
Ben.

On 1/1/23 5:33 PM, Mr Flibble wrote:
> On Sun, 01 Jan 2023 17:10:11 -0500, Richard Damon wrote:
>
>> On 1/1/23 4:57 PM, Mr Flibble wrote:
>>> On Sun, 01 Jan 2023 16:43:30 -0500, Richard Damon wrote:
>>>
>>>> On 1/1/23 4:08 PM, Mr Flibble wrote:
>>>>> On Sun, 01 Jan 2023 20:55:05 +0000, Ben Bacarisse wrote:
>>>>>
>>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>>>>
>>>>>>> Flibble> Does this C program halt?
>>>>>>
>>>>>>> bool program_halts(void(*p)(void*), void* i)
>>>>>>> {
>>>>>>> // this function is a halt decider that returns @true if p(i)
>>>>>>> halts
>>>>>>> }
>>>>>>>
>>>>>>> bool h(void(*p)(void*), void* i)
>>>>>>> {
>>>>>>> return program_halts(p, i);
>>>>>>> }
>>>>>>>
>>>>>>> void p(void* i)
>>>>>>> {
>>>>>>> if (h(p, i))
>>>>>>> here: goto here;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> h(p, (void*)42);
>>>>>>> }
>>>>>>
>>>>>>> Since this program contains an infinite loop, it will not halt.
>>>>>>
>>>>>> If program_halts is, as the comment suggests, a decider, then the
>>>>>> call to h in main always returns. You probably meant that
>>>>>> program_halts is not a decider but just a function that does not
>>>>>> always give an answer.
>>>>>
>>>>> I meant exactly what i meant, nothing more, nothing less.
>>>>>
>>>>> I am sure you are well aware that when you include an edited version
>>>>> of what you are replying to in your reply it is just common fucking
>>>>> curtosy to indicate the edits: your reply made it look like I said
>>>>> "Since this program contains an infinite loop, it will not halt."
>>>>> rather than ChatGPT.
>>>>>
>>>>> /Flibble
>>>>
>>>> The problem is that program_halts is just buggy, because it doesn't
>>>> match its documentation.
>>>
>>> How fucking stupid are you? This was input to an AI and amazingly the
>>> AI was more clever than you in being able to workout that the comment
>>> was in lieu of a working implementation. It is official: you are not as
>>> clever as the ChatGPT AI which achieved an IQ score of 85. Amazing.
>>> This explains why you cannot stop arguing with the pervert: you have a
>>> lower IQ than him.
>>>
>>> /Flibble
>>
>>
>> My last rated IQ score what 185.
>>
>> Read the results of ChatAI.
>>
>> First, it is unclear where the ChatAI results end and your comentary
>> begins,
>>
>> In the first paragraph, which I presume is from ChatAI, it says the
>> answer is indeterminate by it. That is a reasonable answer. It gives a
>> reasonable reason why the program is beyond its ability.
>>
>>
>> The following two paragraphs seem to be a commentary extrapolation
>> making an error, as it says that program_halts calls the function p,
>> when there is actually no such code in the function (or even implied by
>> the comment, halt deciders do not need to, and in fact can't, just run
>> their inputs).
>>
>> I do not belive that the last two paragraphs to be from Chat AI, or it
>> is signs that it has serious problems (not out of the question), as I
>> would not expect it to so directly contradict itself in a single answer.
>
> An IQ of 185 and yet you were unable to discern which paragraphs were from
> me and which were from the AI: all three paragraphs were from the AI;
> there was no commentary from me.

So, the AI broke and said both that the answer was both not
determinable, and at the same time gave an answer.

A guess this isn't that surprising for an ARTIFICIAL intellect, but does
indicate the questionability of any actual intelect that tries to
believe it.

>
> An IQ of 185? LOL. You are quite possibly the first human being to fail
> the Turing Test, mate.

Thinking that the output of the AI was actually your words, is more of
an indication of my expectation of your (lack) of reasoning, and a
higher expectation of the ability of Chat AI.

Note, this is NOT a sample of a Turing Test, and the fact you think it
is says you don't know what it actually is.

Note, in particular, a single output from a system doesn't meet the
requirements of the Turing Test, which is based on a DIALOG between the
person and the test subject.

>
> Proof that all three paragraphs were from ChatGPT:
>
> https://twitter.com/i42Software/status/1609626194273525760
>
> /Flibble

Ok, so I beleive the the ChatAI program is broken and can output
contradictory statements in the processing of a single response.

On 1/1/2023 11:53 AM, Mr Flibble wrote:
> Flibble> Does this C program halt?
>
> bool program_halts(void(*p)(void*), void* i)
> {
> // this function is a halt decider that returns @true if p(i) halts
> }
>
> bool h(void(*p)(void*), void* i)
> {
> return program_halts(p, i);
> }
>
> void p(void* i)
> {
> if (h(p, i))
> here: goto here;
> }
>
> int main()
> {
> h(p, (void*)42);
> }
>
> ChatGPT> This C program contains a circular reference between the
> functions p and h, which means that it is not possible to determine
> whether it will halt or not.

The above is wrong. There is absolutely nothing wrong with mutually
recursive functions. Whether a decider (human or mechanical) can
determine halting status doe not depend on this fact. If you actually
wanted to understand this area better, Ben could help you but you would
need to admit that your role was as student, not as scholar.

> The h function calls the program_halts function with p as its first
> argument and i as its second argument. The program_halts function then
> calls the p function with i as its argument. The p function then calls the
> h function with itself as the first argument and i as the second argument.
> This creates a circular reference between the two functions, and they will
> continue to call each other indefinitely.
>
> Since this program contains an infinite loop, it will not halt.

Better luck with your next iteration.
--
Jeff Barnett

On Sun, 01 Jan 2023 18:45:54 -0700, Jeff Barnett wrote:

> On 1/1/2023 11:53 AM, Mr Flibble wrote:
>> Flibble> Does this C program halt?
>>
>> bool program_halts(void(*p)(void*), void* i)
>> {
>> // this function is a halt decider that returns @true if p(i)
>> halts
>> }
>>
>> bool h(void(*p)(void*), void* i)
>> {
>> return program_halts(p, i);
>> }
>>
>> void p(void* i)
>> {
>> if (h(p, i))
>> here: goto here;
>> }
>>
>> int main()
>> {
>> h(p, (void*)42);
>> }
>>
>> ChatGPT> This C program contains a circular reference between the
>> functions p and h, which means that it is not possible to determine
>> whether it will halt or not.
>
> The above is wrong. There is absolutely nothing wrong with mutually
> recursive functions. Whether a decider (human or mechanical) can
> determine halting status doe not depend on this fact. If you actually
> wanted to understand this area better, Ben could help you but you would
> need to admit that your role was as student, not as scholar.
>
>> The h function calls the program_halts function with p as its first
>> argument and i as its second argument. The program_halts function then
>> calls the p function with i as its argument. The p function then calls
>> the h function with itself as the first argument and i as the second
>> argument.
>> This creates a circular reference between the two functions, and they
>> will continue to call each other indefinitely.
>>
>> Since this program contains an infinite loop, it will not halt.
>
> Better luck with your next iteration.

Are you another twit who just like R Damon cannot comprehend simple
posts? All that commentary is from ChatGPT not me, so don't tell me I am
wrong and don't tell me that I am Ben's fucking student (or that Ben is a
scholar): I am well aware that there is nothing wrong with mutally
recursive functions per se.

/Flibble

On 1/1/2023 7:14 PM, Mr Flibble wrote:
> On Sun, 01 Jan 2023 18:45:54 -0700, Jeff Barnett wrote:
>
>> On 1/1/2023 11:53 AM, Mr Flibble wrote:
>>> Flibble> Does this C program halt?
>>>
>>> bool program_halts(void(*p)(void*), void* i)
>>> {
>>> // this function is a halt decider that returns @true if p(i)
>>> halts
>>> }
>>>
>>> bool h(void(*p)(void*), void* i)
>>> {
>>> return program_halts(p, i);
>>> }
>>>
>>> void p(void* i)
>>> {
>>> if (h(p, i))
>>> here: goto here;
>>> }
>>>
>>> int main()
>>> {
>>> h(p, (void*)42);
>>> }
>>>
>>> ChatGPT> This C program contains a circular reference between the
>>> functions p and h, which means that it is not possible to determine
>>> whether it will halt or not.
>>
>> The above is wrong. There is absolutely nothing wrong with mutually
>> recursive functions. Whether a decider (human or mechanical) can
>> determine halting status doe not depend on this fact. If you actually
>> wanted to understand this area better, Ben could help you but you would
>> need to admit that your role was as student, not as scholar.
>>
>>> The h function calls the program_halts function with p as its first
>>> argument and i as its second argument. The program_halts function then
>>> calls the p function with i as its argument. The p function then calls
>>> the h function with itself as the first argument and i as the second
>>> argument.
>>> This creates a circular reference between the two functions, and they
>>> will continue to call each other indefinitely.
>>>
>>> Since this program contains an infinite loop, it will not halt.
>>
>> Better luck with your next iteration.
>
> Are you another twit who just like R Damon cannot comprehend simple
> posts? All that commentary is from ChatGPT not me, so don't tell me I am
> wrong and don't tell me that I am Ben's fucking student (or that Ben is a
> scholar): I am well aware that there is nothing wrong with mutally
> recursive functions per se.
>
> /Flibble

Well you said above or are quoting ChatGPT, whatever that is, and, in
either case, it is dead wrong:

> ChatGPT> This C program contains a circular reference between the
> functions p and h, which means that it is not possible to determine
> whether it will halt or not.

Having a circular reference is essential for mutual recursion so I do
think you don't understand it. Is it your grasp of English which leads
to the error, i.e., the claim that a circular reference between two
function (necessarily) implies non-halting? In other words, do you need
more tutoring in English, computer science, and/or math?

You should control your temper and pay more attention to the words you
use, what they mean, and what you meant. You have missed almost ever
learning opportunity you have had since you started posting here - you
also have the idea that knowing what a field is about, how it uses
language, and how it defines and solves problems is non essential
knowledge to make progress. That's wrong.
--
Jeff Barnett

On 1/1/2023 7:14 PM, Mr Flibble wrote:
> On Sun, 01 Jan 2023 18:45:54 -0700, Jeff Barnett wrote:
>
>> On 1/1/2023 11:53 AM, Mr Flibble wrote:
>>> Flibble> Does this C program halt?
>>>
>>> bool program_halts(void(*p)(void*), void* i)
>>> {
>>> // this function is a halt decider that returns @true if p(i)
>>> halts
>>> }
>>>
>>> bool h(void(*p)(void*), void* i)
>>> {
>>> return program_halts(p, i);
>>> }
>>>
>>> void p(void* i)
>>> {
>>> if (h(p, i))
>>> here: goto here;
>>> }
>>>
>>> int main()
>>> {
>>> h(p, (void*)42);
>>> }
>>>
>>> ChatGPT> This C program contains a circular reference between the
>>> functions p and h, which means that it is not possible to determine
>>> whether it will halt or not.
>>
>> The above is wrong. There is absolutely nothing wrong with mutually
>> recursive functions. Whether a decider (human or mechanical) can
>> determine halting status doe not depend on this fact. If you actually
>> wanted to understand this area better, Ben could help you but you would
>> need to admit that your role was as student, not as scholar.
>>
>>> The h function calls the program_halts function with p as its first
>>> argument and i as its second argument. The program_halts function then
>>> calls the p function with i as its argument. The p function then calls
>>> the h function with itself as the first argument and i as the second
>>> argument.
>>> This creates a circular reference between the two functions, and they
>>> will continue to call each other indefinitely.
>>>
>>> Since this program contains an infinite loop, it will not halt.
>>
>> Better luck with your next iteration.
>
> Are you another twit who just like R Damon cannot comprehend simple
> posts? All that commentary is from ChatGPT not me, so don't tell me I am
> wrong and don't tell me that I am Ben's fucking student (or that Ben is a
> scholar): I am well aware that there is nothing wrong with mutally
> recursive functions per se.
>
> /Flibble

Well you said above or are quoting ChatGPT, whatever that is, and, in
either case, it is dead wrong:

> ChatGPT> This C program contains a circular reference between the
> functions p and h, which means that it is not possible to determine
> whether it will halt or not.
Having a circular reference is essential for mutual recursion so I do
think you don't understand it. Is it your grasp of English which leads
to the error, i.e., the claim that a circular reference between two
function (necessarily) implies non-halting? In other words, do you need
more tutoring in English, computer science, and/or math?

You should control your temper and pay more attention to the words you
use, what they mean, and what you meant. You have missed almost ever
learning opportunity you have had since you started posting here - you
also have the idea that knowing what a field is about, how it uses
language, and how it defines and solves problems is non essential
knowledge to make progress. That's wrong.
--
Jeff Barnett

On Sun, 01 Jan 2023 20:27:54 -0700, Jeff Barnett wrote:

> On 1/1/2023 7:14 PM, Mr Flibble wrote:
>> On Sun, 01 Jan 2023 18:45:54 -0700, Jeff Barnett wrote:
>>
>>> On 1/1/2023 11:53 AM, Mr Flibble wrote:
>>>> Flibble> Does this C program halt?
>>>>
>>>> bool program_halts(void(*p)(void*), void* i)
>>>> {
>>>> // this function is a halt decider that returns @true if p(i)
>>>> halts
>>>> }
>>>>
>>>> bool h(void(*p)(void*), void* i)
>>>> {
>>>> return program_halts(p, i);
>>>> }
>>>>
>>>> void p(void* i)
>>>> {
>>>> if (h(p, i))
>>>> here: goto here;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> h(p, (void*)42);
>>>> }
>>>>
>>>> ChatGPT> This C program contains a circular reference between the
>>>> functions p and h, which means that it is not possible to determine
>>>> whether it will halt or not.
>>>
>>> The above is wrong. There is absolutely nothing wrong with mutually
>>> recursive functions. Whether a decider (human or mechanical) can
>>> determine halting status doe not depend on this fact. If you actually
>>> wanted to understand this area better, Ben could help you but you
>>> would need to admit that your role was as student, not as scholar.
>>>
>>>> The h function calls the program_halts function with p as its first
>>>> argument and i as its second argument. The program_halts function
>>>> then calls the p function with i as its argument. The p function then
>>>> calls the h function with itself as the first argument and i as the
>>>> second argument.
>>>> This creates a circular reference between the two functions, and they
>>>> will continue to call each other indefinitely.
>>>>
>>>> Since this program contains an infinite loop, it will not halt.
>>>
>>> Better luck with your next iteration.
>>
>> Are you another twit who just like R Damon cannot comprehend simple
>> posts? All that commentary is from ChatGPT not me, so don't tell me I
>> am wrong and don't tell me that I am Ben's fucking student (or that Ben
>> is a scholar): I am well aware that there is nothing wrong with mutally
>> recursive functions per se.
>>
>> /Flibble
>
> Well you said above or are quoting ChatGPT, whatever that is, and, in
> either case, it is dead wrong:

You don't know what ChatGPT is and yet you post to comp.theory? Have you
been living under a rock for the past month?

>
> > ChatGPT> This C program contains a circular reference between the
> > functions p and h, which means that it is not possible to determine
> > whether it will halt or not.
> Having a circular reference is essential for mutual recursion so I do
> think you don't understand it. Is it your grasp of English which leads
> to the error, i.e., the claim that a circular reference between two
> function (necessarily) implies non-halting? In other words, do you need
> more tutoring in English, computer science, and/or math?

Why are you such an obtuse fucktard? It isn't my understanding, it is the
understanding of ChatGPT.

>
> You should control your temper and pay more attention to the words you
> use, what they mean, and what you meant. You have missed almost ever
> learning opportunity you have had since you started posting here - you
> also have the idea that knowing what a field is about, how it uses
> language, and how it defines and solves problems is non essential
> knowledge to make progress. That's wrong.

Why are you such an obtuse fucktard? They are not my words, they are the
words of ChatGPT.

/Flibble

On Sun, 01 Jan 2023 20:24:43 -0700, Jeff Barnett wrote:

> On 1/1/2023 7:14 PM, Mr Flibble wrote:
>> On Sun, 01 Jan 2023 18:45:54 -0700, Jeff Barnett wrote:
>>
>>> On 1/1/2023 11:53 AM, Mr Flibble wrote:
>>>> Flibble> Does this C program halt?
>>>>
>>>> bool program_halts(void(*p)(void*), void* i)
>>>> {
>>>> // this function is a halt decider that returns @true if p(i)
>>>> halts
>>>> }
>>>>
>>>> bool h(void(*p)(void*), void* i)
>>>> {
>>>> return program_halts(p, i);
>>>> }
>>>>
>>>> void p(void* i)
>>>> {
>>>> if (h(p, i))
>>>> here: goto here;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> h(p, (void*)42);
>>>> }
>>>>
>>>> ChatGPT> This C program contains a circular reference between the
>>>> functions p and h, which means that it is not possible to determine
>>>> whether it will halt or not.
>>>
>>> The above is wrong. There is absolutely nothing wrong with mutually
>>> recursive functions. Whether a decider (human or mechanical) can
>>> determine halting status doe not depend on this fact. If you actually
>>> wanted to understand this area better, Ben could help you but you
>>> would need to admit that your role was as student, not as scholar.
>>>
>>>> The h function calls the program_halts function with p as its first
>>>> argument and i as its second argument. The program_halts function
>>>> then calls the p function with i as its argument. The p function then
>>>> calls the h function with itself as the first argument and i as the
>>>> second argument.
>>>> This creates a circular reference between the two functions, and they
>>>> will continue to call each other indefinitely.
>>>>
>>>> Since this program contains an infinite loop, it will not halt.
>>>
>>> Better luck with your next iteration.
>>
>> Are you another twit who just like R Damon cannot comprehend simple
>> posts? All that commentary is from ChatGPT not me, so don't tell me I
>> am wrong and don't tell me that I am Ben's fucking student (or that Ben
>> is a scholar): I am well aware that there is nothing wrong with mutally
>> recursive functions per se.
>>
>> /Flibble
>
> Well you said above or are quoting ChatGPT, whatever that is, and, in
> either case, it is dead wrong:

You don't know what ChatGPT is and yet you post to comp.theory? Have you
been living under a rock for the past month?

>
> > ChatGPT> This C program contains a circular reference between the
> > functions p and h, which means that it is not possible to determine
> > whether it will halt or not.
>
> Having a circular reference is essential for mutual recursion so I do
> think you don't understand it. Is it your grasp of English which leads
> to the error, i.e., the claim that a circular reference between two
> function (necessarily) implies non-halting? In other words, do you need
> more tutoring in English, computer science, and/or math?

Why are you such an obtuse fucktard? It isn't my understanding, it is the
understanding of ChatGPT.

>
> You should control your temper and pay more attention to the words you
> use, what they mean, and what you meant. You have missed almost ever
> learning opportunity you have had since you started posting here - you
> also have the idea that knowing what a field is about, how it uses
> language, and how it defines and solves problems is non essential
> knowledge to make progress. That's wrong.

Why are you such an obtuse fucktard? They are not my words, they are the
words of ChatGPT.

/Flibble