Re: The philosophy of computation reformulates existing ideas on a new basis

On 11/11/24 10:15 AM, olcott wrote:

On 11/11/2024 5:06 AM, Mikko wrote:

On 2024-11-09 14:56:14 +0000, olcott said:
>

On 11/9/2024 3:53 AM, Mikko wrote:

On 2024-11-08 14:39:20 +0000, olcott said:
>

On 11/8/2024 6:39 AM, Mikko wrote:

On 2024-11-07 16:39:57 +0000, olcott said:
>

On 11/7/2024 3:56 AM, Mikko wrote:

On 2024-11-06 15:26:06 +0000, olcott said:
>

On 11/6/2024 8:39 AM, Mikko wrote:

On 2024-11-05 13:18:43 +0000, olcott said:
>

On 11/5/2024 3:01 AM, Mikko wrote:

On 2024-11-03 15:13:56 +0000, olcott said:
>

On 11/3/2024 7:04 AM, Mikko wrote:

On 2024-11-02 12:24:29 +0000, olcott said:
>

HHH does compute the mapping from its input DDD
to the actual behavior that DDD specifies and this
DOES INCLUDE HHH emulating itself emulating DDD.

>
Yes but not the particular mapping required by the halting problem.

>
Yes it is the particular mapping required by the halting problem.
The exact same process occurs in the Linz proof.

>
The halting probelm requires that every halt decider terminates.
If HHH(DDD) terminates so does DDD. The halting problmen requires
that if DDD terminates then HHH(DDD) accepts as halting.

>
void Infinite_Loop()
{
   HERE: goto HERE;
   return;
}
>
No that is false.
The measure is whether a C function can possibly
reach its "return" instruction final state.

>
Not in the original problem but the question whether a particular strictly
C function will ever reach its return instruction is equally hard. About

>
It has always been about whether or not a finite string input
specifies a computation that reaches its final state.

>
Not really. The original problem was not a halting problem but Turing's

>
Exactly. The actual Halting Problem was called that by Davis
in 1952. Not the same as Turing proof.

>
In early times there was variation in how things were presented and what
words were used. Post had studied the halting problem of his tag system
much earlier but didn't call it a machine. Many other problems were also
studied and later found to be more or less related to the halting
problem and its variants.
>

*So we are back to The Halting Problem itself*
>
has always been about whether or not a finite string input
specifies a computation that reaches its final state.

>
No, it has been a collection of related problems that includes that
particular one.

>
The halting problem has always been abuut halting

>
Nevertheless Turing's solution to his circularity problem is usually
regarded as the first solution to the halting problem.
>

As the problems are related and equally hard it does
not really matter which one you choose as long as you are clear
about your choice. To argue about the meaning of words id a clear
indcation of an intent to avoid an honest discussion.

>

It is not the meaning of words it is the semantic
property of the finite string pair HHH/DDD.

>
Above you have argued about the meanings of the words and
keep doing so below.

>
It is the meaning of the bytes of x86 code and
bytes of code are not words.

>
No, nothing you have said tells anuything about meanings of the bytes
of x86 code. (A pair of such bytes is sometimes called a "word").
You were just arguing about the meanings the verb "halt" and other
words.
>

 Halt means reaching a final halt state to say otherwise
is ignorant or dishonest.

And not halting means never reaching that final state after an unbounded number of steps.
Showing it didn't yet halt after a finite number of steps doesn't show non-halting, just didn't halt yet.

 

The halting problem has always been about whether a finite
string input specifies a computation that will reach its
final halt state.
>
If you disagree then you must provide a complete and coherent
counter-example conclusively proving otherwise not merely
some vague reference to some other things somewhere else.

>
From https://www.tutorialspoint.com/automata_theory/ turing_machine_halting_problem.htm
>

Turing Machine Halting Problem
Input − A Turing machine and an input string w.
Problem − Does the Turing machine finish computing of the string w in a finite number of steps? The answer must be either yes or no.

>
The computation specified by the finite string DDD
emulated by HHH cannot possibly reach its "return"
instruction final halt state.

>
It can and does if HHH is a decider and otherwise does not matter.
>

 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 HHH is a correct termination analyzer that does correctly
determine that DDD emulated by HHH cannot possibly reach
its own [00002183] machine address.

No, it is an INCORRECT terminatation analyzer that INCORRECRTLY determines that DDD will not terminate.
DDD emulated by HHH is NOT a valid condition to base termination analysis, so, you are just showing you don't know what you are talking about.

 The erroneous assumptions about halt deciders are anchored
in the lack of a complete concrete example where the behavior
specified by the finite string can be unequivocally determined.

Nope, your ignorance is rooted in your false understanding of the properties of the system.
Note, it is a FAcT that there are finite-strings whose behavior can not be unequviocally determined, yet have an unequivocal behavior (that just isn't known).

 That people continue to stupidly try to get away with disagreeing
with the x86 language proves that anything less than the 100%
complete specification that the x86 language provides cannot
possibly overcome the strong indoctrination into an incoherent view.

No, the fact that you IGNORE that the semantics of the x86 language says you can not "abort" your emulation and still necessarily get the FINAL behaivor of the code just shows your stupidity.

 

The computation specified by the finite string DDD
emulated by HHH1 IS NOT THE ACTUAL INPUT TO HHH.

>
HHH1 can take same inputs as HHH. These inputs specify some behaviour.
What they do with this input may differ.
>

 *It is the behavior of their own input that they must report on*
It has always been ridiculously stupid for everyone here to
require HHH to ignore the actual behavior specified by its own
input and instead report on the behavior of the input to HHH1.

And the "behavior" of their own inputs is DEFINED (for "programs") to be the results of the unbounded emulation of that program / the direct running of the program described, even if that isn't what the decider itself does.
Your logic does exactly what you say it isn't allowed to do, because you try to assert a FALSE definition of its behavior, just showing that you are nothing but a LIAR.

 

HHH must compute the mapping FROM ITS INPUT TO THE
BEHAVIOR THAT THIS INPUT SPECIFIES.

>
Not to full behaviour but to one feature of that behaviour.
Doesn't HHH1 need to?
>

 Both HHH and HHH1 must report on whether or not their simulation
of their own input can possibly reach its own "return" instruction
final halt state. They get different answers ONLY BECAUSE THE BEHAVIOR OF THEIR INPUT DDD IS DIFFERENT!
 

No, they must report if *THE* unbounded emulation of their input can possibly reach its own return instruction.
The fact that you keep on insisting on your LIE about what the criteria is, as established by the DEFINITIONS of the problem, just show how stupid you are.
Do you have ANY source to support your LIE that the decider is to answer about the SUBJECTIVE behavior of its own emulation of the input, as opposed to the actual behavior of the program the input represents, or the correct and complete emulation of the input given to it.
If you can't find one, that is just you admitting that your life is just based on lying to yourself and everyone else, because you are nothing but a pathetic pathological lying idiot.