Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott2@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: We finally know exactly how H1(D,D) derives a different result
 than H(D,D)
Date: Fri, 8 Mar 2024 01:07:02 -0600
Organization: A noiseless patient Spider
Lines: 304
Message-ID: <useden$1ie34$1@dont-email.me>
References: <usda7b$18hee$1@dont-email.me> <usdf9p$15934$2@i2pn2.org>
 <usdh1e$19t14$1@dont-email.me> <usdi0i$15ejn$1@i2pn2.org>
 <usdkf8$1aheg$1@dont-email.me> <use0kt$15q44$2@i2pn2.org>
 <use9hj$1hofh$1@dont-email.me> <usebgv$167kp$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 8 Mar 2024 07:07:03 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="cbe692f823dc8310f00dd0aaf1f84978";
	logging-data="1652836"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Lz3XQj1rLXCX7nzGT3bPn"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ryuIZxpEzTaZ9KtfS5O2yYAEQQc=
In-Reply-To: <usebgv$167kp$1@i2pn2.org>
Content-Language: en-US
Bytes: 13656

On 3/8/2024 12:34 AM, Richard Damon wrote:
> On 3/7/24 10:00 PM, olcott wrote:
>> On 3/7/2024 9:28 PM, Richard Damon wrote:
>>> On 3/7/24 4:00 PM, olcott wrote:
>>>> On 3/7/2024 5:18 PM, Richard Damon wrote:
>>>>> On 3/7/24 3:02 PM, olcott wrote:
>>>>>> On 3/7/2024 4:32 PM, Richard Damon wrote:
>>>>>>> On 3/7/24 1:05 PM, olcott wrote:
>>>>>>>> H1(D,D) maps its input + its own machine address 00001422 to its 
>>>>>>>> output.
>>>>>>>>   H(D,D) maps its input + its own machine address 00001522 to 
>>>>>>>> its output.
>>>>>>>> Thus both H1 and H are computable functions of their input.
>>>>>>>
>>>>>>> And thus you are admitting that Neither H or H1 are actually 
>>>>>>> correct Halt Deciders, as Halt Deciders must be only a function 
>>>>>>> of the description of the Compuation to be decided.
>>>>>>>
>>>>>>
>>>>>> It turns out that both H(D,D) and H1(D,D) do correctly determine
>>>>>> whether or not they must abort the simulation of their input.
>>>>>
>>>>> Which isn't the halting question, so you are LYING.
>>>>
>>>> As I completely explained yet you persistently ignore the
>>>> halting question can only be correctly answered indirectly
>>>> otherwise inputs that contradict the decider that is embedded
>>>> within these inputs have no answer at all.
>>>
>>> In other words you argue by lying.
>>>
>>> The QUESTION is, and always will be, does the computation described 
>>> by the input Halt when run.
>>>
>>> The Computation so described is FIXED and UNCHANGING reguards of what 
>>> the decider that is deciding does, as is the behavior of the H that 
>>> it is built on.
>>>
>>> That was FIXED and made UNCHANGING when it was defined.
>>>
>>> Thus, the question does THIS H^(H^) halt? HAS a definite and fixed 
>>> answer. SO you LIE when you said it doesn't.
>>>
>>> Your problem seems to be that you think "Get the Right Answer?" is a 
>>> valid program instruction, or that H can somehow "change" itself 
>>> after H^ gets defined. IT CAN'T.
>>>
>>> YOU persistently ignore this fact, likely because you are too stupid 
>>> and ignorant to understand that fundamental nature of programs, that 
>>> they will do what their programming says they will do, and that 
>>> programming doesn't change, EVER, with out the creation of some NEW 
>>> program that is different from its predicesor.
>>>
>>> YOU *NEVER* have the right to change the question for a problem.
>>>
>>> You can try to point out the the problem is inconsistant, and propose 
>>> a NEW PROBLEM, but that doesn't change the old.
>>>
>>> You can talk about your new problem that you think is more useful 
>>> than the actual Halting Problem, after all, someone might be more 
>>> interested in the incorrect opinion of an admittedly faulty 
>>> "Olcott-Halt Decider" than the actual behavior of the Computation 
>>> they are interested in.
>>>
>>> NOT.
>>>
>>> What you can't to is say you are working on one problem, while trying 
>>> to change it to mean something different. That is just call LYING, 
>>> and you seem to know that you doing it (you might feel you have 
>>> justified reasons to talk about a different problem) so the lie is 
>>> DELIBERATE.
>>>
>>>>
>>>>>>
>>>>>> That you or others consider this somehow improper does not change
>>>>>> the verified fact that they both correctly determine whether or
>>>>>> not they must abort their simulation.
>>>>>
>>>>> Which isn't the Halting Question, which you claim you are working 
>>>>> on, so you are just LYING.
>>>>>
>>>>
>>>> Already fully explained many many times (including above)
>>>> yet your ignorance is very persistent.
>>>
>>> So, you think you can change the question and still be talking about 
>>> the same question.
>>>
>>> You ARE the LIAR PARADOX.
>>>
>>>>
>>>>>>
>>>>>> It is also the case that both H1(D,D) and H(D,D) are a pure function
>>>>>> of their inputs when we construe their own machine address to be an
>>>>>> element of these inputs.
>>>>>
>>>>> Which means they are not computing the Halting Function, which 
>>>>> isn't a function of the decider, so again, you are LYING.
>>>>>
>>>>
>>>> Already fully explained many many times (including above)
>>>> yet your ignorance is very persistent.
>>>
>>> Yes, you have ADMITTED that you are LYING about working on the 
>>> Halting Problem.
>>>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>> Turing machines don't even have the idea of their own machine
>>>>>>>> address so this exact same thing cannot be Turing computable.
>>>>>>>
>>>>>>> And it isn't a Halt Decider even in Olcott machines as the 
>>>>>>> algorithm is shown to vary by a parameter that it isn't allowed 
>>>>>>> to vary to be a Halt Decider.
>>>>>>>
>>>>>>>>
>>>>>>>> Olcott machines entirely anchored in Turing machine notions
>>>>>>>> can compute the equivalent of H1(D,D) and H(D,D).
>>>>>>>>
>>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>>> descriptions their essence is already fully understood.
>>>>>>>>
>>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>>
>>>>>>>> This is followed by the machine description of the machine
>>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>>>
>>>>>>>> When this input is ignored Olcott machines compute the
>>>>>>>> exact same set as Turing machines.
>>>>>>>>
>>>>>>>> Unlike Turing machines, Olcott machines have the basis to
>>>>>>>> determine that they have been called with copies of their
>>>>>>>> own TMD.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does 
>>>>>>>> not halt
>>>>>>>>
>>>>>>>> With Olcott machines Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> and H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> do
>>>>>>>> not have the same inputs thus can compute different outputs
>>>>>>>> when they do not ignore their own TMD.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> THen you build H^ wrong. Of course with your change in mechanics, 
>>>>>>> the H^ that needs to be generated will be a bit different.
>>>>>>>
>>>>>>
>>>>>> That Olcott machines always know their own TMD is unconventional.
>>>>>
>>>>> And breaks much of the background of Turing Machines, 
>>>>
>>>> Not at all. Not in the least little bit.
>>>> Olcott machines are 100% fully specified
>>>> in terms of Turing machines.
>>>
>>> Yes, BUT if you talk about an Olcott machine, you MUST include the 
>>> added data as part of the description of that machine, or you are 
>>> just LYING.
>>>
>>>>
>>>>> so if you what to use ANY establish property of Turing Machine, you 
>>>>> must include that now extra data EXPLICITLY.
>>>>>
>>>>
>>>> It is already explicitly included in the definition of an Olcott 
>>>> machine.
>>>
>>> Which means that you can't actually write an Olcott-Machine that 
>>> matches the requirements for a Halt Decider.
>>>
>>> A Halt Decider MUST be able to defined as taking JUST the description 
========== REMAINDER OF ARTICLE TRUNCATED ==========