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

Groups > sci.math > #640346 > unrolled thread

Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022

Back to article view | Back to sci.math

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:00 -0500
    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-20 23:05 -0400
      Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:13 -0500
        Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-20 23:16 -0400
          Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:25 -0500
            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-20 23:29 -0400
    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 03:20 +0000
      Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:29 -0500
      Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 06:56 -0500
        Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 08:25 -0400
          Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 07:48 -0500
            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 09:00 -0400
              Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 08:47 -0500
                Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 09:50 -0400
                  Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 09:25 -0500
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Python <jpierre.messager@gmail.com> - 2025-10-22 14:27 +0000
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 13:30 -0400
        Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 15:40 +0000
          Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 10:47 -0500
            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 17:07 +0000
              Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 12:11 -0500
                Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 13:38 -0400
                Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 18:40 +0000
                  Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 André G. Isaak <agisaak@gm.invalid> - 2025-10-22 13:24 -0600
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 14:30 -0500
                      Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 15:31 -0400
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Richard Heathfield <rjh@cpax.org.uk> - 2025-10-22 20:34 +0100
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 19:52 +0000
                      Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 15:00 -0500
                        Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 20:20 +0000
                          Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 15:35 -0500
                            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 16:43 -0400
                          Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST olcott <polcott333@gmail.com> - 2025-10-22 16:12 -0500
                            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-22 14:32 -0700
                            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST dbush <dbush.mobile@gmail.com> - 2025-10-22 17:50 -0400
                            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 23:01 +0000
                              Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST olcott <polcott333@gmail.com> - 2025-10-23 09:55 -0500
                                Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 16:47 +0000
                                  "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 12:22 -0500
                                    Re: "there will still be a nested simulation tower" Kaz "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-23 11:50 -0700
                                    Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 21:11 +0000
                              "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 17:08 -0500
                                Re: "there will still be a nested simulation tower" Kaz "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-23 15:21 -0700
                                Re: "there will still be a nested simulation tower" Kaz "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-23 15:26 -0700
                                Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-23 18:40 -0400
                                  Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 17:48 -0500
                                    Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-23 19:09 -0400
                                    Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 23:55 +0000
                                      Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 19:00 -0500
                                Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 23:45 +0000
                                  Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 18:51 -0500
                                    Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-23 20:14 -0400
                          "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-22 17:14 -0500
                            Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-22 18:33 -0400
                            Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 23:15 +0000
                              Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-22 18:24 -0500
                                Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-22 20:14 -0400
                                Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 01:22 +0000
                              Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-22 20:47 -0500
                                Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-22 22:13 -0400
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Julio Di Egidio <julio@diegidio.name> - 2025-10-23 08:02 +0200
                      Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-23 09:51 -0500
                  Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 14:55 -0500
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 16:24 -0400
                    Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 21:55 +0000
            Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 13:36 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#640474 — Re: "there will still be a nested simulation tower" Kaz

On 2025-10-23, olcott <polcott333@gmail.com> wrote:
> On 10/23/2025 11:47 AM, Kaz Kylheku wrote:
>> On 2025-10-23, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>>
>>>>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>>> description of HHH.
>>>>>>>>
>>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>>>> but the same algorithm: a workalike.
>>>>>>>>
>>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>>> called by DD could be in Python.
>>>>>>>
>>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>>> and you try to get away with lying about it.
>>>>>>
>>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>>
>>>>>> DD does not have to use that implementation of HHH; it can have
>>>>>> its own clean-room implementation and it can be in any language.
>>>>>>
>>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>>
>>>>>
>>>>> I made sure to read what you said all the way through
>>>>> this time. DD correctly simulated by HHH cannot possibly
>>>>> reach its own final halt state no matter what HHH does.
>>>>
>>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>>> state of DD, which DD undeniably /has/.
>>>>
>>> *Hence the halting problem is wrong*
>> 
>> The much simpler explanation is that the decider is wrong. 
>
> https://www.liarparadox.org/Simple_but_Wrong.png

As a general remark, liardparadox.org is a site under your own control
and so sheds no light on anything; it just repeats the claims you make
in comp.theory.

I have thoroughly refuted the lazy, intellectually immature and illogical
idea that the halting problem involves anything equivalent to the
liar paradox.

Turing machines do not proclaim a statement, and do not self-contradict.

Even among sentences which appear to state a truth, and which are
self-referential, not all such sentences are ill-formed paradoxes.

"This sentence has five words." is self-referential and truth bearing;
its value is true.

Your repeated claim that halting involves something closely analogous
to the Liar Paradox is completely unfounded, not supported by a shred
of rational evidence.

>>> The halting problem requires that halt deciders do what
>>> no Turing machine decider can do report on the semantic
>>> property of non-inputs.
>> 
>> It positively doesn't. 
>
> HHH(DD) does report on the behavior that its actual
> input actually specifies:

Yes; it does, as required.

That input has one and only one behavior, which is halting.

Thus, the 0 report is incorrect.

It meets the requirements for what to report on,
but not the requirement for correctness.

> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
> > there will still be a nested simulation tower
>
> The halting problem requires HHH(DD) to report on
> something else, QED the halting problem is wrong.

It does not; it requires HHH(DD) to report on the actual behavior of
input DD.

That input DD starts its own instance of an algorithm equivalent to the
one used by HHH, and applies that to itself. Then it behaves in a way
which ensures that the result does not match its behavior.

That whole thing encoded in the finite string input, and is its
behavior. 

> Turing machine deciders only compute the mapping
> from their finite string inputs to an accept state
> or reject state on the basis that this input finite
> string specifies a semantic or syntactic property.

The DD input definitely specifies these properties. It it well-formed
code that can be executed, and that reaches termination.

> This means that the ultimate measure of the behavior
> that a finite string input D specifies is D correctly
> simulated by simulating halt decider H.

For that, a simulator is needed which doesn't abort, because
correctly implies completely. We have been calling one such
decider by the name HHH1. HHH1 does nothing but simulate.

HHH1(DD) finds that DD terminates and returns 1.

Thus it carries out the "ultimate measure".

HHH fails to simulate DD to the end the way HHH1 does and therefore
does not perform the "ultimate measure".

> The halting problem requires that halt deciders do what
> no Turing machine decider can do report on the semantic
> property of non-inputs.

It simply doesn't. This claim is not based in reality, and is delivered
without rational justification.

The halting problem is simply the question, can there exist an algorithm
for deciding (i.e. calculating in a finite number of steps) the halting
status of /any/ algorithm?

Through meticulous logic, we have derived the answer that no, an
algorithm which decides the halting of all algorithms, does not exist.

In no way does the halting problem require "non-inputs", whatever those
are.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#640475 — "there will still be a nested simulation tower" Kaz

On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>> which is a property of DD, which is a finite string.
>>>>>>
>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>> description of HHH.
>>>>>
>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>> but the same algorithm: a workalike.
>>>>>
>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>> called by DD could be in Python.
>>>>
>>>> DD does call HHH(DD) in recursive simulation
>>>> and you try to get away with lying about it.
>>>
>>> I'm saying that's not a requirement in the halting problem.
>>>
>>> DD does not have to use that implementation of HHH; it can have
>>> its own clean-room implementation and it can be in any language.
>>>
>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>
>>
>> I made sure to read what you said all the way through
>> this time. DD correctly simulated by HHH cannot possibly
>> reach its own final halt state no matter what HHH does.
> 
> The /simulation/ of DD by HHH will not /reproduce/ the halt
> state of DD, which DD undeniably /has/.
> 

The finite string as an actual input to HHH(DD)
*does not have the halting property*

Turing machine deciders only compute the mapping
from their finite string inputs

Turing machine deciders only compute the mapping
from their finite string inputs

Turing machine deciders only compute the mapping
from their finite string inputs

The DD that has the halting property is not an input
The DD that has the halting property is not an input
The DD that has the halting property is not an input

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640476 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 3:08 PM, olcott wrote:
> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>> behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>> that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> I made sure to read what you said all the way through
>>> this time. DD correctly simulated by HHH cannot possibly
>>> reach its own final halt state no matter what HHH does.
>>
>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>> state of DD, which DD undeniably /has/.
>>
> 
> The finite string as an actual input to HHH(DD)
> *does not have the halting property*
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> The DD that has the halting property is not an input
> The DD that has the halting property is not an input
> The DD that has the halting property is not an input
> 

Your DD relies on what HHH(DD) returns and acts accordingly.

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

#640477 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 3:08 PM, olcott wrote:
> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>> behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>> that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> I made sure to read what you said all the way through
>>> this time. DD correctly simulated by HHH cannot possibly
>>> reach its own final halt state no matter what HHH does.
>>
>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>> state of DD, which DD undeniably /has/.
>>
> 
> The finite string as an actual input to HHH(DD)
> *does not have the halting property*
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> The DD that has the halting property is not an input
> The DD that has the halting property is not an input
> The DD that has the halting property is not an input
> 

DD relies on HHH(DD)'s return value. It can halt, or no halt.

If HHH(DD) never returns, its not a simulation of DD.

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

#640479 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 6:08 PM, olcott wrote:
> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>> behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>> that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> I made sure to read what you said all the way through
>>> this time. DD correctly simulated by HHH cannot possibly
>>> reach its own final halt state no matter what HHH does.
>>
>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>> state of DD, which DD undeniably /has/.
>>
> 
> The finite string as an actual input to HHH(DD)

