Re: The simple essence of Proof Theoretic Semantics

On 7/3/2026 4:35 PM, olcott wrote:
> On 7/3/2026 1:53 PM, dbush wrote:
>> On 7/3/2026 2:45 PM, olcott wrote:
>>> On 7/3/2026 1:27 PM, dbush wrote:
>>>> On 7/3/2026 2:10 PM, olcott wrote:
>>>>> On 7/3/2026 12:10 PM, dbush wrote:
>>>>>> On 7/3/2026 12:52 PM, olcott wrote:
>>>>>>> On 7/3/2026 10:50 AM, dbush wrote:
>>>>>>>> On 7/3/2026 11:36 AM, olcott wrote:
>>>>>>>>> On 7/3/2026 4:22 AM, Mikko wrote:
>>>>>>>>>> On 02/07/2026 17:51, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> Do you know enough about C to understand that
>>>>>>>>>>> dbush example was foolish nonsense when proposed
>>>>>>>>>>> to show the halting problem counter-example?
>>>>>>>>>>
>>>>>>>>>> It is a valid example of a C program. It was present as a part 
>>>>>>>>>> of a
>>>>>>>>>> claim about you, and your response was the false claim that "That
>>>>>>>>>> is just nonsense". Later in the discussion you offer more 
>>>>>>>>>> evidence
>>>>>>>>>> to support his claim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> His halt decider did not look at its input.
>>>>>>>>
>>>>>>>> Nor is it required to.  All it needs to do is map inputs to 
>>>>>>>> outputs.
>>>>>>>>
>>>>>>>
>>>>>>> So a piece of metal sitting on the ground is an automobile.
>>>>>>
>>>>>> Does algorithm H map machine description X and machine input Y to 
>>>>>> an output of either 0 or 1?
>>>>>>
>>>>> Ignoring the input IS NOT A MAPPING
>>>>>
>>>>
>>>> A mapping is nothing more than an association of inputs to outputs, 
>>> int Not_A_Mapping(int X)
>>> {
>>>    return 0;
>>> }
>>
>> The above algorithm does in fact compute this mathematical mapping:
>>
>> input     | output
>> ------------------
>> (any int) | 0
>>
>>>
>>> By construing that as a mapping is one of the screw-ups
>>> that prevents true expressed in language from being computable.
>>>
>>> My HHH applies the operational semantics of
>>> C to its finite string input DD to correctly
>>> determine that the DD input to HHH has no PTS
>>> well-founded justification tree within these
>>> operational semantics.
>>>
>>> With your screwed up notion of a halt decider this
>>> would be correct.
>>>
>>> int HHH(ptr DD)
>>> {
>>>    if (5 > 3)
>>>     return 0;
>>> }
>>
> 
> Because it ignores the input it is not any halt
> function at all.

False, as proven by the below which you dishonestly erased.

>> The above partial halt decider meets the below requirements for all 
>> algorithms that do not halt:
>> 
>> 
>> Given any algorithm (i.e. a fixed immutable sequence of instructions) X 
>> described as <X> with input Y:
>> 
>> A solution to the halting problem is an algorithm H that computes the 
>> following mapping:
>> 
>> (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly