Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.software-eng > #3446 > unrolled thread

Does the call from P() to H() specify infinite recursion?

Back to article view | Back to comp.software-eng

Contents

  Does the call from P() to H() specify infinite recursion? olcott <NoOne@NoWhere.com> - 2021-11-11 10:00 -0600
    Re: Does the call from P() to H() specify infinite recursion? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-11-11 19:01 +0100
      Re: Does the call from P() to H() specify infinite recursion? olcott <NoOne@NoWhere.com> - 2021-11-11 12:52 -0600
      Re: Does the call from P() to H() specify infinite recursion? Jeff Barnett <jbb@notatt.com> - 2021-11-11 12:06 -0700
        Re: Does the call from P() to H() specify infinite recursion? olcott <NoOne@NoWhere.com> - 2021-11-11 13:26 -0600
          Re: Does the call from P() to H() specify infinite recursion? Jeff Barnett <jbb@notatt.com> - 2021-11-11 14:55 -0700
            Re: Does the call from P() to H() specify infinite recursion? olcott <NoOne@NoWhere.com> - 2021-11-11 16:51 -0600
        Re: Does the call from P() to H() specify infinite recursion? olcott <NoOne@NoWhere.com> - 2021-11-11 16:11 -0600
      Re: Does the call from P() to H() specify infinite recursion? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-11-11 17:47 -0700
        Re: Does the call from P() to H() specify infinite recursion? olcott <NoOne@NoWhere.com> - 2021-11-11 19:02 -0600

#3446 — Does the call from P() to H() specify infinite recursion?

#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

[toc] | [next] | [standalone]

#3447

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

[toc] | [prev] | [next] | [standalone]

#3448

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

[toc] | [prev] | [next] | [standalone]

#3449

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

[toc] | [prev] | [next] | [standalone]

#3450

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

[toc] | [prev] | [next] | [standalone]

#3451

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

[toc] | [prev] | [next] | [standalone]

#3453

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

[toc] | [prev] | [next] | [standalone]

#3452

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

[toc] | [prev] | [next] | [standalone]

#3454

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.

[toc] | [prev] | [next] | [standalone]

#3455

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.software-eng

csiph-web