i.e. finite string DD which is the description of machine DD and 
therefore is stipulated to specify all semantic properties of the 
described machine, including halting when executed directly.

> *does not have the halting property*

False, see above.>
> Turing machine deciders only compute the mapping
> from their finite string inputs

And the finite string input DD has the halting property as show above.

> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> Turing machine deciders only compute the mapping
> from their finite string inputs
> 
> The DD that has the halting property 

i.e. finite string DD which is an input to HH

> is not an input
False, see above.

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

#640482 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 5:40 PM, dbush wrote:
> On 10/23/2025 6:08 PM, olcott wrote:
>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>>> behavior,
>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>
>>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>>> that the
>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>> description of HHH.
>>>>>>>
>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be 
>>>>>>> HHH,
>>>>>>> but the same algorithm: a workalike.
>>>>>>>
>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>> called by DD could be in Python.
>>>>>>
>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>> and you try to get away with lying about it.
>>>>>
>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>
>>>>> DD does not have to use that implementation of HHH; it can have
>>>>> its own clean-room implementation and it can be in any language.
>>>>>
>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>
>>>>
>>>> I made sure to read what you said all the way through
>>>> this time. DD correctly simulated by HHH cannot possibly
>>>> reach its own final halt state no matter what HHH does.
>>>
>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>> state of DD, which DD undeniably /has/.
>>>
>>
>> The finite string as an actual input to HHH(DD)
> 
> i.e. finite string DD which is the description of machine DD and 
> therefore is stipulated to specify all semantic properties of the 
> described machine, including halting when executed directly.
> 
>> *does not have the halting property*
> 
> False, see above.>
>> Turing machine deciders only compute the mapping
>> from their finite string inputs
> 
> And the finite string input DD has the halting property as show above.
> 
>>
>> Turing machine deciders only compute the mapping
>> from their finite string inputs
>>
>> Turing machine deciders only compute the mapping
>> from their finite string inputs
>>
>> The DD that has the halting property 
> 
> i.e. finite string DD which is an input to HH
> 
>> is not an input
> False, see above.

Correct simulation is defined as simulation
according to the semantics of the specification
language: C, x86 or TM description.

The execution trace of DD correctly simulated
by HHH differs from the execution trace of
DD correctly simulated HHH1 proving that I
am right and you are stupid or dishonest.

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640483 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 6:48 PM, olcott wrote:
> On 10/23/2025 5:40 PM, dbush wrote:
>> On 10/23/2025 6:08 PM, olcott wrote:
>>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>>>> behavior,
>>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>>
>>>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>>>> that the
>>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>>> description of HHH.
>>>>>>>>
>>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be 
>>>>>>>> HHH,
>>>>>>>> but the same algorithm: a workalike.
>>>>>>>>
>>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>>> called by DD could be in Python.
>>>>>>>
>>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>>> and you try to get away with lying about it.
>>>>>>
>>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>>
>>>>>> DD does not have to use that implementation of HHH; it can have
>>>>>> its own clean-room implementation and it can be in any language.
>>>>>>
>>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>>
>>>>>
>>>>> I made sure to read what you said all the way through
>>>>> this time. DD correctly simulated by HHH cannot possibly
>>>>> reach its own final halt state no matter what HHH does.
>>>>
>>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>>> state of DD, which DD undeniably /has/.
>>>>
>>>
>>> The finite string as an actual input to HHH(DD)
>>
>> i.e. finite string DD which is the description of machine DD and 
>> therefore is stipulated to specify all semantic properties of the 
>> described machine, including halting when executed directly.
>>
>>> *does not have the halting property*
>>
>> False, see above.>
>>> Turing machine deciders only compute the mapping
>>> from their finite string inputs
>>
>> And the finite string input DD has the halting property as show above.
>>
>>>
>>> Turing machine deciders only compute the mapping
>>> from their finite string inputs
>>>
>>> Turing machine deciders only compute the mapping
>>> from their finite string inputs
>>>
>>> The DD that has the halting property 
>>
>> i.e. finite string DD which is an input to HH
>>
>>> is not an input
>> False, see above.
> 
> Correct simulation is defined as simulation
> according to the semantics of the specification
> language: C, x86 or TM description.

And because aborting is against the semantics of those languages, HHH 
doesn't do a correct simulation.

> 
> The execution trace of DD correctly simulated
> by HHH 
Does not exist because HHH aborts.


And since none of what you've written directly addresses my prior post, 
you've implicitly agreed that the above points are correct, specifically 
that the input to HHH(DD) specifies halting behavior.

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

