Re: HHH maps its input to the behavior specified by it --- key error in all the proofs

Am Mon, 12 Aug 2024 11:42:00 -0500 schrieb olcott:

On 8/12/2024 11:10 AM, Richard Damon wrote:

On 8/12/24 11:34 AM, olcott wrote:

On 8/12/2024 10:05 AM, Richard Damon wrote:

On 8/12/24 9:16 AM, olcott wrote:

On 8/12/2024 8:04 AM, Richard Damon wrote:

On 8/12/24 8:43 AM, olcott wrote:

On 8/11/2024 12:06 PM, Richard Damon wrote:

On 8/11/24 8:40 AM, olcott wrote:

On 8/11/2024 6:08 AM, Richard Damon wrote:

On 8/10/24 10:38 PM, olcott wrote:

On 8/10/2024 9:21 PM, Richard Damon wrote:

On 8/10/24 9:43 PM, olcott wrote:

On 8/10/2024 8:13 PM, Richard Damon wrote:

On 8/10/24 8:51 PM, olcott wrote:

On 8/10/2024 7:20 PM, Richard Damon wrote:

On 8/10/24 7:52 PM, olcott wrote:

On 8/10/2024 5:47 PM, Richard Damon wrote:

On 8/10/24 6:41 PM, olcott wrote:

On 8/10/2024 4:53 PM, Richard Damon wrote:

On 8/10/24 5:37 PM, olcott wrote:

On 8/10/2024 4:33 PM, Richard Damon wrote:

On 8/10/24 5:18 PM, olcott wrote:

On 8/10/2024 3:58 PM, Richard Damon wrote:

On 8/10/24 4:36 PM, olcott wrote:

Richard, get a life.

Except that HHH does't do that, since if HHH
decides to abort and return, then the DDD that it
is emulating WILL return, just after HHH has
stopped its emulation.
You just confuse the behavior of DDD with the
PARTIAL emulation that HHH does, because you lie
about your false "tautology".
>

Denying a tautology seems to make you a liar. I
only say "seems to" because I know that I am
fallible.

Now if only you would recognise this.

The x86 language says DDD will Halt if HHH(DDD)
returns a value.

HHH is called by main() there is no directly
executed DDD() any where in the whole computation.

Except in your requirements, and we can see what it
does by adding a call to DDD from main, since nothing
in your system calls main.

All that you need to know is that there is not any
directly executed DDD() anywhere in the computation.

But there ccould be, and the behavior of it is what
matters.
>

The key error of the halting problem proofs all of these
years has been the false assumption that a halt decider
must report on the behavior of the computation that
itself is contained within.

But it isn't a false assemption, but an actual
requirement.
A Halt Decider must be able to correctly answer for ANY
Turing Machine represented as its input.
ANY includes those that are built from a copy of itself.
So, a Halt Decider needs to be able to correctly answer
about programs that include copies of itself, even with
contrary behavior, which is what makes it impossible to
compute.
You seem to confuse non-computable with invalid, it seems
in part because you don't understand the difference
between knowledge and truth.

Spot on.

Everyone has simply assumed that the behavior of the
input to a decider must exactly match the direct
execution of this input. They only did this because
everyone rejected simulation out-of-hand without review.

Because that is the DEFINITION of what it is to decide
on.

A "decider" that returns the wrong result is no good.

Since the DEFINITION of "Correct Simulation" that you are
trying to use (from a UTM) means a machine the EXACTLY
reproduces the behavior of the direct exectution of the
machine described by the input, the correct simulation
must exactly match the behavior of the direct execution.
You can't get out of it by trying to lie about it being
different.

Yet somehow

This caused them to never notice that the input
simulated according to its correct semantics does call
its own decider in recursive simulation thus cannot
possibly return to its caller. The Linz proof is
sufficiently isomorphic so this equally applies to the
Linz TM proof.

The recursion has nothing to do with it. The correct answer is "does not
halt", thereby returning and halting, contradicting the result.

If HHH were to report on the direct execution of DDD it
would be breaking the definition of a halt decider that
only computes the mapping from its input...

Nope. Since the mapping that it is supposed to compute is
DEFINED as based on the direct exectut

No it never has been this. I has always been a mapping
from the behavior that the finite string specifies. It has
never been the behavior of the actual computation that the
decider is contained within.

And that string specifies the behaviour of the containing computation.
This Strange Loop is the whole POINT.

And thatg behavior is specified to be the behavior of the
program the input represents. PERIOD.

That has never been true. It is always the case that every
decider of any kind only computes the mapping from its input
finite string and never gives a rat's ass about anything
else anywhere else.

No, you are confusing capability with requirements.
A "Foo Decider" has ALWAYS been required to compute the "Foo"
mapping, as that mapping is defined.
The "Halting" mapping is defined as the behavior of the
machine/ input represented by the input, so the input needs
to be a representation of the program and input and the
decider tries to compute the mapping of that representation
to the behavior that program represents.

So, the behavior of the program the input describes *IS* the
mapping that HHH needs to try to compute to be a halt
decider, as that is the mapping that Halting defines.
Now, it is only CAPABLE of computing a computable mapping,
like a finite length emulation of the input, and since it has
been shown that Halting is NOT a computable mapping, there
will be some inputs (like H^) that the decider WILL get
wrong. That doesn't say the problem is wrong, or specifies
the wrong mapping, just that the problem can't be done with a
computation.
Your HHH may be a decider, if it ALWAYS halts for any input
give to it, but since the answer it gives doesn't always
match the Halting mapping, it just isn't a Halt Decider.

The semantics of my 100% fully specified concrete example
conclusively proves that the behavior of DDD correctly
emulated by HHH is a different sequence that the directly
executed DDD().

"100% fully specified concrete" yeah, I believe it.

Nope, since you have never shown the requested output, you
have no grounds to claim that you HHH does a correct x86
emulation of the input.
Remember, that means the trace is of what HHH does, so starts
with is emulating the beginnig of DDD(), and then following
the call to HHH that it makes into HHH, all the way until the
emulator decides to stop.
Then you need to point out what instruction that it correctly
emulated differed from what the actually directly executed
machine would have done, and explain WHY its difference is
correct.

*crickets*

Even a pretty stupid person can see that each HHH does
emulate its input correctly even if it does this by wild
guess. They *merely have to bother to pay attention that the
emulated lines are the same lines as the x86 source code
of DDD*
>

No, each HHH CONDITIONALLY emulates the input it is given,
and will abort its emulation and return to its caller if it
decides the input isn't going to halt. As such, to prove
infinite recursion you have to show that NONE of the emulated
HHHs will abort their emulations and return, which, since
they are the same HHH as deciding, means your top level HHH
can't do that either, so it fails to be a decider.

No, the fact that you can't prove that the "correct
emulation" differs from the Direct Execution means your claim
that they differ is a lie, and thus HHH is just wrong about
it deciding that DDD will not halt, when it does.

Note, this is NOT a correct emulation, and is just your way
to try to LIE. We need to see the instruction of HHH here.
>

In other words you cannot see that the following code exactly
matches the x86 source-code of DDD thus proving that the
second HHH did emulate it input correctly?
>

Your problem is that that is not the COMPLETE x86 source code
of the PROGRAM DDD, as that needs the code for HHH included in
it. A correct x86 emulation of DDD includes the correct
emulation of HHH.
>

It does do this yet mixing in the 200 pages of other code makes
it too difficult to see the execution trace of DDD.

"this margin is too small"
It would be easier if the inner levels were indented.

But your HHH doesn't "Correctly Simulate" DDD by the same
definition that makes that true.
>

When I state verified facts I am definitely not a liar even when I
do not make this verification available to others.

You are not definitely speaking the truth. I also have a dragon in my
garage.

It has always been a tautology.
I conclusively proved that with the execution trace that you are
persistently trying to get way with ignoring.

Nope, depends on the meaning you give the words.

This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

What the shit was this exchange

And since the D that H has been simulating (that is what its simulated
D means) will Halt when we look at its full behavior, the condition is
not true.
You just don't understand the difference between the D (that H is
simulating) and the simulation that H does of that D.

That is to say, H doesn't (correctly) simulate D.

The input D has its actual behavior whether we know it or not, so that
behavior exists before we ever run or simulate the program. We only
know that behavior by actually running or simulating the program, and
conclusivel seeing what it does, or being able to correct prove that
behavior.

And simulation doesn't change that behaviour.

Since your H *DOES* abort its simulation and return to its caller (the
other Hs, like the one that doesn't return are only hypotheticals, not
the one you are proposing as the ONE that main calls and returns your
claimed right answer, then the behavior of the PROGRAM D is to call H,
and then H *WILL* return to it, and then D will return.
The fact that H can't simulate to that point is irrelevent for the
behavior of D, only for the knowledge of H.

Since you call a partial simulation as being a "Correct Simulation",
if HHH does a partial simulation of DDD and returns to its call, then
the DDD that this DDD that HHH has only partially simulated and
returned to an instance of will be halting and reach that final
instruciton.
Thus, by the definitions you are trying to use, it is not true.
*IF* you accept that the only correct simulation is a complete
simulation, then it is a tautology, but your HHH that answers doesn't
do one, and is given a DIFFERENT DDD then the one built on the HHH

Which he has confusingly implemented with the static Root.

that does one (since the code of HHH is part of the code of the
PROGRAM DDD, which is what the input represents) so you can't use the
"tautology" to say HHH is right, and thus those claims are just,
again, LIES.
You "execution trace" just proves tha that you don't understand the
question, as it is NOT a "x86 simulation" of the input DDD, as HHH
clearly doesn't trace through all the code of HHH. So, your claim is
just a lie.

>
Right and you never see the word "UNTIL" even if I repeat it 10,000
times because you are only playing head games.

But the CONDITION isn't that it won't halt until aborted, but it will
not halt EVER

Of course an aborted simulation halts. It should then return "halting".

When you insist on disagreeing with the semantics of the x86 language an
many times as you have it is unreasonably implausible to construe this
as any sort of honest mistake.

Please see my answers above.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.