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

[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;
}

--
Copyright 2021 Pete Olcott

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

[Marcel Mueller]

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

[olcott]

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.

[Jeff Barnett]

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

[Richard Damon]

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.

[olcott]

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;
}

[olcott]

I added this: #include <stdint.h>

[Richard Damon]

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.

[olcott]

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

[Richard Damon]

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.

[olcott]

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

[Ben Bacarisse]

Jeff Barnett <j...@notatt.com> writes:

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

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

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

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

--
Ben.

[Jeff Barnett]

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

[olcott]

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.

[olcott]

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.


--

[Joe Pfeiffer]

Marcel Mueller <news.5...@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.

[olcott]

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.

[Juha Nieminen]

In comp.lang.c++ olcott <No...@nowhere.com> wrote:
> On 11/11/2021 6:47 PM, Joe Pfeiffer wrote:
>> Marcel Mueller <news.5...@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.

You do understand that if the halting problem were solvable, and someone
solved it, it would be the Holy Grail of mathematics? Pretty much every
single unsolved mathematical hypothesis that can be expressed as a
computer program could be solved just like that. The Riemann hypothesis?
Solved. The Collatz conjecture? Solved. All the Millenium Prize Problems?
Solved. You becoming a millionaire by merely solving all these problems
would be peanuts compared to the mathematical revolution that this would
cause.

Of course mathematicians are not stupid. When they have proven that the
halting problem is unsolvable, they know what they are talking about.
No amount of Dunning-Krugerisms is going to change that.

[wij]

I think he won't understand. Because I saw his arguments indicating that
he even get the truth table of logical AND/Implication wrong.

[Tim Rentsch]

Juha Nieminen <nos...@thanks.invalid> writes:

[..wanting to solve the halting problem..]

> You do understand that if the halting problem were solvable, and
> someone solved it, it would be the Holy Grail of mathematics?
> Pretty much every single unsolved mathematical hypothesis that can
> be expressed as a computer program could be solved just like that.

> [...] The Collatz conjecture? Solved. [...]

Can you explain what program would serve to provide a solution to
the Collatz conjecture?

[olcott]

On 11/13/2021 12:24 PM, Tim Rentsch wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>
> [..wanting to solve the halting problem..]
>
>> You do understand that if the halting problem were solvable, and
>> someone solved it, it would be the Holy Grail of mathematics?
>> Pretty much every single unsolved mathematical hypothesis that can
>> be expressed as a computer program could be solved just like that.

I do understand that is simply not the way it works.
If you want to continue discussing this reply to the follow-up group.

Flibble agrees that I am correct:
[Why has the argument with Olcott gone on for so long?]
On 11/13/2021 10:57 AM, Mr Flibble wrote:
> Because the halting problem as defined is a category error: only
> Olcott sees this and the rest of you are blind to it. Classic outcome
> of failing to recognize a category error is an argument that goes
> nowhere and never ends.
>
> /Flibble

>



>> [...] The Collatz conjecture? Solved. [...]
>
> Can you explain what program would serve to provide a solution to
> the Collatz conjecture?
>

--
Copyright 2021 Pete Olcott

[Tim Woodall]

#include <halting.h>

auto collatzN = [](int i) {
while (i != 1) {
if (i&1) i = 3 * i + 1;
else i /= 2;
}

auto collatz = []() {
int n = 1;
while(1) {
if (!HALTS(collatzN(n)))
return n;
++n;
}
}

int main() {
if (HALTS(collatz())) {
std::cout << "conjecture is false." << std::endl;
std::cout << "finding smallest counterexample" << std::endl;
std::cout << collatz() << std::endl;
} else {
std::cout << "conjecture is true." << std::endl;
}
}


Obviously there are much more efficient ways of finding the smallest
counterexample if you have HALTS but I think this answers your question.

[Tim Rentsch]

Nice formulation. The idea of nested calls to HALTS did not
occur to me. Also the idea of being able to call HALTS on
a particular function, rather than the program as a whole,
is a useful one, and not one I remember seeing before (at
least not so clearly).

A hearty round of applause and thank yous.

[Richard Damon]

The key is you call Halts on what could be A program (and each function,
when combined with HALTS is able to be a 'program')

[Tim Rentsch]

Right. Obvious in retrospect. Now if I could just figure
out a way to get my foresight as good as my hindsight....

[olcott]

On 11/13/2021 12:24 PM, Tim Rentsch wrote:

> Juha Nieminen <nos...@thanks.invalid> writes:
>
> [..wanting to solve the halting problem..]
>
>> You do understand that if the halting problem were solvable, and
>> someone solved it,

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

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

int H(ptr x, ptr y)
{

x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P

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

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

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

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

--
Copyright 2021 Pete Olcott

[wij]

POOP, Pete Olcott's Own Problem (Also, Pete Olcott's Other (Halting) Problem [Richard])
---
halt decider (Olcott 2021)
A halt decider accepts or rejects an input on the basis of whether or
not the direct execution or (possibly partial) pure simulation of this
input would ever reach a final state of this input.

I claim that the halt status for a specific H(P,P) is never halting
therefore every correct rebuttal must show that one of these instances
halts.
https://groups.google.com/g/comp.theory/c/i4yGvWzg9gE
---

Basic truth: No one can duplicate your 'experiment'.

Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar

[Keith Thompson]

wij <wyn...@gmail.com> writes:
> On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:

[...]

>> Basic truth: No one can duplicate your 'experiment'.
>
> Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar

Which is why most of us don't read anything he posts in comp.lang.c++
and are not interested in seeing replies here. Post in comp.theory if
you want to engage with him.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[wij]

On Sunday, 14 November 2021 at 18:31:39 UTC+8, Keith Thompson wrote:
> wij <wyn...@gmail.com> writes:
> > On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:
> [...]
> >> Basic truth: No one can duplicate your 'experiment'.
> >
> > Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar
> Which is why most of us don't read anything he posts in comp.lang.c++
> and are not interested in seeing replies here.

Is it? As I knew, not so.
I used to see Mr Flibble in comp.c++. He posted "Halting problem as defined is
erroneous" in comp.theory, which made me worry about C++ people.

> Post in comp.theory if you want to engage with him.
>

Anyone is of the same right posting message on any google forum one think
appropriate, is that correct? Has olcott the right? I think so. Do you?
That said, I don't really enjoy engaging with olcott, he is sometimes very cunny.

[Mr Flibble]

On Sun, 14 Nov 2021 06:09:29 -0800 (PST)
wij <wyn...@gmail.com> wrote:

> On Sunday, 14 November 2021 at 18:31:39 UTC+8, Keith Thompson wrote:
> > wij <wyn...@gmail.com> writes:
> > > On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:
> > [...]
> > >> Basic truth: No one can duplicate your 'experiment'.
> > >
> > > Although you showed some C/C++/x86/TM codes, no one is real, you
> > > are also a liar
> > Which is why most of us don't read anything he posts in
> > comp.lang.c++ and are not interested in seeing replies here.
>
> Is it? As I knew, not so.
> I used to see Mr Flibble in comp.c++. He posted "Halting problem as
> defined is erroneous" in comp.theory, which made me worry about C++
> people.

The halting problem as defined is erroneous: it is effectively a
category error.

/Flibble

[wij]

That is what I am worried about.
If a long C++ debate to find out the problem is rooted in something so basic,
that would be awkward.
There was a C++ fever time, C++ people (esp. standard making people) though it
might surpass TM (that is I guess the reason why standard C++ is so abstract
and, in Go-Game term, 'heavy')

[David Brown]

On 14/11/2021 15:09, wij wrote:
> On Sunday, 14 November 2021 at 18:31:39 UTC+8, Keith Thompson wrote:
>> wij <wyn...@gmail.com> writes:
>>> On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:
>> [...]
>>>> Basic truth: No one can duplicate your 'experiment'.
>>>
>>> Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar
>> Which is why most of us don't read anything he posts in comp.lang.c++
>> and are not interested in seeing replies here.
>
> Is it? As I knew, not so.
> I used to see Mr Flibble in comp.c++. He posted "Halting problem as defined is
> erroneous" in comp.theory, which made me worry about C++ people.
>

Mr. Flibble does not speak for "C++ people". In fact, Mr. Flibble often
does not speak for himself, but posts things just to provoke a reaction.
I don't really know what he means by his comments on the halting
problem, but they are certainly not C++ related - I'm sure if he
actually wants to discuss it, then comp.theory is a better place.

>> Post in comp.theory if you want to engage with him.
>>
>
> Anyone is of the same right posting message on any google forum one think
> appropriate, is that correct? Has olcott the right? I think so. Do you?
> That said, I don't really enjoy engaging with olcott, he is sometimes very cunny.
>

Usenet is a bastion of free speech - there is no sensor of who posts
here, or what they post. Yes, Olcott has the right to post anything
here. Equally, people who would prefer that a C++ newsgroup is for C++
topics have the right to ask others to refrain from off-topic posting or
encouraging impolite and disruptive posters.

Olcott is delusional. He is not the first, nor the last, to believe
that he has found a proof or counter-proof that contradicts a long
established mathematical theorem. Like all such people, rational
arguments bounce off him with no effect, except perhaps to strengthen
his resolve. Replying to and encouraging him does not help anyone - not
him, nor anyone else interested in computational theory, nor other
people frequenting these newsgroups. There is a famous essay "beware
the trisectors" that can be found on the net, which covers the
difficulties in dealing with those like Olcott.

Despite using a limited subset of C and C++ as his programming language
(rather than more traditional choices such as Turing machines), Olcott's
posts are not remote topical here - just as they are not topical in a
newsgroup for English Literature despite being written in English.

Olcott is never going to listen to anyone else's advice or suggestions,
including the suggestion to take his ramblings elsewhere. But perhaps
you might.

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> ... There is a famous essay "beware

> the trisectors" that can be found on the net, which covers the
> difficulties in dealing with those like Olcott.

It's called "What To Do When the Trisector Comes" by Underwood Dudley.
But it's pre-Usenet so have very little relevant advice.

--
Ben.

[olcott]

You are the only one else in the world that realizes this.

[olcott]

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

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

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

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

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

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

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

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

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

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

[Keith Thompson]

wij <wyn...@gmail.com> writes:
> On Sunday, 14 November 2021 at 18:31:39 UTC+8, Keith Thompson wrote:
>> wij <wyn...@gmail.com> writes:
>> > On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:
>> [...]
>> >> Basic truth: No one can duplicate your 'experiment'.
>> >
>> > Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar
>> Which is why most of us don't read anything he posts in comp.lang.c++
>> and are not interested in seeing replies here.
>
> Is it? As I knew, not so.
> I used to see Mr Flibble in comp.c++. He posted "Halting problem as defined is
> erroneous" in comp.theory, which made me worry about C++ people.

I was referring to olcott, not Mr Flibble.

>> Post in comp.theory if you want to engage with him.
>
> Anyone is of the same right posting message on any google forum one think
> appropriate, is that correct? Has olcott the right? I think so. Do you?
> That said, I don't really enjoy engaging with olcott, he is sometimes very cunny.

This is a Usenet newsgroup, not a Google forum. Google has created a
clumsy interface to Usenet, making newsgroups appear as Google forums.

That being said, yes, anyone can post to unmoderated newsgroups. I am
*asking* you to refrain from arguing with olcott here in comp.lang.c++.

[olcott]

On 11/14/2021 3:46 PM, Keith Thompson wrote:
> wij <wyn...@gmail.com> writes:
>> On Sunday, 14 November 2021 at 18:31:39 UTC+8, Keith Thompson wrote:
>>> wij <wyn...@gmail.com> writes:
>>>> On Sunday, 14 November 2021 at 06:29:57 UTC+8, olcott wrote:
>>> [...]
>>>>> Basic truth: No one can duplicate your 'experiment'.
>>>>
>>>> Although you showed some C/C++/x86/TM codes, no one is real, you are also a liar
>>> Which is why most of us don't read anything he posts in comp.lang.c++
>>> and are not interested in seeing replies here.
>>
>> Is it? As I knew, not so.
>> I used to see Mr Flibble in comp.c++. He posted "Halting problem as defined is
>> erroneous" in comp.theory, which made me worry about C++ people.
>
> I was referring to olcott, not Mr Flibble.
>
>>> Post in comp.theory if you want to engage with him.
>>
>> Anyone is of the same right posting message on any google forum one think
>> appropriate, is that correct? Has olcott the right? I think so. Do you?
>> That said, I don't really enjoy engaging with olcott, he is sometimes very cunny.
>
> This is a Usenet newsgroup, not a Google forum. Google has created a
> clumsy interface to Usenet, making newsgroups appear as Google forums.
>
> That being said, yes, anyone can post to unmoderated newsgroups. I am
> *asking* you to refrain from arguing with olcott here in comp.lang.c++.
>

Please just review my snippet code C code and I will go away again.

[wij]

No one likes to see what is not wanted to see. But, 'suppressing' other
speeches should not be what the 'free speech' we recognized.
An example of your case: https://groups.google.com/g/comp.programming
That communication function of that site is sabotaged by "garbage posts" is
definitely not the essence of free speech.
There are also many similar cases, particularly involving political issues.

[David Brown]

On 15/11/2021 09:43, wij wrote:

> No one likes to see what is not wanted to see. But, 'suppressing' other
> speeches should not be what the 'free speech' we recognized.
> An example of your case: https://groups.google.com/g/comp.programming
> That communication function of that site is sabotaged by "garbage posts" is
> definitely not the essence of free speech.
> There are also many similar cases, particularly involving political issues.
>

comp.programming is a Usenet group, not a "site" or a "google group".
And yes, it has been destroyed by vandals - people who irritate others
and hinder other people from using a place for its intended function.
That is a misuse of free speech - just as talking loudly in a cinema or
theatre is a misuse. It is extremely difficult to create and enforce a
set of rules that do not hinder or censor free speech, while at the same
time stopping misuse and abuse.

The best that can be done in an open group like this is to ask people
politely to respect other people. Sometimes it works - I've seen
posters mature from annoying and egotistic to understanding that working
/with/ people in a group, rather than against them, is better for
everyone. Often, it does not work. Some people (such as at least one
person in comp.programming) prefer to destroy communities and vandalise
common areas - that is something that most people find difficult to
understand, but it happens. Others (including a long-term poster to
comp.programming and other groups, including occasionally this one) have
serious psychological issues and I think are unable to understand things
from other peoples' viewpoints. I suspect Olcott falls into this
category - his plan to annoy people such as Keith until they review his
"code" shows a serious inability to understand other people.

Now, despite the rule that "discussions about topicality are always on
topic", is it possible to agree on the following points?

1. Olcott's posts contribute nothing of use or interest to groups such
as comp.lang.c and comp.lang.c++, and are not topical there.

2. No replies to Olcott's posts in these groups help him in any way -
most replies are complaints about the posts, and those that address the
technical aspects are invariably dismissed by Olcott himself.

3. While ignoring Olcott will not stop him entirely, replying to him
encourages most posts. Unfortunately, that also applies to replies in
the topical group comp.theory, since he often cross-posts back to
off-topic groups.

4. No one can stop Olcott or any others from posting what they want.
All that can be done is ask people to stop, and appeal to basic human
decency.

5. Further discussion here will not help. Either you get the point, or
you don't.

[wij]

On Monday, 15 November 2021 at 17:12:36 UTC+8, David Brown wrote:
> On 15/11/2021 09:43, wij wrote:
>
> > No one likes to see what is not wanted to see. But, 'suppressing' other
> > speeches should not be what the 'free speech' we recognized.
> > An example of your case: https://groups.google.com/g/comp.programming
> > That communication function of that site is sabotaged by "garbage posts" is
> > definitely not the essence of free speech.
> > There are also many similar cases, particularly involving political issues.
> >
> comp.programming is a Usenet group, not a "site" or a "google group".

Sorry that I don't really distinguish "site" "google group/forum" "usenet"
"newsgroup", sometimes I refer it to "link" "webpage",...,etc.

From Olcott's Incident I learned quite several things. From my eye, you just
rejected a chance to lean new things for you.
Those had debated with him should have learned something they missed in the
process, nothing really that negative.

It all depend on the viewer.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> And yes, it has been destroyed by vandals - people who irritate others
> and hinder other people from using a place for its intended function.
> That is a misuse of free speech - just as talking loudly in a cinema or
> theatre is a misuse. It is extremely difficult to create and enforce a
> set of rules that do not hinder or censor free speech, while at the same
> time stopping misuse and abuse.

While the concept of "free speech" can be divided into its legal definition
and the *principle* (ie. the ideal that one supports philosophically and
tries to not to infringe as a matter of principle), in either case I would
say that the concept of "free speech" entails three main rules:

1) You should be able to express your opinions in a public forum to
anybody who is willing to listen, without impediment, and without negative
repercussions or pusnishment. (Nobody has to actively provide you the means
to do this, but neither should anybody actively stop you from doing it by
deliberately putting barriers in your way.)

2) You should be able to listen to any opinions you want, by anybody
you want, in a public forum without impediment, and without negative
repercussions or punishment. (Again, nobody has to actively provide you
the means to do this, but likewise should nobody actively stop you from
doing so by deliberately putting barriers in your way.)

3) You should not be forced to say something you don't want to say
(ie. compelled speech), and you should not be forced to listen to any
opinions you don't want to listen to (as long as this this does not
infringe on the other rules above.)

When it comes to disruptive behavior, that usually infringes on the first
and second rule above, as disruptive behavior often hinders people expressing
their opinions and other people listening to them. It is acceptable to limit
disruptive behavior (to a reasonable extent) in order to protect the rules
above.