On 4/15/2022 6:39 AM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/14/2022 7:12 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/14/2022 3:54 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/14/2022 11:40 AM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/14/2022 9:30 AM, Ben wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/13/2022 6:02 PM, Ben wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/13/2022 2:38 PM, Ben wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>> The simulated input to H(P,P) is non halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then you are either (a) doing it wrong, or (b) wrong to have said that
>>>>>>>>>>>>> P(P) halts. Oh, there is a third (c) you are using poetic license, and
>>>>>>>>>>>>> simulating the input means something silly. It's literal nonsense to
>>>>>>>>>>>>> there's a lot of scope for you make up some silly meaning.
>>>>>>>>>>>>
>>>>>>>>>>>> When mere rhetoric goes against easily verified facts rhetoric loses:
>>>>>>>>>>>
>>>>>>>>>>> Your own claim: H(P,P) == false is "correct" even though P(P) halts.
>>>>>>>>>>> That's not rhetoric. You've been too clear about this attempt. You
>>>>>>>>>>> need to try a new ruse.
>>>>>>>>>>
>>>>>>>>>> Because the input to H(P,P) is non-halting then nothing in the
>>>>>>>>>> universe can possibly contradict the fact that it is non-halting.
>>>>>>>>>
>>>>>>>>> Being generous, the "input" to H in the call H(P,P) is just two
>>>>>>>>> pointers. They are neither halting nor non-halting -- they are just
>>>>>>>>> pointers.
>>>>>>>>>
>>>>>>>>> Up until, now I was prepared to take your words metaphorically, but
>>>>>>>>> since you duck the key question of what "the input to H(P,P) is
>>>>>>>>> non-halting" means,
>>>>>>>>
>>>>>>>> Sure when I make to to explain ever details many hundreds of times
>>>>>>>> damned liars will say that I never mentioned any of this.
>>>>>>> Just use the right terms. H(P,P) has not input. The call has
>>>>>>> arguments. They are just pointers. Pointers are not halting nor are
>>>>>>> they non halting. Given that this mantra is the core of what you are
>>>>>>> now claiming, I would have thought you would want to avoid it being
>>>>>>> patentent nonsense.
>>>>>>>
>>>>>>>> The input to H is the only way that finite strings can be passed to a
>>>>>>>> "C" function and points to the finite string of the machine code of P.
>>>>>>> H has no input. Do you mean the two pointer arguments?
>>>>>>>
>>>>>>>> The simulating halt decider H uses an x86 emulator to simulate its
>>>>>>>> input (P,P) and finds that it would never reach its own final state in
>>>>>>>> an unlimited number of simulated steps.
>>>>>>>
>>>>>>> (P,P) is too vague. What needs to be simulated is the first pointer
>>>>>>> being called as a function with the second as it's argument. I.e. the
>>>>>>> call P(P) is what should be simulated.
>>>>>>
>>>>>> That the correctly simulated input to H(P,P) cannot possibly reach its
>>>>>> own final state proves that this input is not-halting.
>>>>>>
>>>>>> Adding all of the tedious details that you suggest does not change
>>>>>> this fact.
>>>>>
>>>>> If you add all the corrections, sorry, "tedious details", it contradicts
>>>>> what you've said in the past. With the errors left in place, the naive
>>>>> reader won't knowing exactly what's being said -- and I think that's
>>>>> deliberate.
>>>>>
>>>>> For example, why talk about simulation at all since simulations of
>>>>> computations halt or don't halt if and only if the computations do
>>>>> themselves? Well, it adds yet another puff of smoke to the mirrors
>>>>> you've got in there already like what that "its" refers to (since
>>>>> nothing here has a final state), or what non-halting pointers are.
>>>>> "The input to H(P,P)" should mean the two pointers, P and P. Simulating
>>>>> them should mean simulating the call P(P) and the simulation "not
>>>>> reaching its own final state" should mean that the simulation of P(P)
>>>>> does not halt. And that happens if, and only if, the call P(P) itself
>>>>> does not halt.
>>>>>
>>>>> I honestly have no idea if that is what you mean, but if it is, it's
>>>>> wrong because P(P) halts. You are probably just trying to cover that
>>>>> up.
>>>>
>>>> That a non input halts, converts the world to Fascism or opens a very
>>>> popular brothel is totally unrelated to the easily confirmed fact that
>>>> the input to H(P,P)* does not halt.
>>>
>>> The correct value of H(P,P) is determined by the halting status of what
>>> you call a non input:
>>
>> LIAR LIAR PANTS ON FIRE
>
> If this is one of the things you might say to that fictional room of
> academics you imagine talking to, put me down for a front row seat!
>
>> You know damn well that a halt decider must compute the mapping
>> FROM ITS INPUTS
>
> From its arguments.
>
>> Any damn thing that computes the mapping from a non-input
>> IS WRONG BY DEFINITION
>
> I tried to help you with this, but you

Just won't believe damn lies

> got stuck at the very start.
>
> Anyway, you don't get to say what the correct answer is.

Computer science says that any input to a halt decider that would never
reach its own final state is non-halting.

> You started
> this massive waste of time by deciding, decades ago, to take up an
> /existing/ problem. What your H has to return, for any given arguments,
> is not up for debate. You can say you can't meet the specification
> because it's in some way crazy -- that /is/ up to you (though you won't
> find many takers) -- but you still can't meet the specification:
>
> // H returns true if, and only if, the function call x(y) always
> // returns (or halts if you prefer) no matter where it is called from.
> // H returns false in all other cases.
>
> typedef int (*ptr)();
> int H(ptr x, ptr y);
>
> Stamp your feet and shout that x(y) is a "non-input" all you like, but
> this is the function you can't write[1].
>
> Actually you can't write a function like that which decides /any/
> non-trivial property of the function x. Can you write a function that
> decides if there is some y for which x(y) == 42? No you can't. Can you
> write a function that decides if x(0) == 0? No you can't.
>
> And the list includes many practical and interesting problems such as
> deciding if a context-free grammar is ambiguous or not.
>
>> IS WRONG BY DEFINITION
>> IS WRONG BY DEFINITION
>>
>> Why lie ?
>
> How often have you got burned by this?

I am not burned now.
When I state a logical truism and anyone disagrees then they are incorrect.

> I have never lied to you but
> many times when you have accused me of lying, or playing head games, or,
> on one occasion, of being mad, it's turned out that you just didn't know
> what you were talking about. The last time was fixed only after I told
> you, repeatedly, to read page 8 of Mendelson. On that occasion, you
> didn't know what a sequence was just a function.
>
> [1] Without tricks like H(x,y) returning different results when called
> in different places in a program.
>

The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push P
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push P
[00000961](05) e8c0feffff call 00000826 // call H(P,P)
The above keeps repeating until aborted

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Size in bytes:(0027) [00000970]

Because the above simulated input is non-halting H can report this and
be correct. There is no dishonest double-talk that can even seem otherwise.

--
Copyright 2022 Pete Olcott

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