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

On 11/3/24 9:39 AM, olcott wrote:

On 11/3/2024 6:11 AM, Mikko wrote:

On 2024-11-02 12:46:47 +0000, olcott said:
>

On 11/2/2024 5:49 AM, Mikko wrote:

On 2024-11-01 12:26:58 +0000, olcott said:
>

On 11/1/2024 5:58 AM, Mikko wrote:

On 2024-10-31 12:50:00 +0000, olcott said:
>

On 10/31/2024 5:49 AM, Mikko wrote:

On 2024-10-29 14:35:34 +0000, olcott said:
>

On 10/29/2024 2:57 AM, Mikko wrote:

On 2024-10-29 00:57:30 +0000, olcott said:
>

On 10/28/2024 6:56 PM, Richard Damon wrote:

On 10/28/24 11:04 AM, olcott wrote:

On 10/28/2024 6:16 AM, Richard Damon wrote:

The machine being used to compute the Halting Function has taken a finite string description, the Halting Function itself always took a Turing Machine,
>

>
That is incorrect. It has always been the finite string Turing Machine
description of a Turing machine is the input to the halt decider.
There are always been a distinction between the abstraction and the
encoding.

>
Nope, read the problem you have quoted in the past.
>

>
Ultimately I trust Linz the most on this:
>
the problem is: given the description of a Turing machine
M and an input w, does M, when started in the initial
configuration qow, perform a computation that eventually halts?
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
Linz also makes sure to ignore that the behavior of ⟨Ĥ⟩ ⟨Ĥ⟩
correctly simulated by embedded_H cannot possibly reach
either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ because like everyone else he rejects
simulation out of hand:
>
We cannot find the answer by simulating the action of M on w,
say by performing it on a universal Turing machine, because
there is no limit on the length of the computation.

>
That statement does not fully reject simulation but is correct in
the observation that non-halting cannot be determied in finite time
by a complete simulation so someting else is needed instead of or
in addition to a partial simulation. Linz does include simulationg
Turing machines in his proof that no Turing machine is a halt decider.

>
*That people fail to agree with this and also fail to*
*correctly point out any error seems to indicate dishonestly*
*or lack of technical competence*
>
DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "return" instruction
whether or not any HHH ever aborts its emulation of DDD.

>
- irrelevant

>
100% perfectly relevant within the philosophy of computation

>
Probably but not to anything quoted above.
>

*THE TITLE OF THIS THREAD*
[The philosophy of computation reformulates existing ideas on a new basis ---]
>

- couterfactual

>

You can baselessly claim that verified facts are counter-factual
you cannot show this.

>
Your statement was about a situation where "people fail to agree with
this and also fail to correctly point out any error". But that situation
has not happened as people have identified your errors (perhaps not all
but at least sufficiently many).
>

>
Inconsistent with the currently received view is
certainly not the slightest trace of any error when
examined within the philosophy of computation.

>

It has always seemed quite ridiculous to me that everyone
here consistently construes the currently received view
as inherently infallible.

>
The currently received view that if you are asked "What is 5 + 6?"
then only an answer that tells what 5 + 6 is is correct is infallible.

>
This is simple enough that people cannot be confused.
That 5 + 6 == 11 does seem infallibly true.

>
So even you can make the ridiculous mistake to regard the currently
received view as infallible?
>

They call me stupid and ignorant for not accepting the currently
received view as inherently infallible.

>
You are stupid if you regard your own view as infallible. If you
regard something that has been tested and found good as infallible
then the risk of error can be small enough.

>
I have known that equating believable with true is an error
a great consequence ever since I was 14.
>
It seems clear that halt deciders must compute the mapping
from their input finite strings to the actual behavior
specified by these finite strings.

>
It is not clear at all unless you specify how those finite
strings specify the actual behaviour.

 That is why I used to fully defined semantics of the x86
language to make this 100% perfectly unequivocal.
 A few lines of x86 code express complex algorithms
succinctly enough that human minds are not totally
overwhelmed by far too much tedious detail.
 

It is not pspecified
in the usual formulation of the problem. Also note that
the behaviour exists before those strings so "describe"
should be and usually is used instead of "specify". The
use of latter may give the false impression that the behaviour
is determined by those strings.
>

 In order for any machine to compute the mapping from
a finite string it must to so entirely on the basis
of the actual finite string and its specified semantics.

You have that somewhat backwards. It *CAN* only do what it can compute.
The mapping is not required to *BE* computable.

 The finite string input to HHH specifies that HHH
MUST EMULATE ITSELF emulating DDD.

Right, and it must CORRECTLY determine what an unbounded emulation of that input would do, even if its own programming only lets it emulate a part of that.

 The finite string input to HHH1 specifies that HHH1
MUST NOT EMULATE ITSELF emulating DDD.

But the semantics of the string haven't changed, as the string needs to contain all the details of how the machine it is looking at will work.

 Unless HHH rejects its input DDD as non halting the
executed DDD never stops running. This itself proves
that HHH is correct and that DDD is not the same
instance as the one that HHH rejected.

You have cause and effect backwards.
HHH aborts it emulation at the point it does because that is what its programming says to do. HHH has no volition to "choose" what to do.
That was all exercised when the programmer created it, and that choice is able to be used by DDD when it is made. The programmer can't consider an input that is based on a different HHH, as that isn't what DDD is built on.

 

It is true that when we construe the halting criteria as
requiring taking into account how a pathological relationship
changes the behavior of the input instead of simply ignoring
this behavior change that pathological inputs become decidable
as non-halting.

>
It is true that doing that means leaving the halting proble unsolved.
>

 The HP proofs are refuted by my work.
This is not quite the same ting as solving the halting problem.
 

Nope, your stupidity is proved by your words, which show you don't understand the basics of the problem.
You are just showing you are nothing but a pathological liar that presumes he can change definitions and just state falsehoods.