Re: The truth about the halting problem counter-example input

On 06/07/2026 18:18, olcott wrote:
> On 7/6/2026 3:07 AM, Mikko wrote:
>> On 04/07/2026 20:16, olcott wrote:
>>> On 7/4/2026 3:58 AM, Mikko wrote:
>>>> On 04/07/2026 06:11, olcott wrote:
>>>>> On 7/3/2026 9:43 PM, dbush wrote:
>>>>>> On 7/3/2026 10:37 PM, olcott wrote:
>>>>>>> On 7/3/2026 9:19 PM, dbush wrote:
>>>>>>>> On 7/3/2026 10:05 PM, olcott wrote:
>>>>>>>>> On 7/3/2026 8:58 PM, dbush wrote:
>>>>>>>>>> On 7/3/2026 9:52 PM, olcott wrote:
>>>>>>>>>>> On 7/3/2026 5:51 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2026-07-03 16:37, olcott wrote:
>>>>>>>>>>>>> On 7/3/2026 1:47 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2026-07-03 12:36, olcott wrote:
>>>>>>>>>>>>>>> On 7/3/2026 1:18 PM, dbush wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If an algorithm takes an input and produces an output, 
>>>>>>>>>>>>>>>> that is by definition a mapping. 
>>>>>>>>>>>>>>> That only proves that the definition is incoherent.
>>>>>>>>>>>>>>> The coherent way that it actually works is that
>>>>>>>>>>>>>>> inputs are transformed into outputs by applying
>>>>>>>>>>>>>>> finite string transformation rules to inputs to
>>>>>>>>>>>>>>> derive outputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Apparently you don't understand the difference between a 
>>>>>>>>>>>>>> mapping and an algorithm. They are two different things.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> André
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> A function that ignores its input and only returns 0
>>>>>>>>>>>>> is not any sort of halt function.
>>>>>>>>>>>>
>>>>>>>>>>>> He was defining 'mapping', not 'halt function'.
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A actual halt function must compute 
>>>>>>>>>> The mathematical halting function:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When you actually implement this concretely 
>>>>>>>>
>>>>>>>> We find that it is not possible, as Linz and others have proved.
>>>>>>>>
>>>>>>>
>>>>>>> Impossible requirements are incorrect requirements.
>>>>>>>
>>>>>>
>>>>>> Nope.  Requirements are requirements for a reason.  If they can't 
>>>>>> be satisfied, then that's just the way it is.
>>>>>>
>>>>>
>>>>> The halting problem requires a decider that correctly reports the 
>>>>> halt status of an input that does the opposite of whatever it 
>>>>> reports. The meaning of these words prove that is logically 
>>>>> impossible.
>>>>>
>>>>>> I would like to have a single algorithm that can tell me whether 
>>>>>> any arbitrary algorithm with a given input will halt when executed 
>>>>>> directly, but unfortunately no such algorithm exists.
>>>>>
>>>>> typedef int (*ptr)();
>>>>> int HHH(ptr P);
>>>>>
>>>>> 01 int DD()
>>>>> 02 {
>>>>> 03   int Halt_Status = HHH(DD);
>>>>> 04   if (Halt_Status)
>>>>> 05     HERE: goto HERE;
>>>>> 06   return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 void main()
>>>>> 10 {
>>>>> 11   DD();
>>>>> 12   HHH(DD);
>>>>> 13 }
>>>>>
>>>>> HHH is not accountable to report on the
>>>>> behavior of its caller on line 11.
>>>>
>>>> It is if HHH reagards itself as a part of the input. 
>>>
>>> There is no regarding to it
>>> HHH is not accountable to report on the
>>> behavior of its caller on line 11.
>>
>> Yes, there is. If HHH interpretes the call to HHH as a call
> 
> You did not bother to pay attention to the line number 11.
> The HP stupidly assumes that a halt function must report
> on the behavior its caller. HHH has no access to its caller.

The HP does not assume anything. It requires.

-- 
Mikko