#640487 — Re: "there will still be a nested simulation tower" Kaz

On 2025-10-23, olcott <polcott333@gmail.com> wrote:
> On 10/23/2025 5:40 PM, dbush wrote:
>> On 10/23/2025 6:08 PM, olcott wrote:
>>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>>>> behavior,
>>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>>
>>>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>>>> that the
>>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>>> description of HHH.
>>>>>>>>
>>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be 
>>>>>>>> HHH,
>>>>>>>> but the same algorithm: a workalike.
>>>>>>>>
>>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>>> called by DD could be in Python.
>>>>>>>
>>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>>> and you try to get away with lying about it.
>>>>>>
>>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>>
>>>>>> DD does not have to use that implementation of HHH; it can have
>>>>>> its own clean-room implementation and it can be in any language.
>>>>>>
>>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>>
>>>>>
>>>>> I made sure to read what you said all the way through
>>>>> this time. DD correctly simulated by HHH cannot possibly
>>>>> reach its own final halt state no matter what HHH does.
>>>>
>>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>>> state of DD, which DD undeniably /has/.
>>>>
>>>
>>> The finite string as an actual input to HHH(DD)
>> 
>> i.e. finite string DD which is the description of machine DD and 
>> therefore is stipulated to specify all semantic properties of the 
>> described machine, including halting when executed directly.
>> 
>>> *does not have the halting property*
>> 
>> False, see above.>
>>> Turing machine deciders only compute the mapping
>>> from their finite string inputs
>> 
>> And the finite string input DD has the halting property as show above.
>> 
>>>
>>> Turing machine deciders only compute the mapping
>>> from their finite string inputs
>>>
>>> Turing machine deciders only compute the mapping
>>> from their finite string inputs
>>>
>>> The DD that has the halting property 
>> 
>> i.e. finite string DD which is an input to HH
>> 
>>> is not an input
>> False, see above.
>
> Correct simulation is defined as simulation
> according to the semantics of the specification
> language: C, x86 or TM description.

Correct simulation must continue while the
final instruction has not been reached.

The correct simulation of a non-terminating machine
never stops.

The correct simulation of a terminating machine
must reach its halt state.

> The execution trace of DD correctly simulated
> by HHH differs from the execution trace of
> DD correctly simulated HHH1 proving that I
> am right and you are stupid or dishonest.

Someone idenfiable as an engineer, and not necessarily even
a great one, will immediately know that if two simulations
(of a deterministic program that has a single behavior)
do not agree, /at most/ one of them can be called "correct".

They could be both wrong, but they cannot be both right.

If you think so, then obviously you must be stupid
or dishonest.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#640488 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 6:55 PM, Kaz Kylheku wrote:
> On 2025-10-23, olcott <polcott333@gmail.com> wrote:
>> On 10/23/2025 5:40 PM, dbush wrote:
>>> On 10/23/2025 6:08 PM, olcott wrote:
>>>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>>>> But that entire bundle is one fixed case DD, with a single
>>>>>>>>>>> behavior,
>>>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>>>
>>>>>>>>>> I think part of the problem here is that Olcott doesn't grasp
>>>>>>>>>> that the
>>>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>>>> description of HHH.
>>>>>>>>>
>>>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be
>>>>>>>>> HHH,
>>>>>>>>> but the same algorithm: a workalike.
>>>>>>>>>
>>>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>>>> called by DD could be in Python.
>>>>>>>>
>>>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>>>> and you try to get away with lying about it.
>>>>>>>
>>>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>>>
>>>>>>> DD does not have to use that implementation of HHH; it can have
>>>>>>> its own clean-room implementation and it can be in any language.
>>>>>>>
>>>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>>>
>>>>>>
>>>>>> I made sure to read what you said all the way through
>>>>>> this time. DD correctly simulated by HHH cannot possibly
>>>>>> reach its own final halt state no matter what HHH does.
>>>>>
>>>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>>>> state of DD, which DD undeniably /has/.
>>>>>
>>>>
>>>> The finite string as an actual input to HHH(DD)
>>>
>>> i.e. finite string DD which is the description of machine DD and
>>> therefore is stipulated to specify all semantic properties of the
>>> described machine, including halting when executed directly.
>>>
>>>> *does not have the halting property*
>>>
>>> False, see above.>
>>>> Turing machine deciders only compute the mapping
>>>> from their finite string inputs
>>>
>>> And the finite string input DD has the halting property as show above.
>>>
>>>>
>>>> Turing machine deciders only compute the mapping
>>>> from their finite string inputs
>>>>
>>>> Turing machine deciders only compute the mapping
>>>> from their finite string inputs
>>>>
>>>> The DD that has the halting property
>>>
>>> i.e. finite string DD which is an input to HH
>>>
>>>> is not an input
>>> False, see above.
>>
>> Correct simulation is defined as simulation
>> according to the semantics of the specification
>> language: C, x86 or TM description.
> 
> Correct simulation must continue while the
> final instruction has not been reached.
> 
> The correct simulation of a non-terminating machine
> never stops.
> 
> The correct simulation of a terminating machine
> must reach its halt state.
> 
>> The execution trace of DD correctly simulated
>> by HHH differs from the execution trace of
>> DD correctly simulated HHH1 proving that I
>> am right and you are stupid or dishonest.
> 
> Someone idenfiable as an engineer, and not necessarily even
> a great one, will immediately know that if two simulations
> (of a deterministic program that has a single behavior)
> do not agree, /at most/ one of them can be called "correct".
> 

