Re: Working out the details of the steps of Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn

On 3/8/2024 8:24 PM, Richard Damon wrote:

On 3/8/24 5:59 PM, olcott wrote:

On 3/8/2024 7:18 PM, Richard Damon wrote:

On 3/8/24 4:26 PM, olcott wrote:

On 3/8/2024 5:29 PM, Richard Damon wrote:

On 3/8/24 2:37 PM, olcott wrote:

On 3/8/2024 3:57 PM, Richard Damon wrote:

On 3/8/24 1:34 PM, olcott wrote:

On 3/8/2024 2:29 PM, Richard Damon wrote:

On 3/8/24 11:17 AM, olcott wrote:

On 3/8/2024 12:40 PM, Richard Damon wrote:

On 3/8/24 10:11 AM, olcott wrote:

On 3/8/2024 12:00 PM, Richard Damon wrote:

On 3/8/24 7:59 AM, olcott wrote:

On 3/8/2024 5:26 AM, Mikko wrote:

On 2024-03-07 19:49:49 +0000, Dan Cross said:
>

What is it?  The olcott machine is a device that never halts and
generates infinite amounts of nonsense.  As a perpetual motion
device with no discernable input and unbounded output, it is
believed that it violates the laws of thermodynamics.

>
The olcott machine uses a hidden input.
>

>
It is not hidden. The master UTM of Olcott machines simply
appends the TMD to the end of the simulated TMD's tape.
>
Only those machines that need to see if themselves are
called in recursive simulation use this optional input.
>

>
Which means they ADMIT they are doing a different computation then the Turing Machine they are derived from.
>
So, there can not be an Olcott Machine that matches the signature of a Halt Decider.
>
PERIOD
>
And thus, you prove you have created another worthless field.

>
I am working on the computability of the halting problem
(the exact same TMD / input pairs) by a slightly augmented
notion of Turing machines as elaborated below:
>
Olcott machines are entirely comprised of a UTM + TMD and one
extra step that any UTM could perform, append the TMD to the end
of its own tape.
>
Olcott machines that ignore this extra input compute the exact
same set of functions that Turing machines compute.
>
Olcott machines can do something that no Turing machine can
possibly do correctly determine that they themselves are
called in recursive simulation.
>

>
Nope.
>
You have PROVED (by your definition of an Olcott Machine) that ANYTHING an Olcott machine can do, there exists a Turing Machine that does the same thing.

There is no conventional Turing machine that can possibly
know that it is about to simulate a copy of itself in
recursive simulation.

>
It can know just as well as your Olcott machines, which apparently can only tell it the recusion is done by that EXACT same machine using the same description
>

>
How it this?
Conventional Turing machines do not generally have access to their
own machine description and generally cannot even know that they
are being provided with their own machine description unless they
are Olcott machines where this is anchored in their fundamental
architecture.

>
But if the mapping includes the description, it can be given to it.

>
I am only going to respond to this one thread
(until I complete my design)
and will stop responding to this one too if you don't provide
very well thought out rebuttals or replies.

>
Suit yourself. YOU are the one on a time limit and trying to develope something "useful".

>
It should not take very long to figure the details steps
of what H ⟨H⟩ ⟨H⟩ <H> would do.

>
Right, but
>
H (H) (H) <H> is asking what
H (H) <H> will do which is asking about what
H <H> will do, which is asking about the Halting Property of a no-description, which will be defined by the fine details of your rules, but will definitely Halt
So even without doing any aborting, the last machine halts, and thus the whole chain will reach a final state of qy.
>
Thus, what it SHOULD do is not abort, finish its simulation and thus report Halting.
>
Which sort of goes against your initial plan.
>

>

>
If a machine is given its own description unless the fundamental
architecture of the system guarantees that this is its true
description then the machine cannot rely on this being its own
description.

>
Right, so copies of a machine embedded in another machine can not get that guarantee, so you idea fails.
>

>
Not at all. Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can definitely verify that it is about to
simulate a copy of its own machine description with a copy of its own
machine description.

>
Yes, but the issue is that isn't what will happen in the pathological program, so shouldn't be your focus.
>
Note, if your decision on processing this doesn't handle the FULL input, you can easily get the wrong answer, as
>
H^.H (H^) (H) <H^> will then do
>
H^.H (H) (H) <H^> which is asking about
>
H (H) <H> which we looked at above, and the whole chain will end and all will return halting.
>
Just matching the machine to itself doesn't mean infinite recursion.
>
For that you needed the outer most H to see that we got to H^.H with the same paratmeters it started with, but H can't recognize H^.H, since its description will have changed due to the state remapping.
>

>

It is a FUNDAMENTAL property of Turing Machines that you can embed a copy of one machine in another, and provide it with whatever input tape you can compute.
>
If you want your new property to apply to such "submachines" you are going to need some careful thought, and understanding how Turing Machine actually work is going to be a requirement.
>

>

>
Anchoring it in the architecture means you now need to PROVE they don't use it if the mapping doesn't have it (like most don't)

>
Not at all as I just explained above.

>
Nope.
>
If the mapping is Halting( M, d) -> Halt/non-Halt
>
but the machine is H (M) d <H>, then if H depends on the final <H> that means that not all copies of H answer correctly, so "H" isn't a halt decider.
>
You might be able to say just one representation is the true decider, but the we just need to build H^ to contradict that one, and you now can't do your H / H1 trick, as you were forced to declare that it was H, the one that H^ was built on was the decider.

>
I think that you may be disingenuous here.
I have gone though the details so many times that you
should know all these details by now.
>
Or maybe you never understood how this has the side-effect
of correctly deciding halting whenever it is not impossible.

>
Nope, because what you end up with fails to meet the requirements of a DECIDER.
>
You might have a machine that gets this one question right, but that doesn't make it a DECIDER.
>

>
*Criterion Measure*
H is assumed to be a simulating termination analyzer that aborts the
simulation of any input that would cause its own non-termination and
returns NO. Otherwise H always returns YES.

>
Which isn't the Halting Question, so you are just lying when you say you are working on the Halting Problem.
>

>

>

So you have added to your work to prove the behavior of the machine.

>
I don't see how.

>
Of course you don't see, because you don't understand the problem.
>
If the requirement is to find a Computation of X that computes a mapping of X to Y, and you build a machine M that takes in X and <M> and you show that one of them

>
As a rebuttal this still makes no sense to me.
*Here <are> the mappings*

>
Do you even know what a "Mapping" is?

>
Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> ⊢* Ĥ.Hqn
Says that Ĥ.H maps its inputs to its own internal state Ĥ.Hqn
>

 That is just H^.H computing an instance of the mapping, not the mapping itself.

Yes I forgot the exact words.
Ĥ.H computes the mapping from its inputs:
⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> to its own final state Ĥ.Hqn

The Mapping describes the answer that we want for ALL possible inputs. It becomes the specification of the problem.
 

You still can't understand how computing the mapping
from all inputs to final state Ĥ.Hqn or non final state
Ĥ.Hqy on the basis of the indirect criteria also causes
H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> to correctly compute halting.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer