olcott does not understand basic IF/AND/OR/NOT. This implies many.
On Sat, 2025-08-16 at 03:29 +0800, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to think olcott
has read and know (somewhat) what other people says. But not, olcott doesn't >> understand (probably did not read, neither) and continue to rely, he just repeat
what he want to say, even though inconsistency (he does not understand
contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge are
fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to nothing.
This is another point. One hour ago, I asked olcott a simple test question:
Q: Can you rephrase the wiki definition of halting problem?
olcott's basic method of rebuttal is no reply or erasing reply, pretending it is
not there (so, no rebuttal to him). So, what does the HP definition mean to him?
What does the no reply suggest? He cannot even rephrase the wiki definition of
the halting problem. He knows something.
On 8/15/2025 4:40 PM, wij wrote:
On Sat, 2025-08-16 at 03:29 +0800, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to
think olcott
has read and know (somewhat) what other people says. But not, olcott
doesn't
understand (probably did not read, neither) and continue to rely, he
just repeat
what he want to say, even though inconsistency (he does not understand
contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge
are
fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to
nothing.
This is another point. One hour ago, I asked olcott a simple test
question:
Q: Can you rephrase the wiki definition of halting problem?
olcott's basic method of rebuttal is no reply or erasing reply,
pretending it is
not there (so, no rebuttal to him). So, what does the HP definition
mean to him?
What does the no reply suggest? He cannot even rephrase the wiki
definition of
the halting problem. He knows something.
*Correcting the error of the halting problem spec*
Is it possible to create a halt decider H that consistently
reports the halt status of the behavior specified by its
input finite string Turing machine description P on the
basis of P correctly simulated by H?
*Existing counter-example inputs do not work on this*
On 8/15/2025 4:51 PM, olcott wrote:
On 8/15/2025 4:40 PM, wij wrote:
On Sat, 2025-08-16 at 03:29 +0800, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to
think olcott
has read and know (somewhat) what other people says. But not, olcott
doesn't
understand (probably did not read, neither) and continue to rely, he
just repeat
what he want to say, even though inconsistency (he does not understand >>>> contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms,
knowledge are
fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges
to nothing.
This is another point. One hour ago, I asked olcott a simple test
question:
Q: Can you rephrase the wiki definition of halting problem?
olcott's basic method of rebuttal is no reply or erasing reply,
pretending it is
not there (so, no rebuttal to him). So, what does the HP definition
mean to him?
What does the no reply suggest? He cannot even rephrase the wiki
definition of
the halting problem. He knows something.
*Correcting the error of the halting problem spec*
Is it possible to create a halt decider H that consistently
reports the halt status of the behavior specified by its
input finite string Turing machine description P on the
basis of P correctly simulated by H?
*Existing counter-example inputs do not work on this*
The above has the exact same result as the original
halting problem definition except that it doesn't
get stuck on inputs with pathological self-reference
to their own halt decider.
On 8/15/2025 5:44 PM, wij wrote:
On Fri, 2025-08-15 at 16:51 -0500, olcott wrote:
On 8/15/2025 4:40 PM, wij wrote:
On Sat, 2025-08-16 at 03:29 +0800, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to
think olcott
has read and know (somewhat) what other people says. But not,
olcott doesn't
understand (probably did not read, neither) and continue to rely,
he just repeat
what he want to say, even though inconsistency (he does not understand >>>>> contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms,
knowledge are
fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges
to nothing.
This is another point. One hour ago, I asked olcott a simple test
question:
Q: Can you rephrase the wiki definition of halting problem?
olcott's basic method of rebuttal is no reply or erasing reply,
pretending it is
not there (so, no rebuttal to him). So, what does the HP definition
mean to him?
What does the no reply suggest? He cannot even rephrase the wiki
definition of
the halting problem. He knows something.
*Correcting the error of the halting problem spec*
Is it possible to create a halt decider H that consistently
reports the halt status of the behavior specified by its
input finite string Turing machine description P on the
basis of P correctly simulated by H?
"...by its input finite string Turing machine description P on the
basis of P correctly simulated by H?" is you added to the HP.
Wiki definition https://en.wikipedia.org/wiki/Halting_problem
(there are many kind of definition) explicitly says in [Common pitfalls]
about simulating execution is no no.
You added "correctly simulated by H" effectly changes the HP definition,
and you need to define what is "correctly simulated by H". In doing
so, I am
afraid you are defining in circle. Thus, POOH is meaningless
description from
the begin. Nothing needs to prove or disprove.
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
On 8/15/2025 6:18 PM, wij wrote:
On Fri, 2025-08-15 at 17:50 -0500, olcott wrote:
On 8/15/2025 5:44 PM, wij wrote:
On Fri, 2025-08-15 at 16:51 -0500, olcott wrote:
On 8/15/2025 4:40 PM, wij wrote:
On Sat, 2025-08-16 at 03:29 +0800, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many. >>>>>>> Often, olcott cannot answer what other people says, people used
to think olcott
has read and know (somewhat) what other people says. But not,
olcott doesn't
understand (probably did not read, neither) and continue to rely, >>>>>>> he just repeat
what he want to say, even though inconsistency (he does not
understand
contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms,
knowledge are
fabrication in his brain.
So, my solution is insist your unanswered question untill answered. >>>>>>> olcott is good at switching subject, otherwise discussion
diverges to nothing.
This is another point. One hour ago, I asked olcott a simple test
question:
Q: Can you rephrase the wiki definition of halting problem?
olcott's basic method of rebuttal is no reply or erasing reply,
pretending it is
not there (so, no rebuttal to him). So, what does the HP
definition mean to him?
What does the no reply suggest? He cannot even rephrase the wiki
definition of
the halting problem. He knows something.
*Correcting the error of the halting problem spec*
Is it possible to create a halt decider H that consistently
reports the halt status of the behavior specified by its
input finite string Turing machine description P on the
basis of P correctly simulated by H?
"...by its input finite string Turing machine description P on the
basis of P correctly simulated by H?" is you added to the HP.
Wiki definition https://en.wikipedia.org/wiki/Halting_problem
(there are many kind of definition) explicitly says in [Common
pitfalls]
about simulating execution is no no.
You added "correctly simulated by H" effectly changes the HP
definition,
and you need to define what is "correctly simulated by H". In doing
so, I am
afraid you are defining in circle. Thus, POOH is meaningless
description from
the begin. Nothing needs to prove or disprove.
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
You don't understand what those symbols means, what did you really mean?
*It is my adaptation and rebuttal of the Peter Linz proof* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Try write a TM that computes the length of its input to prove you
understand TM.
or try to write a TM to demonstrate what is 'copy' in (a), what is
'invoke' in (b)
and what is 'simulate' in (c). Can you?
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to think olcott
has read and know (somewhat) what other people says. But not, olcott doesn't understand (probably did not read, neither) and continue to rely, he just repeat
what he want to say, even though inconsistency (he does not understand contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge are fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to nothing.
On 8/15/2025 7:34 PM, Mike Terry wrote:
On 15/08/2025 20:29, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to
think olcott
has read and know (somewhat) what other people says. But not, olcott
doesn't
understand (probably did not read, neither) and continue to rely, he
just repeat
what he want to say, even though inconsistency (he does not understand
contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge
are
fabrication in his brain.
with you so far...
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to
nothing.
but this doesn't really work. Just asking PO to answer the same
question over and over is assuming PO has a proper understanding of
what you're asking and is just being stubborn in refusing to answer.
That's /sometimes/ the case but for most questions I think PO
genuinely doesn't understand what's being asked... So simply
repeating the question doesn't make much progress.
*If* PO were a typical student who was just confused over some point,
a strategy to help him might be to step back and look at the language
being used. Insist on duffer-speak phrases being eliminated or
properly defined in terms of <other well-understood terminology>.
That's probably what I'd try. In this process the student would
hopefully see that his/her own thinking was confused and not properly
thought through.
That doesn't work with PO for several reasons!
- With PO there really is no <other well-understood terminology> -
PO's conceptual misunderstandings and terminology confusions go "all
the way down". This approach risks some kind of infinite regress, or
at best something resembling a kind of Hydra game:
<https://en.wikipedia.org/wiki/Hydra_game>
(The point is, while the Hydra game can be shown to always end, the
length of such a game can Very Very Long due to the game's growth rate!)
- there is no chance whatsoever PO could stick to the rules of a
"clarify everything" approach. He doesn't understand /his own/
thinking in any coherently explainable way!
- being /unable/ to adequately clarify his intention, if doggedly
pressed PO will just Say More Words (whatever, just carry on
regardless) or more likely just refuse to speak to the poster. I've
seen both many times. No actual progress is made.
-----
So stepping back for the title question - what IS an efficient way to
communicate with a person with whom you have no shared vocabulary or
technical concepts, and who lacks the required capabilities of logical
comprehension that might establish such a shared basis?
Put as bluntly as this, obviously communication with such a person is
going to impossible or horrendously inefficient. But it begs the
question of what would be GAINED from such an attempt? I.e. /why/ are
you trying to communicate with such a person? We need to know the
objectives before we can come up with efficient approaches... A
reasonable starting suggestion might be "don't communicate"...
Mike.
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
there are no finite number of steps of correct
simulation where DD correctly simulated by HHH
reaches its own simulated final halt state.
Kaz thought this last part was so obvious that he
honestly didn't believe that everyone here didn't see it.
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD promptly
halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
On 8/15/2025 7:52 PM, wij wrote:
On Fri, 2025-08-15 at 18:29 -0500, olcott wrote:
On 8/15/2025 6:18 PM, wij wrote:
On Fri, 2025-08-15 at 17:50 -0500, olcott wrote:
On 8/15/2025 5:44 PM, wij wrote:
On Fri, 2025-08-15 at 16:51 -0500, olcott wrote:
On 8/15/2025 4:40 PM, wij wrote:
On Sat, 2025-08-16 at 03:29 +0800, wij wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many. >>>>>>>>> Often, olcott cannot answer what other people says, people used >>>>>>>>> to think olcott
has read and know (somewhat) what other people says. But not, >>>>>>>>> olcott doesn't
understand (probably did not read, neither) and continue to
rely, he just repeat
what he want to say, even though inconsistency (he does not
understand
contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms,
knowledge are
fabrication in his brain.
So, my solution is insist your unanswered question untill
answered.
olcott is good at switching subject, otherwise discussion
diverges to nothing.
This is another point. One hour ago, I asked olcott a simple
test question:
Q: Can you rephrase the wiki definition of halting problem?
olcott's basic method of rebuttal is no reply or erasing reply, >>>>>>>> pretending it is
not there (so, no rebuttal to him). So, what does the HP
definition mean to him?
What does the no reply suggest? He cannot even rephrase the wiki >>>>>>>> definition of
the halting problem. He knows something.
*Correcting the error of the halting problem spec*
Is it possible to create a halt decider H that consistently
reports the halt status of the behavior specified by its
input finite string Turing machine description P on the
basis of P correctly simulated by H?
"...by its input finite string Turing machine description P on the >>>>>> basis of P correctly simulated by H?" is you added to the HP.
Wiki definition https://en.wikipedia.org/wiki/Halting_problem
(there are many kind of definition) explicitly says in [Common
pitfalls]
about simulating execution is no no.
You added "correctly simulated by H" effectly changes the HP
definition,
and you need to define what is "correctly simulated by H". In
doing so, I am
afraid you are defining in circle. Thus, POOH is meaningless
description from
the begin. Nothing needs to prove or disprove.
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
You don't understand what those symbols means, what did you really
mean?
*It is my adaptation and rebuttal of the Peter Linz proof*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Yes, this is a typical trick. (olcott doesn't understand the challenge
is most an insult
to average people in comp.theory).
Once I get into the Peter_Linz_317-320.pdf, he would (maybe after days
of discussion)
probably change subject to Tarski theorem or Prolog, ... various like
of liar's paradox,
philosophy or maybe some set theory.
Try write a TM that computes the length of its input to prove you
understand TM.
or try to write a TM to demonstrate what is 'copy' in (a), what is
'invoke' in (b)
and what is 'simulate' in (c). Can you?
This is erased question, typically proves olcott can't.
It is all explained in Linz.
My Linz link was the answer.
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
You argue that it's not reasonable to expect HHH to deduce that from
the limited information available to it. And of course that is quite
right, but all we can deduce from that is that you have failed to
provide that information to HHH. There's no excuse for it, though; the
information is freely available in DD's executable image as
constructed by the compiler. If you don't want to do it that way, you
can pass in the source code.
As it stands, though, your simulation is inadequate because it
completely fails to simulate the most important part of DD - a part
that you argue is invisible, but it clearly isn't because /we/ can see
it.
On 8/15/25 11:46 PM, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD
promptly halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
And thus one doesn't tell you the behavior of the other like you
try to claim.
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
On 8/16/2025 11:39 AM, Kaz Kylheku wrote:But that isn't the definition of non-halting.
On 2025-08-16, olcott <polcott333@gmail.com> wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
It is CS undergraduate insight, and you're ignoring that part of
which identifies it as confounding your argumentation.
If the spontaneous call out of main to HHH(DD) behaves differently in
the slightest detail fro mthe HHH(DD) that is embedded inside DD, that
situation shows taht HHH isn't a function of DD, but a procedure with
side effects, involving unidentified outside objects and input sources.
A Turing machine has no unidentified inputs or side effects; its
behavior is a function of the tape. Same tape, same calculation.
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
causing M applied to ⟨M⟩ halt
If M.H ⟨M⟩ ⟨M⟩ cannot see that it is called
in recursive simulation then M applied to ⟨M⟩
is still non-halting and an outside observer
can see this.
On 16/08/2025 13:10, Richard Damon wrote:
On 8/15/25 11:46 PM, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/ HHH(DD)
returns 0 to indicate that DD doesn't halt, DD promptly halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
And thus one doesn't tell you the behavior of the other like you try
to claim.
I beg to differ. One is /required/ to tell you the behaviour of the one.
<snip>
On 8/16/25 9:18 AM, Richard Heathfield wrote:
On 16/08/2025 13:10, Richard Damon wrote:
On 8/15/25 11:46 PM, olcott wrote:
On 8/15/2025 10:44 PM, Richard Heathfield wrote:
On 16/08/2025 04:01, olcott wrote:
All of this comes from you failing to understand
that HHH(DD) does recognize that itself does get
stuck in recursive simulation, aborts this emulation,
and returns 0 indicating that:
No, it all comes from you failing to understand that /when/
HHH(DD) returns 0 to indicate that DD doesn't halt, DD
promptly halts.
As Kaz indicated these are different DD's.
That was his brilliant insight into the matter.
And thus one doesn't tell you the behavior of the other like
you try to claim.
I beg to differ. One is /required/ to tell you the behaviour of
the one.
<snip>
But doesn't
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
causing M applied to ⟨M⟩ halt
If M.H ⟨M⟩ ⟨M⟩ cannot see that it is called
in recursive simulation then M applied to ⟨M⟩
is still non-halting and an outside observer
can see this.
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to
think olcotthas read and know (somewhat) what other people says. But
not, olcott doesn't
understand (probably did not read, neither) and continue to rely, he
just repeat
what he want to say, even though inconsistency (he does not understand contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge are fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to nothing.
We don't need an efficient way to communicate with Olcott. We
only need
an efficient way to inform readers that they needn't be deceived.
On 8/17/2025 2:14 AM, Kaz Kylheku wrote:
On 2025-08-16, olcott <polcott333@gmail.com> wrote:
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
causing M applied to ⟨M⟩ halt
If M.H ⟨M⟩ ⟨M⟩ cannot see that it is called
in recursive simulation then M applied to ⟨M⟩
is still non-halting and an outside observer
can see this.
M has failed to decide.
That an outside observer can tell doesn't matter;
It does seem to matter. Previously both [halts] and
[does not halt] were the wrong answer. Now [does not halt]
is the correct answer even if HHH does not know it.
the outside observer
is a different decider which is not M. The success of the outside
observer's decision doesn't repair the failure of M (that it didn't
halt).
Everyone else here simply flat out lies about my prior
paragraph by disagreeing with its verified facts.
It great to have a competent reviewer that is not a liar.
This has taken three years.
I think that you were the one that taught me about
computable functions. It still seems a little silly
that C code can do things that Turing machines cannot.
You're playing games with magic flags that indicate inside versus
outside so that you could pretend that M is both the decider in question
/and/ the outside observer.
You just can't do that.
I think that you were the one that taught me about
computable functions. It still seems a little silly
that C code can do things that Turing machines cannot.
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:
I think that you were the one that taught me about
computable functions. It still seems a little silly
that C code can do things that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can interface
with the outside world and respond to real-time events and ocnditions
that are never the same on any repeated run. Let's make it clear
that this is not on the table at all.
C calculations that are deterministic are Turing computations.
But you have to know where to draw the chalk line around them to
say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables
which are not reset to known values, we have to work harder to
identify what is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together
with a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine
c = 73; result = add(7, 13); // that's a different Turing machine
We can't ignore the hidden static data which affects the
calculation, but if we identify it and control it then we can
characterize the conditions that give us a Turing machine.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine
that DD correctly simulated by HHH cannot possibly
reach its own "return" instruction final halt state.
It aborts its simulation and correctly returns 0
to indicate this.
When we eliminate the static data then it remains
true that the input to HHH(DD) remains stuck in
recursive simulation, yet HHH cannot know this
with my currently coded HHH.
The design of HHH is a pure function of its input.
HHH merely reports on the behavior specified by
this input: DD correctly simulated by HHH including
HHH simulating an instance of itself simulating an
instance of DD.
The current implementation of HHH does depend on
homemade static data for at least: execution_trace;
C functions are really procedures, which /can/ be functions.
When they are not functions, we may be to identify the
constituents of the computation that give us functions.
E.g. a state machine's state transition function
(which could actually be a C array, not a C function).
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:
I think that you were the one that taught me about
computable functions. It still seems a little silly
that C code can do things that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can interface
with the outside world and respond to real-time events and ocnditions
that are never the same on any repeated run. Let's make it clear
that this is not on the table at all.
C calculations that are deterministic are Turing computations.
But you have to know where to draw the chalk line around them to
say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables
which are not reset to known values, we have to work harder to
identify what is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together
with a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine
c = 73; result = add(7, 13); // that's a different Turing machine
We can't ignore the hidden static data which affects the
calculation, but if we identify it and control it then we can
characterize the conditions that give us a Turing machine.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine
that DD correctly simulated by HHH cannot possibly
reach its own "return" instruction final halt state.
It aborts its simulation and correctly returns 0
to indicate this.
When we eliminate the static data then it remains
true that the input to HHH(DD) remains stuck in
recursive simulation, yet HHH cannot know this
with my currently coded HHH.
The design of HHH is a pure function of its input.
HHH merely reports on the behavior specified by
this input: DD correctly simulated by HHH including
HHH simulating an instance of itself simulating an
instance of DD.
The current implementation of HHH does depend on
homemade static data for at least: execution_trace;
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:When HHH(DD) is a pure function of its inputs and uses no static data
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:int DD()
I think that you were the one that taught me about computable
functions. It still seems a little silly that C code can do things
that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can interface
with the outside world and respond to real-time events and ocnditions
that are never the same on any repeated run. Let's make it clear that
this is not on the table at all.
C calculations that are deterministic are Turing computations.
But you have to know where to draw the chalk line around them to say
"that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables which are
not reset to known values, we have to work harder to identify what is
the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together with a
specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine c = 73;
result = add(7, 13); // that's a different Turing machine
We can't ignore the hidden static data which affects the calculation,
but if we identify it and control it then we can characterize the
conditions that give us a Turing machine.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine that DD correctly
simulated by HHH cannot possibly reach its own "return" instruction
final halt state.
It aborts its simulation and correctly returns 0 to indicate this.
DD isn't stuck if HHH(DD) returns zero.
Your system represents two different HHH functions in one function
body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you need
functions. Procedures that access mutating static data are not
functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your situation
is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the decider
is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1) can
determine that DD isn't halting and return that indication.
But the DD test case is trying to show that HHD(..., 0) is not a valid
decider, not HH(..., 1). You cannot argue that DD does not show that
which it shows because HH(..., 1), a different decider, decides it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly
decide.
That's the samea s removing the static data: keeping the flag the same
everywhere.
You can't use decider A to show that a test case which embeds decider B
can be decided, and then claim that halting undecidability is bunk; it
doesn't work.
The test case which embeds decider B shows that B is not a universal
halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which targets A.
When we eliminate the static data then it remains true that the input
to HHH(DD) remains stuck in recursive simulation, yet HHH cannot know
this with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and restore
it around each HHHH call) then your system collectly exemplifies the
undecidability of halting, refuting your claims.
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer the
queston "am I the top-level HHH or not?" which is equivalent to passing
in a flag argument which splits it into two classes of decider.
HHH merely reports on the behavior specified by this input: DD
correctly simulated by HHH including HHH simulating an instance of
itself simulating an instance of DD.
The current implementation of HHH does depend on homemade static data
for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static data, such as a
numeric or string literal.
If you want HHH to be a pure function, which you should, you must turn
every operand it depends on into a parameter of the function (every
operand that is not a literal constant). Also, the parameter must be a
value parameter, not a pointer to some mutable is effectively the same
as static data.
For each call to HHH, decide what arguments those extra parameters take
on and then realize that every distinct combination of those arguments
effectively gives rise to a different HHH.
then both HHH(DD) and directly executed DD() never stop running proving
that HHH(DD)==0 is correct.
On 8/18/2025 12:57 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 12:55:44 -0500, olcott wrote:
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:When HHH(DD) is a pure function of its inputs and uses no static data
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:int DD()
I think that you were the one that taught me about computable
functions. It still seems a little silly that C code can do things >>>>>>> that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can
interface with the outside world and respond to real-time events
and ocnditions that are never the same on any repeated run. Let's
make it clear that this is not on the table at all.
C calculations that are deterministic are Turing computations.
But you have to know where to draw the chalk line around them to
say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables which are >>>>>> not reset to known values, we have to work harder to identify what >>>>>> is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together with >>>>>> a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine c =
73;
result = add(7, 13); // that's a different Turing machine
We can't ignore the hidden static data which affects the
calculation,
but if we identify it and control it then we can characterize the
conditions that give us a Turing machine.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine that DD correctly
simulated by HHH cannot possibly reach its own "return" instruction
final halt state.
It aborts its simulation and correctly returns 0 to indicate this.
DD isn't stuck if HHH(DD) returns zero.
Your system represents two different HHH functions in one function
body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you need
functions. Procedures that access mutating static data are not
functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your
situation is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the
decider is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1) can
determine that DD isn't halting and return that indication.
But the DD test case is trying to show that HHD(..., 0) is not a
valid decider, not HH(..., 1). You cannot argue that DD does not show
that which it shows because HH(..., 1), a different decider, decides
it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly
decide.
That's the samea s removing the static data: keeping the flag the
same everywhere.
You can't use decider A to show that a test case which embeds decider
B can be decided, and then claim that halting undecidability is bunk;
it doesn't work.
The test case which embeds decider B shows that B is not a universal
halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which targets
A.
When we eliminate the static data then it remains true that the
input to HHH(DD) remains stuck in recursive simulation, yet HHH
cannot know this with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and
restore it around each HHHH call) then your system collectly
exemplifies the undecidability of halting, refuting your claims.
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer the
queston "am I the top-level HHH or not?" which is equivalent to
passing in a flag argument which splits it into two classes of
decider.
HHH merely reports on the behavior specified by this input: DD
correctly simulated by HHH including HHH simulating an instance of
itself simulating an instance of DD.
The current implementation of HHH does depend on homemade static
data for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static data, such as a
numeric or string literal.
If you want HHH to be a pure function, which you should, you must
turn every operand it depends on into a parameter of the function
(every operand that is not a literal constant). Also, the parameter
must be a value parameter, not a pointer to some mutable is
effectively the same as static data.
For each call to HHH, decide what arguments those extra parameters
take on and then realize that every distinct combination of those
arguments effectively gives rise to a different HHH.
then both HHH(DD) and directly executed DD() never stop running
proving that HHH(DD)==0 is correct.
No. HHH(DD) has to report to the directly executed DD() otherwise HHH
is not a halt decider.
/Flibble
Turing machine deciders only compute the mapping from their inputs...
Otherwise HHH is not any kind of decider at all.
On 8/18/2025 1:21 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 13:19:21 -0500, olcott wrote:
On 8/18/2025 12:57 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 12:55:44 -0500, olcott wrote:
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:When HHH(DD) is a pure function of its inputs and uses no static
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:DD isn't stuck if HHH(DD) returns zero.
On 2025-08-17, olcott <polcott333@gmail.com> wrote:int DD()
I think that you were the one that taught me about computable >>>>>>>>> functions. It still seems a little silly that C code can do
things that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can
interface with the outside world and respond to real-time events >>>>>>>> and ocnditions that are never the same on any repeated run. Let's >>>>>>>> make it clear that this is not on the table at all.
C calculations that are deterministic are Turing computations. >>>>>>>> But you have to know where to draw the chalk line around them to >>>>>>>> say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables which >>>>>>>> are not reset to known values, we have to work harder to identify >>>>>>>> what is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together >>>>>>>> with a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine c >>>>>>>> =
73;
result = add(7, 13); // that's a different Turing machine >>>>>>>>
We can't ignore the hidden static data which affects the
calculation,
but if we identify it and control it then we can characterize the >>>>>>>> conditions that give us a Turing machine.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine that DD correctly >>>>>>> simulated by HHH cannot possibly reach its own "return"
instruction final halt state.
It aborts its simulation and correctly returns 0 to indicate this. >>>>>>
Your system represents two different HHH functions in one function >>>>>> body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you need >>>>>> functions. Procedures that access mutating static data are not
functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your
situation is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the
decider is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1)
can determine that DD isn't halting and return that indication.
But the DD test case is trying to show that HHD(..., 0) is not a
valid decider, not HH(..., 1). You cannot argue that DD does not
show that which it shows because HH(..., 1), a different decider,
decides it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly
decide.
That's the samea s removing the static data: keeping the flag the
same everywhere.
You can't use decider A to show that a test case which embeds
decider B can be decided, and then claim that halting
undecidability is bunk;
it doesn't work.
The test case which embeds decider B shows that B is not a
universal halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which targets >>>>>> A.
When we eliminate the static data then it remains true that the
input to HHH(DD) remains stuck in recursive simulation, yet HHH
cannot know this with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and
restore it around each HHHH call) then your system collectly
exemplifies the undecidability of halting, refuting your claims.
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer the >>>>>> queston "am I the top-level HHH or not?" which is equivalent to
passing in a flag argument which splits it into two classes of
decider.
HHH merely reports on the behavior specified by this input: DD
correctly simulated by HHH including HHH simulating an instance of >>>>>>> itself simulating an instance of DD.
The current implementation of HHH does depend on homemade static >>>>>>> data for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static data, such as a >>>>>> numeric or string literal.
If you want HHH to be a pure function, which you should, you must
turn every operand it depends on into a parameter of the function
(every operand that is not a literal constant). Also, the
parameter must be a value parameter, not a pointer to some mutable >>>>>> is effectively the same as static data.
For each call to HHH, decide what arguments those extra parameters >>>>>> take on and then realize that every distinct combination of those
arguments effectively gives rise to a different HHH.
data then both HHH(DD) and directly executed DD() never stop running >>>>> proving that HHH(DD)==0 is correct.
No. HHH(DD) has to report to the directly executed DD() otherwise HHH
is not a halt decider.
/Flibble
Turing machine deciders only compute the mapping from their inputs...
Otherwise HHH is not any kind of decider at all.
A halt decider needs to report a decision to its caller.
/Flibble
Yes. A halt decider cannot possibly report a decision about the behavior
OF ITS CALLER.
On 8/18/2025 1:59 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 13:49:48 -0500, olcott wrote:
On 8/18/2025 1:21 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 13:19:21 -0500, olcott wrote:
On 8/18/2025 12:57 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 12:55:44 -0500, olcott wrote:
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:When HHH(DD) is a pure function of its inputs and uses no static >>>>>>> data then both HHH(DD) and directly executed DD() never stop
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:int DD()
I think that you were the one that taught me about computable >>>>>>>>>>> functions. It still seems a little silly that C code can do >>>>>>>>>>> things that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can >>>>>>>>>> interface with the outside world and respond to real-time
events and ocnditions that are never the same on any repeated >>>>>>>>>> run. Let's make it clear that this is not on the table at all. >>>>>>>>>>
C calculations that are deterministic are Turing computations. >>>>>>>>>> But you have to know where to draw the chalk line around them >>>>>>>>>> to say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is >>>>>>>>>> self-contained, like the contents of a tape.
If we have a function that is looking at static variables which >>>>>>>>>> are not reset to known values, we have to work harder to
identify what is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together >>>>>>>>>> with a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine >>>>>>>>>> c =
73;
result = add(7, 13); // that's a different Turing
machine
We can't ignore the hidden static data which affects the
calculation,
but if we identify it and control it then we can characterize >>>>>>>>>> the conditions that give us a Turing machine.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine that DD correctly >>>>>>>>> simulated by HHH cannot possibly reach its own "return"
instruction final halt state.
It aborts its simulation and correctly returns 0 to indicate >>>>>>>>> this.
DD isn't stuck if HHH(DD) returns zero.
Your system represents two different HHH functions in one
function body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you >>>>>>>> need functions. Procedures that access mutating static data are >>>>>>>> not functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your
situation is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the >>>>>>>> decider is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1) >>>>>>>> can determine that DD isn't halting and return that indication. >>>>>>>>
But the DD test case is trying to show that HHD(..., 0) is not a >>>>>>>> valid decider, not HH(..., 1). You cannot argue that DD does not >>>>>>>> show that which it shows because HH(..., 1), a different decider, >>>>>>>> decides it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly >>>>>>>> decide.
That's the samea s removing the static data: keeping the flag the >>>>>>>> same everywhere.
You can't use decider A to show that a test case which embeds
decider B can be decided, and then claim that halting
undecidability is bunk;
it doesn't work.
The test case which embeds decider B shows that B is not a
universal halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which
targets A.
When we eliminate the static data then it remains true that the >>>>>>>>> input to HHH(DD) remains stuck in recursive simulation, yet HHH >>>>>>>>> cannot know this with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and >>>>>>>> restore it around each HHHH call) then your system collectly
exemplifies the undecidability of halting, refuting your claims. >>>>>>>>
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer >>>>>>>> the queston "am I the top-level HHH or not?" which is equivalent >>>>>>>> to passing in a flag argument which splits it into two classes of >>>>>>>> decider.
HHH merely reports on the behavior specified by this input: DD >>>>>>>>> correctly simulated by HHH including HHH simulating an instance >>>>>>>>> of itself simulating an instance of DD.
The current implementation of HHH does depend on homemade static >>>>>>>>> data for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static data, such as >>>>>>>> a numeric or string literal.
If you want HHH to be a pure function, which you should, you must >>>>>>>> turn every operand it depends on into a parameter of the function >>>>>>>> (every operand that is not a literal constant). Also, the
parameter must be a value parameter, not a pointer to some
mutable is effectively the same as static data.
For each call to HHH, decide what arguments those extra
parameters take on and then realize that every distinct
combination of those arguments effectively gives rise to a
different HHH.
running proving that HHH(DD)==0 is correct.
No. HHH(DD) has to report to the directly executed DD() otherwise
HHH is not a halt decider.
/Flibble
Turing machine deciders only compute the mapping from their
inputs...
Otherwise HHH is not any kind of decider at all.
A halt decider needs to report a decision to its caller.
/Flibble
Yes. A halt decider cannot possibly report a decision about the
behavior OF ITS CALLER.
It can do and must do if a *description* of its caller is passed to the
halt decider as an input.
/Flibble
THAT IS NOT THE BEHAVIOR OF ITS ACTUAL CALLER THAT IS THE BEHAVIOR OF
ITS ACTUAL INPUT
THAT IS NOT THE BEHAVIOR OF ITS ACTUAL CALLER
THAT IS THE BEHAVIOR OF ITS ACTUAL INPUT
On 8/18/2025 1:01 PM, dbush wrote:Wait, what? You’re *acknowledging* that HHH reports on DD(){HHH_inf();}?
On 8/18/2025 1:55 PM, olcott wrote:
*Changing the decider/input pairs is required* nitwitWhen HHH(DD) is a pure function of its inputs and uses no static datai.e. when you change the input.
then both HHH(DD) and directly executed DD() never stop running
proving that HHH(DD)==0 is correct.Nope. Changing the input is not allowed.
I am not calling you a nitwit because you made a mistake. I am callingThat is what a nitwit would say.
you a nitwit because you keep making the same mistake after many
corrections.
On 8/18/2025 3:53 PM, joes wrote:
Am Mon, 18 Aug 2025 13:27:26 -0500 schrieb olcott:
On 8/18/2025 1:01 PM, dbush wrote:Wait, what? You’re *acknowledging* that HHH reports on
On 8/18/2025 1:55 PM, olcott wrote:
*Changing the decider/input pairs is required* nitwitWhen HHH(DD) is a pure function of its inputs and uses no statici.e. when you change the input.
data then both HHH(DD) and directly executed DD() never stop running
proving that HHH(DD)==0 is correct.Nope. Changing the input is not allowed.
DD(){HHH_inf();}?
I keep telling you that M is not a concrete machine!Too stupid to understand that M is a template specifying an infinite setI am not calling you a nitwit because you made a mistake. I am callingThat is what a nitwit would say.
you a nitwit because you keep making the same mistake after many
corrections.
of machine / input pairs ?
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to think olcott
has read and know (somewhat) what other people says. But not, olcott doesn't >understand (probably did not read, neither) and continue to rely, he just repeat
what he want to say, even though inconsistency (he does not understand >contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge are >fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to nothing.
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:
I think that you were the one that taught me about
computable functions. It still seems a little silly
that C code can do things that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can interface
with the outside world and respond to real-time events and ocnditions
that are never the same on any repeated run. Let's make it clear
that this is not on the table at all.
C calculations that are deterministic are Turing computations.
But you have to know where to draw the chalk line around them to
say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables
which are not reset to known values, we have to work harder to
identify what is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together
with a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine
c = 73; result = add(7, 13); // that's a different Turing machine >>>>
We can't ignore the hidden static data which affects the
calculation, but if we identify it and control it then we can
characterize the conditions that give us a Turing machine.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine
that DD correctly simulated by HHH cannot possibly
reach its own "return" instruction final halt state.
It aborts its simulation and correctly returns 0
to indicate this.
DD isn't stuck if HHH(DD) returns zero.
Your system represents two different HHH functions in one function body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you need
functions. Procedures that access mutating static data are not
functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your situation
is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the decider
is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1) can
determine that DD isn't halting and return that indication.
But the DD test case is trying to show that HHD(..., 0) is not a valid
decider, not HH(..., 1). You cannot argue that DD does not show that
which it shows because HH(..., 1), a different decider, decides it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly decide.
That's the samea s removing the static data: keeping the flag the
same everywhere.
You can't use decider A to show that a test case which embeds decider B
can be decided, and then claim that halting undecidability is bunk; it
doesn't work.
The test case which embeds decider B shows that B is not a universal
halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which targets A.
When we eliminate the static data then it remains
true that the input to HHH(DD) remains stuck in
recursive simulation, yet HHH cannot know this
with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and restore
it around each HHHH call) then your system collectly exemplifies the
undecidability of halting, refuting your claims.
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer the
queston "am I the top-level HHH or not?" which is equivalent to passing
in a flag argument which splits it into two classes of decider.
HHH merely reports on the behavior specified by
this input: DD correctly simulated by HHH including
HHH simulating an instance of itself simulating an
instance of DD.
The current implementation of HHH does depend on
homemade static data for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static
data, such as a numeric or string literal.
If you want HHH to be a pure function, which you should, you must turn
every operand it depends on into a parameter of the function (every
operand that is not a literal constant). Also, the parameter must be a
value parameter, not a pointer to some mutable is effectively the same
as static data.
For each call to HHH, decide what arguments those extra parameters take
on and then realize that every distinct combination of those arguments
effectively gives rise to a different HHH.
When HHH(DD) is a pure function of its inputs and uses
no static data then both HHH(DD) and directly executed
DD() never stop running proving that HHH(DD)==0 is correct.
On 8/18/2025 12:57 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 12:55:44 -0500, olcott wrote:
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:When HHH(DD) is a pure function of its inputs and uses no static data
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:
On 2025-08-17, olcott <polcott333@gmail.com> wrote:int DD()
I think that you were the one that taught me about computable
functions. It still seems a little silly that C code can do things >>>>>>> that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can interface >>>>>> with the outside world and respond to real-time events and ocnditions >>>>>> that are never the same on any repeated run. Let's make it clear that >>>>>> this is not on the table at all.
C calculations that are deterministic are Turing computations.
But you have to know where to draw the chalk line around them to say >>>>>> "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables which are >>>>>> not reset to known values, we have to work harder to identify what is >>>>>> the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together with a >>>>>> specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine c = 73;
result = add(7, 13); // that's a different Turing machine >>>>>>
We can't ignore the hidden static data which affects the calculation, >>>>>> but if we identify it and control it then we can characterize the
conditions that give us a Turing machine.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine that DD correctly
simulated by HHH cannot possibly reach its own "return" instruction
final halt state.
It aborts its simulation and correctly returns 0 to indicate this.
DD isn't stuck if HHH(DD) returns zero.
Your system represents two different HHH functions in one function
body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you need
functions. Procedures that access mutating static data are not
functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your situation >>>> is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the decider >>>> is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1) can
determine that DD isn't halting and return that indication.
But the DD test case is trying to show that HHD(..., 0) is not a valid >>>> decider, not HH(..., 1). You cannot argue that DD does not show that
which it shows because HH(..., 1), a different decider, decides it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly
decide.
That's the samea s removing the static data: keeping the flag the same >>>> everywhere.
You can't use decider A to show that a test case which embeds decider B >>>> can be decided, and then claim that halting undecidability is bunk; it >>>> doesn't work.
The test case which embeds decider B shows that B is not a universal
halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which targets A. >>>>
When we eliminate the static data then it remains true that the input >>>>> to HHH(DD) remains stuck in recursive simulation, yet HHH cannot know >>>>> this with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and restore >>>> it around each HHHH call) then your system collectly exemplifies the
undecidability of halting, refuting your claims.
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer the
queston "am I the top-level HHH or not?" which is equivalent to passing >>>> in a flag argument which splits it into two classes of decider.
HHH merely reports on the behavior specified by this input: DD
correctly simulated by HHH including HHH simulating an instance of
itself simulating an instance of DD.
The current implementation of HHH does depend on homemade static data >>>>> for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static data, such as a
numeric or string literal.
If you want HHH to be a pure function, which you should, you must turn >>>> every operand it depends on into a parameter of the function (every
operand that is not a literal constant). Also, the parameter must be a >>>> value parameter, not a pointer to some mutable is effectively the same >>>> as static data.
For each call to HHH, decide what arguments those extra parameters take >>>> on and then realize that every distinct combination of those arguments >>>> effectively gives rise to a different HHH.
then both HHH(DD) and directly executed DD() never stop running proving
that HHH(DD)==0 is correct.
No. HHH(DD) has to report to the directly executed DD() otherwise HHH is
not a halt decider.
/Flibble
Turing machine deciders only compute the mapping
from their inputs...
Otherwise HHH is not any kind of decider at all.
On 8/18/2025 1:21 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 13:19:21 -0500, olcott wrote:
On 8/18/2025 12:57 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 12:55:44 -0500, olcott wrote:
On 8/18/2025 12:47 PM, Kaz Kylheku wrote:
On 2025-08-18, olcott <polcott333@gmail.com> wrote:When HHH(DD) is a pure function of its inputs and uses no static data >>>>> then both HHH(DD) and directly executed DD() never stop running
On 8/17/2025 8:02 PM, Kaz Kylheku wrote:DD isn't stuck if HHH(DD) returns zero.
On 2025-08-17, olcott <polcott333@gmail.com> wrote:int DD()
I think that you were the one that taught me about computable >>>>>>>>> functions. It still seems a little silly that C code can do things >>>>>>>>> that Turing machines cannot.
Well, yes it can and no it can't. Firstly, obviously C can
interface with the outside world and respond to real-time events >>>>>>>> and ocnditions that are never the same on any repeated run. Let's >>>>>>>> make it clear that this is not on the table at all.
C calculations that are deterministic are Turing computations. >>>>>>>> But you have to know where to draw the chalk line around them to >>>>>>>> say "that is the Turing machine".
We can have a pure function in C like
int add(int x, int y) { return x + y; }.
then something like add(7, 13) is a Turing computation. It is
self-contained, like the contents of a tape.
If we have a function that is looking at static variables which are >>>>>>>> not reset to known values, we have to work harder to identify what >>>>>>>> is the Turning machine there.
int c;
int add(int x, int y) { return x + y + c++; }.
Now add(7, 13) isn't a Turing machine, but add(7, 13) together with >>>>>>>> a specific value of c is:
c = 42; result = add(7, 13); // that's a Turing machine c =
73;
result = add(7, 13); // that's a different Turing machine >>>>>>>>
We can't ignore the hidden static data which affects the
calculation,
but if we identify it and control it then we can characterize the >>>>>>>> conditions that give us a Turing machine.
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
My C function HHH(DD) does correctly determine that DD correctly >>>>>>> simulated by HHH cannot possibly reach its own "return" instruction >>>>>>> final halt state.
It aborts its simulation and correctly returns 0 to indicate this. >>>>>>
Your system represents two different HHH functions in one function >>>>>> body,
by means of static variables to distinguish them.
The function call HHH(DD) is really HHH(DD, static_data).
If you're going to make functionl arguments about halting, you need >>>>>> functions. Procedures that access mutating static data are not
functions, but they can be if we parametrize that data.
If you make your static data explicit, you will see that your
situation is equivalent to this:
int HHH(int (*fn)(void)n, int root_flag);
int DD(void)
{
int halts = HHH(DD, 0);
if (halts)
for(;;);
return halts;
}
int main()
{
if (HHH(DD, 1))
puts("DD halts");
else
puts("DD doesn't halt");
return 0;
}
HHH(DD, 0) and HHH(DD, 1) are calls to different deciders; the
decider is parametrized by the static data.
Given this setup, of course everything you say holds: HHH(DD, 1) can >>>>>> determine that DD isn't halting and return that indication.
But the DD test case is trying to show that HHD(..., 0) is not a
valid decider, not HH(..., 1). You cannot argue that DD does not show >>>>>> that which it shows because HH(..., 1), a different decider, decides >>>>>> it.
If you call HHH(DD, 0) in main, /that/ decider doesn't correctly
decide.
That's the samea s removing the static data: keeping the flag the
same everywhere.
You can't use decider A to show that a test case which embeds decider >>>>>> B can be decided, and then claim that halting undecidability is bunk; >>>>>> it doesn't work.
The test case which embeds decider B shows that B is not a universal >>>>>> halting decider. It "targets" B.
A is irrelevant, and a separate test case can be spun which targets >>>>>> A.
When we eliminate the static data then it remains true that the
input to HHH(DD) remains stuck in recursive simulation, yet HHH
cannot know this with my currently coded HHH.
If we eliminate the static data (or else save, reinitialize and
restore it around each HHHH call) then your system collectly
exemplifies the undecidability of halting, refuting your claims.
The design of HHH is a pure function of its input.
Not with the static data, which allows HHH to internally answer the >>>>>> queston "am I the top-level HHH or not?" which is equivalent to
passing in a flag argument which splits it into two classes of
decider.
HHH merely reports on the behavior specified by this input: DD
correctly simulated by HHH including HHH simulating an instance of >>>>>>> itself simulating an instance of DD.
The current implementation of HHH does depend on homemade static >>>>>>> data for at least: execution_trace;
"pure function" and "depends on static data"
are incompatible, if the static data /mutates/.
A pure function can only depend on immutable static data, such as a >>>>>> numeric or string literal.
If you want HHH to be a pure function, which you should, you must
turn every operand it depends on into a parameter of the function
(every operand that is not a literal constant). Also, the parameter >>>>>> must be a value parameter, not a pointer to some mutable is
effectively the same as static data.
For each call to HHH, decide what arguments those extra parameters >>>>>> take on and then realize that every distinct combination of those
arguments effectively gives rise to a different HHH.
proving that HHH(DD)==0 is correct.
No. HHH(DD) has to report to the directly executed DD() otherwise HHH
is not a halt decider.
/Flibble
Turing machine deciders only compute the mapping from their inputs...
Otherwise HHH is not any kind of decider at all.
A halt decider needs to report a decision to its caller.
/Flibble
Yes. A halt decider cannot possibly report a decision
about the behavior OF ITS CALLER.
On 8/18/25 2:49 PM, olcott wrote:
Yes. A halt decider cannot possibly report a decision
about the behavior OF ITS CALLER.
Sure it can. sometimes.
On Mon, 2025-08-18 at 22:39 +0000, Dan Cross wrote:
In article <17b1db77236d2868926b14304ea2fd5a3d5ad3f2.camel@gmail.com>,
wij <wyniijj5@gmail.com> wrote:
olcott does not understand basic IF/AND/OR/NOT. This implies many.
Often, olcott cannot answer what other people says, people used to think olcott
has read and know (somewhat) what other people says. But not, olcott doesn't
understand (probably did not read, neither) and continue to rely, he just repeat
what he want to say, even though inconsistency (he does not understand >> > contradiction, basic logic).
Sine olcott does not understand basic logic, most CS terms, knowledge are >> > fabrication in his brain.
So, my solution is insist your unanswered question untill answered.
olcott is good at switching subject, otherwise discussion diverges to nothing.
The most efficient way to deal with Peter Olcott is to ignore
him.
Seriously. I was away for the weekend and I come back to over
400 messages in comp.theory from, to, or about Olcott.
Just ignore the guy already.
That is wise. But, since I already read it, I should extract something useful. >I found there is, because my interests is not limited to CS.
'fact' may not be what is thought.
The times that it lucks out and reports on
something else that has the same halt status
as its caller does not count as it reporting
on the behavior of its caller.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
On 8/18/2025 6:50 PM, Richard Heathfield wrote:
On 19/08/2025 00:31, olcott wrote:
<snip>
The times that it lucks out and reports on
something else that has the same halt status
as its caller does not count as it reporting
on the behavior of its caller.
You do realise that you're arguing here in favour of Turing?
There can be no universal decider because it can't decide on
itself, therefore some problems are undecidable.
The definition of Turing machines does not allow
it to report on itself
or its caller:
Turing machine deciders only compute the mapping
from their inputs...
People have not bothered to pay attention to that
for 89 years.
On 8/18/2025 7:33 PM, Richard Heathfield wrote:
On 19/08/2025 01:24, olcott wrote:
On 8/18/2025 6:50 PM, Richard Heathfield wrote:
On 19/08/2025 00:31, olcott wrote:
<snip>
The times that it lucks out and reports on
something else that has the same halt status
as its caller does not count as it reporting
on the behavior of its caller.
You do realise that you're arguing here in favour of Turing?
There can be no universal decider because it can't decide on
itself, therefore some problems are undecidable.
The definition of Turing machines does not allow
it to report on itself
Of course it does. A Turing machine can be described on a tape.
A Turing machine can read a tape. Tapes can be copied. Ergo, a
Turing machine can report on itself.
That only comes from being too damn sloppy with the
exact meaning of words. Yes a Turing machines can
report on the finite string description of itself.
This is not the same as it reporting on its actual
self.
On 8/18/2025 7:49 PM, Richard Heathfield wrote:
On 19/08/2025 01:42, olcott wrote:
On 8/18/2025 7:33 PM, Richard Heathfield wrote:
On 19/08/2025 01:24, olcott wrote:
On 8/18/2025 6:50 PM, Richard Heathfield wrote:
On 19/08/2025 00:31, olcott wrote:
<snip>
The times that it lucks out and reports on
something else that has the same halt status
as its caller does not count as it reporting
on the behavior of its caller.
You do realise that you're arguing here in favour of
Turing? There can be no universal decider because it can't
decide on itself, therefore some problems are undecidable.
The definition of Turing machines does not allow
it to report on itself
Of course it does. A Turing machine can be described on a
tape. A Turing machine can read a tape. Tapes can be copied.
Ergo, a Turing machine can report on itself.
That only comes from being too damn sloppy with the
exact meaning of words. Yes a Turing machines can
report on the finite string description of itself.
And a Turing machine can thus be described perfectly, so the
distinction is
stupidly ignored.
Turing machine deciders only compute the mapping
from their inputs...
No Turing machine full or partial halt decider has
ever been able to *directly* report on the behavior
of any other Turing machine.
On 8/18/2025 8:57 PM, Richard Heathfield wrote:
On 19/08/2025 02:42, olcott wrote:
<snip>
Turing machine deciders only compute the mapping
from their inputs...
TMs read their tapes. Yes, I know.
No Turing machine full or partial halt decider has
ever been able to *directly* report on the behavior
of any other Turing machine.
...except the ones described on the tapes they read. Don't
forget those.
Yes and whenever you are hungry you eat the word: "food"
because you can't understand the difference between direct
versus indirect reference.
When HHH(DD) is a pure function of its inputs and uses
no static data
then both HHH(DD) and directly executed
DD() never stop running proving that HHH(DD)==0 is correct.
On 8/18/2025 4:23 PM, joes wrote:
Am Mon, 18 Aug 2025 15:56:11 -0500 schrieb olcott:
On 8/18/2025 3:53 PM, joes wrote:
Am Mon, 18 Aug 2025 13:27:26 -0500 schrieb olcott:
On 8/18/2025 1:01 PM, dbush wrote:Wait, what? You’re *acknowledging* that HHH reports on
On 8/18/2025 1:55 PM, olcott wrote:
*Changing the decider/input pairs is required* nitwitWhen HHH(DD) is a pure function of its inputs and uses no static >>>>>>> data then both HHH(DD) and directly executed DD() never stopi.e. when you change the input.
running
proving that HHH(DD)==0 is correct.Nope. Changing the input is not allowed.
DD(){HHH_inf();}?
Exactly, „M” refers to many different machines.It is identical to the Peter Linz template that he uses as the basis ofI keep telling you that M is not a concrete machine!Too stupid to understand that M is a template specifying an infiniteI am not calling you a nitwit because you made a mistake. I amThat is what a nitwit would say.
calling you a nitwit because you keep making the same mistake after
many corrections.
set of machine / input pairs ?
his proof.
On 8/18/2025 8:57 PM, Richard Heathfield wrote:
On 19/08/2025 02:42, olcott wrote:
<snip>
Turing machine deciders only compute the mapping
from their inputs...
TMs read their tapes. Yes, I know.
No Turing machine full or partial halt decider has
ever been able to *directly* report on the behavior
of any other Turing machine.
...except the ones described on the tapes they read. Don't forget those.
Yes and whenever you are hungry you eat the word: "food"
because you can't understand the difference between direct
versus indirect reference.
On 8/18/2025 6:36 PM, Dan Cross wrote:
In article <80602321ce2144444b9f465411b3dbed789b53eb.camel@gmail.com>,
wij <wyniijj5@gmail.com> wrote:
On Mon, 2025-08-18 at 22:39 +0000, Dan Cross wrote:
[snip]
Just ignore the guy already.
That is wise. But, since I already read it, I should extract something useful.
I found there is, because my interests is not limited to CS.
'fact' may not be what is thought.
This feels like the sunk cost fallacy, to me.
Perhaps there is something to be learned by studying Olcott's
writings in some field, but that field is not computer science,
mathematics, the theory of computation, or any related field.
Maybe psychology or sociology. But in that case, comp.theory
isn't the right group.
Don't throw good money after bad, as they say.
[snip]
See, this is exactly what I'm talking about. The guy takes
literally every subthread, and just starts spewing his stuff
into it, regardless of whether it's topical or not. And then a
bunch of other people _respond to him_.
Just. Stop. Doing. That.
This problem would solve itself if people would stop engaging
with him; doing so only encourages him and perpetuates the
issue.
On 8/19/2025 3:11 AM, joes wrote:You know you gave it away.
Am Mon, 18 Aug 2025 16:36:00 -0500 schrieb olcott:
On 8/18/2025 4:23 PM, joes wrote:Which is not the input.
Am Mon, 18 Aug 2025 15:56:11 -0500 schrieb olcott:
On 8/18/2025 3:53 PM, joes wrote:
Am Mon, 18 Aug 2025 13:27:26 -0500 schrieb olcott:
On 8/18/2025 1:01 PM, dbush wrote:Wait, what? You’re *acknowledging* that HHH reports on
On 8/18/2025 1:55 PM, olcott wrote:
*Changing the decider/input pairs is required* nitwitWhen HHH(DD) is a pure function of its inputs and uses no static >>>>>>>>> data then both HHH(DD) and directly executed DD() never stop >>>>>>>>> runningi.e. when you change the input.
proving that HHH(DD)==0 is correct.Nope. Changing the input is not allowed.
DD(){HHH_inf();}?
Look, we all know how the proof goes. Mind actually admitting that MErasing this context seems dishonest.Exactly, „M” refers to many different machines.It is identical to the Peter Linz template that he uses as the basisI keep telling you that M is not a concrete machine!Too stupid to understand that M is a template specifying an infinite >>>>> set of machine / input pairs ?I am not calling you a nitwit because you made a mistake. I amThat is what a nitwit would say.
calling you a nitwit because you keep making the same mistake
after many corrections.
of his proof.
On 8/19/2025 10:01 AM, joes wrote:
Am Tue, 19 Aug 2025 09:32:46 -0500 schrieb olcott:
On 8/19/2025 3:11 AM, joes wrote:You know you gave it away.
Am Mon, 18 Aug 2025 16:36:00 -0500 schrieb olcott:
On 8/18/2025 4:23 PM, joes wrote:Which is not the input.
Am Mon, 18 Aug 2025 15:56:11 -0500 schrieb olcott:
On 8/18/2025 3:53 PM, joes wrote:
Am Mon, 18 Aug 2025 13:27:26 -0500 schrieb olcott:
On 8/18/2025 1:01 PM, dbush wrote:Wait, what? You’re *acknowledging* that HHH reports on
On 8/18/2025 1:55 PM, olcott wrote:
*Changing the decider/input pairs is required* nitwitWhen HHH(DD) is a pure function of its inputs and uses no static >>>>>>>>>>> data then both HHH(DD) and directly executed DD() never stop >>>>>>>>>>> runningi.e. when you change the input.
proving that HHH(DD)==0 is correct.Nope. Changing the input is not allowed.
DD(){HHH_inf();}?
Look, we all know how the proof goes. Mind actually admitting that MErasing this context seems dishonest.Exactly, „M” refers to many different machines.It is identical to the Peter Linz template that he uses as the basis >>>>> of his proof.I keep telling you that M is not a concrete machine!Too stupid to understand that M is a template specifying an infinite >>>>>>> set of machine / input pairs ?I am not calling you a nitwit because you made a mistake. I am >>>>>>>>> calling you a nitwit because you keep making the same mistake >>>>>>>>> after many corrections.That is what a nitwit would say.
is not a concrete machine?
It is dishonest to erase any context that is
being responded to. Please stop doing this.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 155:22:36 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,848 |