Until that bother to actually pay complete attention
then they will suddenly realize that the behavior of
DD correctly simulated by HHH specifies non-terminating
recursive simulation that cannot possibly reach its
own simulated final halt state.

This is why I have to tell ChatGPT: do not assume
one damn thing work through all the actual steps
and see what you find.

> They could be both wrong, but they cannot be both right.
> 
> If you think so, then obviously you must be stupid
> or dishonest.
> 


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640485 — Re: "there will still be a nested simulation tower" Kaz

On 2025-10-23, olcott <polcott333@gmail.com> wrote:
> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> I made sure to read what you said all the way through
>>> this time. DD correctly simulated by HHH cannot possibly
>>> reach its own final halt state no matter what HHH does.
>> 
>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>> state of DD, which DD undeniably /has/.
>> 
>
> The finite string as an actual input to HHH(DD)
> *does not have the halting property*

It obviously does. You can directly executed it, meticulously following
every instruction according to the x86 instruction set, showing that it
reaches the final RET.

> The DD that has the halting property is not an input

Yes it is. The DD that has the halting property meets the definition of
being a finite string which has the right form and halting semantics.

> The DD that has the halting property is not an input

You can repeat it all you like, but you have not a shred of rational
justification for this. Other than some hand-waving nonsense about liar
paradoxes, incorrect questions, persons (who can randomly change their
answer being asked a question) rather than formal machines or pure
functions, and whatnot.

None of your rambling on these topics amounts to any rational proof
of anything.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#640486 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 6:45 PM, Kaz Kylheku wrote:
> On 2025-10-23, olcott <polcott333@gmail.com> wrote:
>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>
>>>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>> description of HHH.
>>>>>>>
>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>>> but the same algorithm: a workalike.
>>>>>>>
>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>> called by DD could be in Python.
>>>>>>
>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>> and you try to get away with lying about it.
>>>>>
>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>
>>>>> DD does not have to use that implementation of HHH; it can have
>>>>> its own clean-room implementation and it can be in any language.
>>>>>
>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>
>>>>
>>>> I made sure to read what you said all the way through
>>>> this time. DD correctly simulated by HHH cannot possibly
>>>> reach its own final halt state no matter what HHH does.
>>>
>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>> state of DD, which DD undeniably /has/.
>>>
>>
>> The finite string as an actual input to HHH(DD)
>> *does not have the halting property*
> 
> It obviously does. 
The show all the steps of DD simulated by HHH
according to the semantics of the C programming
language where DD reaches its own final halt
state by pure simulation with no inference by
anything.

This is exactly what I mean:

int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   UTM(DD);
}


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640489 — Re: "there will still be a nested simulation tower" Kaz

On 10/23/2025 7:51 PM, olcott wrote:
> On 10/23/2025 6:45 PM, Kaz Kylheku wrote:
>> On 2025-10-23, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 6:01 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>>>> behavior,
>>>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>>>
>>>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>>>> that the
>>>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>>>> description of HHH.
>>>>>>>>
>>>>>>>> Furthermore, he doesn't get that it doesn't literally have to be 
>>>>>>>> HHH,
>>>>>>>> but the same algorithm: a workalike.
>>>>>>>>
>>>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>>>> called by DD could be in Python.
>>>>>>>
>>>>>>> DD does call HHH(DD) in recursive simulation
>>>>>>> and you try to get away with lying about it.
>>>>>>
>>>>>> I'm saying that's not a requirement in the halting problem.
>>>>>>
>>>>>> DD does not have to use that implementation of HHH; it can have
>>>>>> its own clean-room implementation and it can be in any language.
>>>>>>
>>>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>>>
>>>>>
>>>>> I made sure to read what you said all the way through
>>>>> this time. DD correctly simulated by HHH cannot possibly
>>>>> reach its own final halt state no matter what HHH does.
>>>>
>>>> The /simulation/ of DD by HHH will not /reproduce/ the halt
>>>> state of DD, which DD undeniably /has/.
>>>>
>>>
>>> The finite string as an actual input to HHH(DD)
>>> *does not have the halting property*
>>
>> It obviously does. 
> The show all the steps of DD simulated by HHH
> according to the semantics of the C programming
> language where DD reaches its own final halt
> state by pure simulation with no inference by
> anything.
> 
> This is exactly what I mean:
> 
> int DD()
> {
>    int Halt_Status = UTM(DD);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> int main()
> {
>    UTM(DD);
> }
> 
> 

That's not DD.  That's DD' which is irrelevant.

If you claim HHH(DD) must decide the above code DD', which is not the 
code it was given, then HHH(DD) is deciding on a non-input.

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

#640430 — "there will still be a nested simulation tower" Kaz

On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>> which is a property of DD, which is a finite string.
>>>>
>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>> "finite string input" DD *must* include as a substring the entire
>>>> description of HHH.
>>>
>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>> but the same algorithm: a workalike.
>>>
>>> The HHH analyzing DD's halting could be in C, while the HHH
>>> called by DD could be in Python.
>>
>> DD does call HHH(DD) in recursive simulation
>> and you try to get away with lying about it.
> 
> I'm saying that's not a requirement in the halting problem.
> 
> DD does not have to use that implementation of HHH; it can have
> its own clean-room implementation and it can be in any language.
> 
> But nonetheless, yes, there will still be a nested simulation tower.
> 

Thus proving that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt
state no matter what HHH does.


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640432 — Re: "there will still be a nested simulation tower" Kaz

On 10/22/2025 6:14 PM, olcott wrote:
> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>> which is a property of DD, which is a finite string.
>>>>>
>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>> "finite string input" DD *must* include as a substring the entire
>>>>> description of HHH.
>>>>
>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>> but the same algorithm: a workalike.
>>>>
>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>> called by DD could be in Python.
>>>
>>> DD does call HHH(DD) in recursive simulation
>>> and you try to get away with lying about it.
>>
>> I'm saying that's not a requirement in the halting problem.
>>
>> DD does not have to use that implementation of HHH; it can have
>> its own clean-room implementation and it can be in any language.
>>
>> But nonetheless, yes, there will still be a nested simulation tower.
>>
> 
> Thus proving that DD correctly simulated by HHH

Does not exist because HHH aborts

> cannot possibly reach its own simulated final halt
> state no matter what HHH does.

Category error: algorithm HHH does one thing and one thing only, and 
that is an incomplete and therefore incorrect simulation.

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

#640434 — Re: "there will still be a nested simulation tower" Kaz

On 2025-10-22, olcott <polcott333@gmail.com> wrote:
> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>> which is a property of DD, which is a finite string.
>>>>>
>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>> "finite string input" DD *must* include as a substring the entire
>>>>> description of HHH.
>>>>
>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>> but the same algorithm: a workalike.
>>>>
>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>> called by DD could be in Python.
>>>
>>> DD does call HHH(DD) in recursive simulation
>>> and you try to get away with lying about it.
>> 
>> I'm saying that's not a requirement in the halting problem.
>> 
>> DD does not have to use that implementation of HHH; it can have
>> its own clean-room implementation and it can be in any language.
>> 
>> But nonetheless, yes, there will still be a nested simulation tower.
>> 
>
> Thus proving that DD correctly simulated by HHH
> cannot possibly reach its own simulated final halt
> state no matter what HHH does.

I explained that a nested simulation tower is two dimensional.

One dimension is the simulation level, the nesting itself;
that goes out to infinity. Due to the aborting behavior of HHH,
it is not actually realized in simulation; we have to step
through the aborted simulations to keep it going.

The other dimension is the execution /within/ the simulations.
That can be halting or non-halting.

In the HHH(DD) simulation tower, though that is infinite,
the simulations are halting.

I said that before. Your memory of that has vaporized, and you have now
focused only on my statement that the simluation tower is infinite.

The depth of the simulation tower, and the halting of the simulations
within that tower, are independent phenomena.

A decider must not mistake one for the other.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#640435 — Re: "there will still be a nested simulation tower" Kaz

On 10/22/2025 6:15 PM, Kaz Kylheku wrote:
> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>> which is a property of DD, which is a finite string.
>>>>>>
>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>> description of HHH.
>>>>>
>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>> but the same algorithm: a workalike.
>>>>>
>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>> called by DD could be in Python.
>>>>
>>>> DD does call HHH(DD) in recursive simulation
>>>> and you try to get away with lying about it.
>>>
>>> I'm saying that's not a requirement in the halting problem.
>>>
>>> DD does not have to use that implementation of HHH; it can have
>>> its own clean-room implementation and it can be in any language.
>>>
>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>
>>
>> Thus proving that DD correctly simulated by HHH
>> cannot possibly reach its own simulated final halt
>> state no matter what HHH does.
> 
> I explained that a nested simulation tower is two dimensional.
> 
> One dimension is the simulation level, the nesting itself;
> that goes out to infinity. 

Great. Thus the input to HHH(DD) specifies behavior
such that the correctly simulated DD cannot possibly
reach its own simulated final halt state.

> Due to the aborting behavior of HHH,
> it is not actually realized in simulation; we have to step
> through the aborted simulations to keep it going.
> 
> The other dimension is the execution /within/ the simulations.
> That can be halting or non-halting.
> 
> In the HHH(DD) simulation tower, though that is infinite,
> the simulations are halting.
> 
> I said that before. Your memory of that has vaporized, and you have now
> focused only on my statement that the simluation tower is infinite.
> 
> The depth of the simulation tower, and the halting of the simulations
> within that tower, are independent phenomena.
> 
> A decider must not mistake one for the other.
> 


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640436 — Re: "there will still be a nested simulation tower" Kaz

On 10/22/2025 7:24 PM, olcott wrote:
> On 10/22/2025 6:15 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>> behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>> that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> Thus proving that DD correctly simulated by HHH
>>> cannot possibly reach its own simulated final halt
>>> state no matter what HHH does.
>>
>> I explained that a nested simulation tower is two dimensional.
>>
>> One dimension is the simulation level, the nesting itself;
>> that goes out to infinity. 
> 
> Great. Thus the input to HHH(DD) 

i.e. finite string DD which is the description of machine DD i.e. <DD> 
and therefore stipulated to specify all semantic properties of machine 
DD including the fact that it halts when executed directly.

> specifies behavior
> such that the correctly simulated DD 

i.e. UTM(DD)

> cannot possibly
> reach its own simulated final halt state.

False, as proven by UTM(DD) halting.

> 
>> Due to the aborting behavior of HHH,
>> it is not actually realized in simulation; we have to step
>> through the aborted simulations to keep it going.
>>
>> The other dimension is the execution /within/ the simulations.
>> That can be halting or non-halting.
>>
>> In the HHH(DD) simulation tower, though that is infinite,
>> the simulations are halting.
>>
>> I said that before. Your memory of that has vaporized, and you have now
>> focused only on my statement that the simluation tower is infinite.
>>
>> The depth of the simulation tower, and the halting of the simulations
>> within that tower, are independent phenomena.
>>
>> A decider must not mistake one for the other.
>>
> 
> 

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

#640437 — Re: "there will still be a nested simulation tower" Kaz

On 2025-10-22, olcott <polcott333@gmail.com> wrote:
> On 10/22/2025 6:15 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> Thus proving that DD correctly simulated by HHH
>>> cannot possibly reach its own simulated final halt
>>> state no matter what HHH does.
>> 
>> I explained that a nested simulation tower is two dimensional.
>> 
>> One dimension is the simulation level, the nesting itself;
>> that goes out to infinity. 
>
> Great. Thus the input to HHH(DD) specifies behavior
> such that the correctly simulated DD cannot possibly
> reach its own simulated final halt state.

People replying to you respond to multiple points. Yet you typically
only read one point of a response.

You snipped all this:

>> Due to the aborting behavior of HHH,
>> it is not actually realized in simulation; we have to step
>> through the aborted simulations to keep it going.
>> 
>> The other dimension is the execution /within/ the simulations.
>> That can be halting or non-halting.
>> 
>> In the HHH(DD) simulation tower, though that is infinite,
>> the simulations are halting.
>> 
>> I said that before. Your memory of that has vaporized, and you have now
>> focused only on my statement that the simluation tower is infinite.
>> 
>> The depth of the simulation tower, and the halting of the simulations
>> within that tower, are independent phenomena.
>> 
>> A decider must not mistake one for the other.

There being endless nested simulations doesn't imply that the
simulations are nonterminating.

If we simply do this:

  void fun(void)
  {
     sim_t s = simulation_create(fun);
     return;
  }

we get an infinite tower of simulations, all of which terminate.

When fun() is called, it creates a simulation beginning at fun.
No step of this simulation is performed, yet it exists.

Then fun terminates.

No simulation has actually started, but we have a simuation
state which implies an infnite tower.

If the simulation s abandoned by fun is stepped, then soon,
inside that simulation, fun wil be called, and will create another
simulation and exit.

Then if we simulate that the same thing will happen.

Suppose the simulation_create module provides a simulate_run
function which identifies all/any unfinished simulations and
runs them.

Then if we do this:

  int main()
  {
     fun();
     simulate_run();
  }

simulate_run() will get into an infinite loop inside of
which it is always completing simulations of fun, which
are creating new simulations.

That won't even run out of memory because it's not recursion.

simulation_create() dynamically allocates a simulation.  If
simulation_run() calls simulation_destroy() whenever it detects that it
has completed a simulation, then I think thesituation can hit a steady
state; it runs forever, continuously launching and terminating
simulations.

But we cannot call fun itself non-halting. It has facilitated
the infinite generation of simulations, but is itself halting.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#640438 — Re: "there will still be a nested simulation tower" Kaz

On 10/22/2025 6:15 PM, Kaz Kylheku wrote:
> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>> But that entire bundle is one fixed case DD, with a single behavior,
>>>>>>> which is a property of DD, which is a finite string.
>>>>>>
>>>>>> I think part of the problem here is that Olcott doesn't grasp that the
>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>> description of HHH.
>>>>>
>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>> but the same algorithm: a workalike.
>>>>>
>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>> called by DD could be in Python.
>>>>
>>>> DD does call HHH(DD) in recursive simulation
>>>> and you try to get away with lying about it.
>>>
>>> I'm saying that's not a requirement in the halting problem.
>>>
>>> DD does not have to use that implementation of HHH; it can have
>>> its own clean-room implementation and it can be in any language.
>>>
>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>
>>
>> Thus proving that DD correctly simulated by HHH
>> cannot possibly reach its own simulated final halt
>> state no matter what HHH does.
> 
> I explained that a nested simulation tower is two dimensional.
> 
> One dimension is the simulation level, the nesting itself;
> that goes out to infinity. 

Great. Thus the input to HHH(DD) specifies behavior
such that the correctly simulated DD cannot possibly
reach its own simulated final halt state.

*The above point is the only relevant point to my proof*

We need to proceed from this one point to the next points
that are semantically entailed from this one point then
we have my whole proof.

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#640439 — Re: "there will still be a nested simulation tower" Kaz

On 10/22/2025 9:47 PM, olcott wrote:
> On 10/22/2025 6:15 PM, Kaz Kylheku wrote:
>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote:
>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote:
>>>>>> On 2025-10-22, André G  Isaak <agisaak@gm.invalid> wrote:
>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote:
>>>>>>>> But that entire bundle is one fixed case DD, with a single 
>>>>>>>> behavior,
>>>>>>>> which is a property of DD, which is a finite string.
>>>>>>>
>>>>>>> I think part of the problem here is that Olcott doesn't grasp 
>>>>>>> that the
>>>>>>> "finite string input" DD *must* include as a substring the entire
>>>>>>> description of HHH.
>>>>>>
>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH,
>>>>>> but the same algorithm: a workalike.
>>>>>>
>>>>>> The HHH analyzing DD's halting could be in C, while the HHH
>>>>>> called by DD could be in Python.
>>>>>
>>>>> DD does call HHH(DD) in recursive simulation
>>>>> and you try to get away with lying about it.
>>>>
>>>> I'm saying that's not a requirement in the halting problem.
>>>>
>>>> DD does not have to use that implementation of HHH; it can have
>>>> its own clean-room implementation and it can be in any language.
>>>>
>>>> But nonetheless, yes, there will still be a nested simulation tower.
>>>>
>>>
>>> Thus proving that DD correctly simulated by HHH
>>> cannot possibly reach its own simulated final halt
>>> state no matter what HHH does.
>>
>> I explained that a nested simulation tower is two dimensional.
>>
>> One dimension is the simulation level, the nesting itself;
>> that goes out to infinity. 
> 
> Great. Thus the input to HHH(DD) specifies behavior
> such that the correctly simulated DD cannot possibly
> reach its own simulated final halt state.

Repeat of previously refuted point:

On 10/22/2025 8:14 PM, dbush wrote:
 > On 10/22/2025 7:24 PM, olcott wrote:
 >> Great. Thus the input to HHH(DD)
 >
 > i.e. finite string DD which is the description of machine DD i.e. <DD>
 > and therefore stipulated to specify all semantic properties of machine
 > DD including the fact that it halts when executed directly.
 >
 >> specifies behavior
 >> such that the correctly simulated DD
 >
 > i.e. UTM(DD)
 >
 >> cannot possibly
 >> reach its own simulated final halt state.
 >
 > False, as proven by UTM(DD) halting.

This constitutes your admission that:
1) the prior refutation is correct
2) the point you are responding to is correct

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | sci.math

csiph-web