Sujet : Re: The actual truth is that ... Turing computability issues have been addressed --- marathon winner
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theoryDate : 17. Oct 2024, 01:05:53
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <3b43022905a66370235512a3942a42388366cfde@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
User-Agent : Mozilla Thunderbird
On 10/16/24 8:52 AM, olcott wrote:
On 10/16/2024 1:32 AM, joes wrote:
Am Tue, 15 Oct 2024 22:52:00 -0500 schrieb olcott:
On 10/15/2024 9:11 PM, Richard Damon wrote:
On 10/15/24 8:39 AM, olcott wrote:
On 10/15/2024 4:58 AM, joes wrote:
Am Mon, 14 Oct 2024 20:12:37 -0500 schrieb olcott:
On 10/14/2024 6:50 PM, Richard Damon wrote:
On 10/14/24 12:05 PM, olcott wrote:
On 10/14/2024 6:21 AM, Richard Damon wrote:
On 10/14/24 5:53 AM, olcott wrote:
On 10/14/2024 3:21 AM, Mikko wrote:
On 2024-10-13 12:49:01 +0000, Richard Damon said:
On 10/12/24 8:11 PM, olcott wrote:
>
Trying to change to a different analytical framework than the one
that I am stipulating is the strawman deception. *Essentially an
intentional fallacy of equivocation error*
But, you claim to be working on that Halting Problem,
I quit claiming this many messages ago and you didn't bother to
notice.
Can you please give the date and time? Did you also explicitly
disclaim it or just silently leave it out?
Even people of low intelligence that are not trying to be as
disagreeable as possible would be able to notice that a specified C
function is not a Turing machine.
But it needs to be computationally equivalent to one to ask about
Termination.
Not at all. A termination analyzer need
not be a Turing computable function.
It definitely does. An uncomputable analyser is useless.
>
It is true that a termination analyzer is not required
to work correctly for all inputs.
Of course it is to be a full analyzer.
Its just the field admits that it is impossible, so they look for partial analyzers, and the partial is just assumed.
That there is one way that HHH can consistently catch the
non-terminating pattern of its input proves that this can
be done.
Except that it gets the wrong answer, since DDD() is a terminating functions when it is built on any of the HHH that give that answer.
Mike suggested some different ways that would seem to be
Turing computable yet too convoluted to be time consuming
for me to implement in practice.
The basic approach involves the idea that every state change
of the emulations of emulations is data that belongs to the
outermost directly executed HHH.
But, that still doesn't let you make the assumption that you do.
After all, the emulated analyzer will do exactly the same thing to the input it is analyzing, since it is the exact same code as the analyzer that is giving the answer, and looking at the exact same input as it was.
It is too convoluted for me to provide a way for HHH to
look inside all of the emulations of emulations and pull
out the data that it needs, so knowing that this is possible
is enough to know that it is Turing computable.
So you ADMIT that you claim of being a pure funcition is just a LIE.
Because my life is being cut short by cancer I cut to
the chase and hypothesize this pair of necessary truths:
void DDD()
{
HHH(DDD);
return;
}
When HHH is an x86 emulation based termination analyzer then
each DDD *correctly_emulated_by* any HHH that it calls never returns.
Except it doesn't do that, as it doesn't do an emulation that actual PROVES that the complete emulation of this EXACT input (that calls the HHH that gives the answer) will not halt, but instead its logic assume that the input isn't the input that it was actually given, and thus your logic is based on LIES.
Each of the directly executed HHH emulator/analyzers that returns
0 correctly reports the above *non_terminating _behavior* of its input.
Nope, since it HAS been established that all those DDD will return, they just don't in the PARTIAL emulation done by that HHH, and partial emulations do not define final behavior.
That is just one of your LIES.
When HHH is an x86 emulation based termination analyzer then each DDD
*correctly_emulated_by* any HHH that it calls never returns.
Only because the nested HHH doesn't abort.
>
Every nested HHH has seen one less execution trace than
the next outer one. The outermost one aborts its emulation
as soon as it has seen enough. Thus each inner HHH cannot
possibly abort its own emulation.
No, every nested HHH WILL SEE exactly the same execution trace when we look at its ACTUAL behaivor.
The "one less" is only talking about the partial knowledge that the outer HHH has, but that knowledge isn't about the actual truth of the actual behavior, but it seems your mental deficiencies can't tell the difference.
It is just like guys running in a marathon at exactly the same
speed where each one is ten feet in front of the other. Only the
first guy can possibly win.
Depends on the scoring system, if each started 10 feet behind the one in front, the timing system will give each the same time, and they will tie.
The fact that the first one crosses first doesn't mean the other will not cross and get the exact same time.
Since "Termination" is determined by *IF* the program will reach a final state in a finite number of steps when allowed to run for an unbounded number of steps, the fact that they all *WILL* finish, in EXACTLY the same way as the outer one, says they all will be terminating.
You are just showing you just need to LIE about the problem you are working on and that you need to use STRAWMEN to try to prove it.
Sorry. you don't get to change the criteria, that is just INCORRECT logic.