Decidability Decider H

[olcott]

A single H can consistently correctly determine whether or not its input
is pathological relative to itself. When H(D,D) is invoked in
decidability decider mode determines that D is pathological relative to
itself this enables a batch file to invoke H1(D,D) to get the actual
behavior of the directly executed D(D). H1 is identical to H except for
the pathological relationship to H.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[Python]

Child molester, Peter Olcott wrote:
> A single H can consistently correctly determine whether or not its input
> is pathological relative to itself. When H(D,D) is invoked in
> decidability decider mode determines that D is pathological relative to
> itself this enables a batch file to invoke H1(D,D) to get the actual
> behavior of the directly executed D(D). H1 is identical to H except for
> the pathological relationship to H.
>

No. It can't.

[Richard Damon]

On 7/2/23 8:45 PM, olcott wrote:
> A single H can consistently correctly determine whether or not its input
> is pathological relative to itself. When H(D,D) is invoked in
> decidability decider mode determines that D is pathological relative to
> itself this enables a batch file to invoke H1(D,D) to get the actual
> behavior of the directly executed D(D). H1 is identical to H except for
> the pathological relationship to H.
>

Only if its input isn't a Turing Complete environment. TO be Turing
Complete, teh environment needs to allow the machine being decided on
have its own (private) copy of the Halt Decider, at which point your
algorith for H can't tell when the input has called that copy.

Note, the representation of the copy that it is using doesn't need to
match that of the decider deciding on it to be an equivalent copy, so H
can't just use a simple sub-string compare to detect it.

You have just shown yourself too ignorant of what you are actually
talking about to understand this, so I am expecting some stupid response.

[Richard Damon]

On 7/2/23 8:45 PM, olcott wrote:

> A single H can consistently correctly determine whether or not its input
> is pathological relative to itself. When H(D,D) is invoked in
> decidability decider mode determines that D is pathological relative to
> itself this enables a batch file to invoke H1(D,D) to get the actual
> behavior of the directly executed D(D). H1 is identical to H except for
> the pathological relationship to H.
>

And does an input D that uses this FULL algorithm give your algorithm
problems?

Since H(D,D) will (apparently) determine that the input is pathological,
and thus defer to H1(D,D), then when we actually run D, appearently it
will get that same answer from H1 and do the opposite of it, and thus H1
will be wrong.

Remember, the "Pathological" program is built on a copy of the ACTUAL
program that you ask to decide on it, including ALL of its "tricks",
including things like this "batch processing".

You seem to be assuming that there is some "Operationg System" outside
the Decider - Input structure, but there isn't, at least not one that
can affect the answer of the problem.

[olcott]

I spent 12 hours a day for the last 10 days getting the copy the input
working. When H(D,D) (in decidability decider mode) detects that its
input is in the well defined set of pathological inputs it returns 0
indicating that its input is undecidable. The batch file that invoked H
then knows to invoke H1(D,D) to correctly report that D(D) halts.

This solution does seem to work correctly on every conventional proof in
every textbook.

[Python]

Fraudster Peter Olcott wrote:
> ...

> This solution does seem to work correctly on every conventional proof in
> every textbook.

not. at. all.

[Richard Damon]

So, what is the definition of that "Well Definde Set"? or is this just
another of your moronic oxymorons.

Note, H can't have "Modes" that are externally controlled, as it has no
input to control that, it is just a decider that is given an input to
decide on.

If you have some "fuller" algorithm you use to decide that uses the
sub-function H to do a step, then D needs to be built on that fuller
algorithm, as THAT is what you are actually claiming to be your halt
decider.

I guess you are just making it painfully obvious that you don't
understand the nature of the problem you claim to be working on.

So, since it seems that you have some sort of "batch file" that is your
actual decider, you need to show how you have a program invoke that and
do tha tin D. If you can't, you are just admitting that you are not
working on the actual problem defined, but are playing games in the
sub-Turing Complete versions of the problem, which has many known solutions.

It seems that you just wasted 120 hours of work and just proved that you
are totally ignorant of the problem and don't know what you are talking
aobut.

[Richard Damon]

On 7/2/23 10:01 PM, olcott wrote:

So, did you make your "conventional proof" template actually use a copy
of your ACTUAL decider (which seems to be your "batch file" not the C
funciton H), or are you just admitting that you wasted 120 hours looking
at the wrong thing because you have made yourself intentionally ignorant
of the subject so you don't understand what you are trying to do.

[olcott]

New_D copies its input and simulates its input with its input.
It never sees New_H.

[olcott]

A set is a well-defined collection of objects called elements or members
of the set. If x is a member of the set S, we write x ∈ S, and if x is a
not member of the set S, we write x ∈ S Here, well-defined means that
any given object must either be an element of the set, or not be an
element of the set.
https://www.math.uvic.ca/faculty/gmacgill/guide/sets.pdf

My definition of well-defined set is that it includes and excludes a
body of finite string pairs such that the second element of this pair
that can be encoded in an infinite number of different ways that cannot
even be foreseen in advance, all of which have the property of a
pathological relationship to their decider.

Since my system requires that the behavior of the input must be
considered in making this assessment it is a semantic property.

> Note, H can't have "Modes" that are externally controlled, as it has no
> input to control that, it is just a decider that is given an input to
> decide on.
>

Technically you are correct on this when construed as computable
functions.

> If you have some "fuller" algorithm you use to decide that uses the
> sub-function H to do a step, then D needs to be built on that fuller
> algorithm, as THAT is what you are actually claiming to be your halt
> decider.
>

It is only a matter of returning 1 for non-halting and halting inputs
and returning 0 for pathological inputs, thus the actual computation is
identical except for a single bit of the return value.

We could also simply run the input where H(D,D) != H1(D,D) means
pathological input, thus accept the H1(D,D) value as correct.

> I guess you are just making it painfully obvious that you don't
> understand the nature of the problem you claim to be working on.
>

I foresaw this objection before you made it.

> So, since it seems that you have some sort of "batch file" that is your
> actual decider, you need to show how you have a program invoke that and
> do tha tin D. If you can't, you are just admitting that you are not
> working on the actual problem defined, but are playing games in the
> sub-Turing Complete versions of the problem, which has many known
> solutions.
>

Batch files and Bash scripts can take different paths depending on the
return value of their executable.

> It seems that you just wasted 120 hours of work and just proved that you
> are totally ignorant of the problem and don't know what you are talking
> aobut.

You will say that no matter how correct that I prove to be.

[olcott]

u32 H_DD = H(D,D);
u32 H1_DD = H1(D,D);
if (H_DD != H1_DD)
Output("H1(D,D) correct halt status is:", H1_DD);

H1(D,D) correct halt status is:1

[Richard Damon]

And how do you detect this? You just admitted that there are an infinite
number of them, so you can't just string compare to detect it.

>
> Since my system requires that the behavior of the input must be
> considered in making this assessment it is a semantic property.

But you still haven't described how you detect it.

>
>> Note, H can't have "Modes" that are externally controlled, as it has
>> no input to control that, it is just a decider that is given an input
>> to decide on.
>>
>
> Technically you are correct on this when construed as computable
> functions.
>

And computations are computable functions. If the function isn't
computable, by definition no program exists that computes it.

Deciders are, by definition, Computations, so again, by definition,
don't have "modes" (except as defined by an actual input).

All this shows is that you ar playing games with words, and have
deceived yourself.

If H has "Modes", it isn't the Decider, so showing that you can get the
correct answer for the D built on IT is meaningless, you need to show
you can get the correct answer for the D built on your actual decider,
not just a piece of it.

>> If you have some "fuller" algorithm you use to decide that uses the
>> sub-function H to do a step, then D needs to be built on that fuller
>> algorithm, as THAT is what you are actually claiming to be your halt
>> decider.
>>
>
> It is only a matter of returning 1 for non-halting and halting inputs
> and returning 0 for pathological inputs, thus the actual computation is
> identical except for a single bit of the return value.
>
> We could also simply run the input where H(D,D) != H1(D,D) means
> pathological input, thus accept the H1(D,D) value as correct.

You need to make clear what type of decider you are defining. If a Halt
Decider, then there is no allowed change of answer.

IF you are trying to refute Rice, then you need to clearly define the
property that you are going to use, which your above definition requires
a FIXED H/H1 to be defined, and that the property is actually Semantic.
The fact that it is defined by executing your deciders is NOT enough.

One important thing that you seem to be missing is that Rice's Theorem
is NOT about "Programs" and their behavior, but about Functions and
languages, and their ability to be recognized by a program.

You still need to show that your property is semantic, and the fact that
you can determine that value without needing to actually run the input
shows that it isn't.

>
>> I guess you are just making it painfully obvious that you don't
>> understand the nature of the problem you claim to be working on.
>>
>
> I foresaw this objection before you made it.

But didn't answer it.

>
>> So, since it seems that you have some sort of "batch file" that is
>> your actual decider, you need to show how you have a program invoke
>> that and do tha tin D. If you can't, you are just admitting that you
>> are not working on the actual problem defined, but are playing games
>> in the sub-Turing Complete versions of the problem, which has many
>> known solutions.
>>
>
> Batch files and Bash scripts can take different paths depending on the
> return value of their executable.

Right, but now the "Decider" is a "Batch Script" so the program D must
be able to do the equivalent of that batch script, or you system doesn't
acccept a Turing Complete set.

>
>> It seems that you just wasted 120 hours of work and just proved that
>> you are totally ignorant of the problem and don't know what you are
>> talking aobut.
>
> You will say that no matter how correct that I prove to be.
>

Only when I show you are wrong. Actually try to answer my objections

[Richard Damon]

So, what returns the actual results of the Halt decision?

Remember, THAT is what D will call, not H or H1, since neither, by
themselves, is a halt decider.

That seems to mean that your ACTUAL Halt Decider HD(P, m) would be
something like:

HD(P, m) {
u32 H_DD = H(P, m);
u32 H1_DD = H1(P, m);
return (H_DD == H1_DD) ? H_DD : H1_DD;
}

and

D is defined something like:
D(P) {
if(HD(P,P)) {
while(1) ;
}
}

Which still gives the wrong answer.


You seem to be forgetting what a Halt Decider needs to be.

[Richard Damon]

Why not? Since New_H is the thing that is considered the "Correct Halt
Decider", New_D needs to be built on it.

You keep on forgetting that the proof says we create a specific input
for the given halt decider claimed to be correct, and the only halt
decider that input is claimed to not be decidable with is that one.

SHowing that New_H can answer for the input designed on H means nothing,
you need to show that it can handle the input designed for itself.

THAT is where the actual self-reference occurs, that there exists within
the set of "any program" a program built on the decider in this manner.

[olcott]

New_H is embedded within New_D (as its middle states) just the
way it is supposed to be. The question is: Does New_H(New_H) halt?

The only difference at the source code level is:
(a) New_H copies its input, thus takes one param.
(b) New_H has an infinite loop at its accept state.

> You keep on forgetting that the proof says we create a specific input
> for the given halt decider claimed to be correct, and the only halt
> decider that input is claimed to not be decidable with is that one.
>
> SHowing that New_H can answer for the input designed on H means nothing,
> you need to show that it can handle the input designed for itself.
>
> THAT is where the actual self-reference occurs, that there exists within
> the set of "any program" a program built on the decider in this manner.

[Richard Damon]

So, how is New_H a halt decider then?

Or are you just being deceptive about what problem you are solving again.

If New_H is about your 'Rice' problem machine, I showed why your
property wasn't semantic, so doesn't disprove the Rice proofs.

Remember, the definition based on "executing" are based on executing the
machine described on the input, NOT on executing the decider.

After all, of course a property based on the execution decider is decidable.

You seem to be just building a great big argument out of strawmen, and
Red Herring, and forgetting the actual problem you claim to be working on.

[olcott]

What about a three valued decider?
0=undecidable
1=halting
2=not halting

[olcott]

typo

The only difference at the source code level is:

(a) New_D copies its input, thus takes one param.
(b) New_D has an infinite loop at its accept state.
Other than that (at the source-code level) New_D is exactly New_H

[olcott]

At the Turing machine level any D can make it impossible for a
particular H to be unable to correctly report on the behavior of the
directly executed D(D). Because D is a fixed constant finite string it
cannot dynamically reconfigure itself to fool a different H.

[Richard Damon]

So, you don't understand the problem.

D doesn't even exist as an input until you define the H that you want to
claim to be correct, then you make the H^/P/D that shows that THAT H
doesn't get all inputs right.

Thus 'D' is only a 'fixed constant finite string' in the context of a
given H, and while you can give that string to a different decider, it
doesn't actualy prove anything, except that the answer the H it was
designed for is wrong.

Thus, your whole arguement is based on a category error.

[Richard Damon]

Doesn't meet the definition of a Halt Decider.

After all, ALL inputs to H represent a computation that either Halts or
Not, so "Undecidable" isn't a correct answer for the behavior of that
machine.

So, all you are doing is showing that you don't understand that actual
problem you claim to be solving.

[Richard Damon]

But New_D needs to call New_H, and so at the source code level, which
includes ALL the source code of the program, it is different.

If New_D doesn't call New_H, then it is no longer a proof program for
New_H, so New_H hasn't refuted the "pathological program proof".

You just are showing you don't understand the nature of the problem you
are claiming to solve.

[olcott]

So you want a TM to decide halting for an imaginary input?
That is not the way that computation actually works.

In computability theory and computational complexity theory, a decision
problem is a computational problem that can be posed as a yes–no
question of the input values.
https://en.wikipedia.org/wiki/Decision_problem

TM's do not take ideas held within the mind as their inputs, they only
take fixed constant finite strings as inputs.

[olcott]

On 7/3/2023 10:35 AM, Richard Damon wrote:
> On 7/3/23 10:42 AM, olcott wrote:
>> On 7/3/2023 8:13 AM, Richard Damon wrote:
>>> On 7/2/23 11:10 PM, olcott wrote:
>>
>>> Only when I show you are wrong. Actually try to answer my objections
>>
>>
>> What about a three valued decider?
>> 0=undecidable
>> 1=halting
>> 2=not halting
>>
>
> Doesn't meet the definition of a Halt Decider.
>

Because these are semantic properties based on the behavior of
the input it does refute Rice.

> After all, ALL inputs to H represent a computation that either Halts or
> Not, so "Undecidable" isn't a correct answer for the behavior of that
> machine.
>
> So, all you are doing is showing that you don't understand that actual
> problem you claim to be solving.

[olcott]

Not in the Peter Linz proof:
https://www.liarparadox.org/Linz_Proof.pdf

In the Linz proof a copy of H is directly embedded
within Ĥ at this state: Ĥq0 Wm Wm
The original H remains unchanged.

The halting problem is about undecidable inputs, it is not about
inserting bugs into a halt decider to make it cease to function.

[Richard Damon]

On 7/3/23 11:44 AM, olcott wrote:
> On 7/3/2023 10:35 AM, Richard Damon wrote:
>> On 7/3/23 10:42 AM, olcott wrote:
>>> On 7/3/2023 8:13 AM, Richard Damon wrote:
>>>> On 7/2/23 11:10 PM, olcott wrote:
>>>
>>>> Only when I show you are wrong. Actually try to answer my objections
>>>
>>>
>>> What about a three valued decider?
>>> 0=undecidable
>>> 1=halting
>>> 2=not halting
>>>
>>
>> Doesn't meet the definition of a Halt Decider.
>>
>
> Because these are semantic properties based on the behavior of
> the input it does refute Rice.

Nope. Rice's theorem doesn't allow for an 'undecidable' output state either.

Either the input is or is not something that is in the set defined by
the function/language defined.

Undecidable is just admitting that Rice is true.

[Richard Damon]

Or, to put it another way, to add the "Undecidable" output state means
that you are admitting that Halting IS undecidable, and thus the Halting
Theorem, which states that, is correct and you are not trying to refute it.

The second part of the problem then is that for any H that gives an
answer to H(D,D) the "undecidable" answer, or which is provably
non-answering, will be incorrect, as that input IS decidably Halting or
Non-Halting (Depending on the behavior assigned in D to the undecidable
answwer as "contrary", but both Halting and Looping Forever are contrary
to not being decidable).

The interesting thing about halting is the "undecidable" case can NEVER
actually be proven, as that leads to a contradiction, as an undecidable
machine MUST be non-halting, as all Halting Machines can be proven in
finite time to Halt, so the only way to actually be undecidable is to be
non-halting, so proving undecidable actually proves that it would be
decidable as non-halting.

[Richard Damon]

Nope, it must decide for ALL inputs, even those that haven't been
'created' yet.

Once you create H, you can create D. That will be one of the infinite
set of possible inputs that H was designed to decide on.

When we RUN H, the input exists. Until you decide on what H will be, we
don't know which of all the possible inputs D will be.

>
> In computability theory and computational complexity theory, a decision
> problem is a computational problem that can be posed as a yes–no
> question of the input values.
> https://en.wikipedia.org/wiki/Decision_problem

Right, and it must accept ALL inputs, it can take the input based on
itself, which we don't know which one it will be until we define the
decider.

>
> TM's do not take ideas held within the mind as their inputs, they only
> take fixed constant finite strings as inputs.
>

Right, but since it takes ALL inputs, it can take an input based on
itself, which of course we can't figure out which of the infinte number
of possible inputs it will be until we define the decider.

You keep on missing that 'D' isn't a fixed input that breaks ALL
deciders, but an input that is only shown to break a particular decider
(but any of them). The proof define a TEMPLATE to construct this input
from the decider, and thus shows that for ANY decider we can make such
an input that it can't decide.

Thus, changing H means you need to look at the D built on it, which will
be a different input then the 'D' built on any other decider.

This is why Linz used the ^ notation, given any decider H, you can make
the input H^ that shows it is wrong. The ^ marking a transformation. If
the decider is H1, then the input is H1^. This allows for the discussion
of "all deciders".

The H/P and H/D notations have built in that we are talking about a
particular H for the whole discussion, or we need to go to Hn / Pn type
notations.

Your omitting of distinct names for you various versions of H is just
your attempt to be intentionally deceptive, as shown by your claim that
D is a 'fixed string', for all H, when it is only a fixed string for a
given H. Each Hi gets its own fixed string Di.

[Richard Damon]

Right, and in Linz, H is the decider that is claimed to give the right
answer.

That isn't 'H' in your system, but the script that decides whether to
use H or H1.

Your error is in calling the wrong thing 'H'

You are just showing you are lying by using the wrong name for things.

[olcott]

On 7/3/2023 10:58 AM, Richard Damon wrote:
> On 7/3/23 11:44 AM, olcott wrote:
>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>> On 7/3/23 10:42 AM, olcott wrote:
>>>> On 7/3/2023 8:13 AM, Richard Damon wrote:
>>>>> On 7/2/23 11:10 PM, olcott wrote:
>>>>
>>>>> Only when I show you are wrong. Actually try to answer my objections
>>>>
>>>>
>>>> What about a three valued decider?
>>>> 0=undecidable
>>>> 1=halting
>>>> 2=not halting
>>>>
>>>
>>> Doesn't meet the definition of a Halt Decider.
>>>
>>
>> Because these are semantic properties based on the behavior of
>> the input it does refute Rice.
>
> Nope. Rice's theorem doesn't allow for an 'undecidable' output state
> either.
>
> Either the input is or is not something that is in the set defined by
> the function/language defined.
>
> Undecidable is just admitting that Rice is true.
>

Undecidable <is> a semantic property.

>>
>>> After all, ALL inputs to H represent a computation that either Halts
>>> or Not, so "Undecidable" isn't a correct answer for the behavior of
>>> that machine.
>>>
>>> So, all you are doing is showing that you don't understand that
>>> actual problem you claim to be solving.
>>
>

[olcott]

None-the-less you continue to assert that it must take ideas as inputs.
It just doesn't work that way.

[olcott]

You are using double-talk in a lame attempt to show that
Linz H cannot correctly determine the halt status of Linz Ĥ.

[Richard Damon]

So you agree with the Theorem.

No 'Linz H' can exist that correctly decides the halt status of Linz Ĥ
applied to the description of Linz Ĥ.

That is EXACTLY the consequence of the Halting Theorem.


Please show an ACTUAL 'Linz H' that correctly gets the results of the
'Linz Ĥ' built on it. You keep on changing H and trying to use the old Ĥ
which just fails to meet the requirement of the proof, likely because
you just don't understand the theory involved.

[Richard Damon]

Nope, Where did I say THAT. It is just your interpreation of what I say
because you don't understand what I am saying.

H is ALWAYS given a description of an actual concrete machine, the
machine D which is built from H. Since it is built on the actual machine
H, it can't actually exist until H does, but that doesn't make it 'just
an idea', as D can come into existance (since it is defined by a
template) the instant after H is defined, and you can't actually RUN the
H on an input to after that anyway. So the REAL AND ACTUAL input exists
(that shows H to be wrong) as soon as H is created, and is thus
available as an actual input to run on it.

Please try to explain where that requires H to take an "Idea" as an input.

The only point that happens is when H is also "just an idea".

[Richard Damon]

On 7/3/23 12:05 PM, olcott wrote:
> On 7/3/2023 10:58 AM, Richard Damon wrote:
>> On 7/3/23 11:44 AM, olcott wrote:
>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>> On 7/3/23 10:42 AM, olcott wrote:
>>>>> On 7/3/2023 8:13 AM, Richard Damon wrote:
>>>>>> On 7/2/23 11:10 PM, olcott wrote:
>>>>>
>>>>>> Only when I show you are wrong. Actually try to answer my objections
>>>>>
>>>>>
>>>>> What about a three valued decider?
>>>>> 0=undecidable
>>>>> 1=halting
>>>>> 2=not halting
>>>>>
>>>>
>>>> Doesn't meet the definition of a Halt Decider.
>>>>
>>>
>>> Because these are semantic properties based on the behavior of
>>> the input it does refute Rice.
>>
>> Nope. Rice's theorem doesn't allow for an 'undecidable' output state
>> either.
>>
>> Either the input is or is not something that is in the set defined by
>> the function/language defined.
>>
>> Undecidable is just admitting that Rice is true.
>>
>
> Undecidable <is> a semantic property.

Source of that Claim?

And you aren't saying the Undecidable <IS> a semantic property, but is
an answer for if an input <HAS> some specific semantic property.

[olcott]

It took me two years to figure out a clean way to copy the input to
Linz_H_Hat and not have the system crash. Relative to Linz_H_Hat
Linz_H is H1. Now Linz_H_Hat only contradicts itself.

[olcott]

[olcott]

In computability theory, Rice's theorem states that all non-trivial
semantic properties of programs are undecidable. A semantic property is
one about the program's behavior
https://en.wikipedia.org/wiki/Rice%27s_theorem

Undecidable <is> a semantic property of the finite string pair: {H,D}.

[Richard Damon]

So, you are admitting that you actually can't do what is required?

Copying the input should be trivial, as the input should be a
representation that packages a full program in its own virtual
environment, so a simple bit by bit copy to empty ram will work. Your
problem is that you don't put the input into its own virtual address
space, so you have pathological interactions.

Linz_H_Hat must be built on the exact code base that is deciding on it,
in this case H, since you just said it isn't, your proof is invalid.

Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
truth values, only behavior. You are just showing that you don't
understand the basics of the requirements, and seem to think that
"close" is good enough for proofs.

[Richard Damon]

Right, haven't been created at the time the decider is created, but will
have been when it is run.

This is part of needing to handle ALL inputs. Not all inputs can exist
at any given point time, as it is an infinite set. The given input needs
to be created before you can run the decider on it.

[Richard Damon]

[Richard Damon]

As I mentioned, many simple descriptions get it wrong. Note, later in
the same page it says:

It is important to note that Rice's theorem does not concern the
properties of machines or programs; it concerns properties of functions
and languages.

So, it isn't pointing out that a given program is "Undecidable", or a
given decider is "undecidable" on a given input, but that the
mathematical function "Halting" representing the property of the machine
reaching a final state is undecidable, i.e., no decider program can give
the correct answer for all inputs.

Note also, the statement you quote does not say that "undecidable" is a
PROPERTY that Rice's Theorem is talking about, but that all semantic
properties end up having the attribute of being undecidable, i.e., there
is no "program" that can be given all possible inputs and always give
the correct answer (that the input has or doesn't have that property).

Note, Rice talks NOTHING about your finite string pairs {H,D}, but that
for the property that H is defined to try to decide on, there WILL be
some input that H will either not halt on, or give the wrong answer.

It is the PROPERTY that is "Undecidable", not a particular case.

[olcott]

The relative addressing of the x86 language causes all function
calls to call the wrong address.

> as the input should be a
> representation that packages a full program in its own virtual
> environment, so a simple bit by bit copy to empty ram will work. Your
> problem is that you don't put the input into its own virtual address
> space, so you have pathological interactions.
>
> Linz_H_Hat must be built on the exact code base that is deciding on it,
> in this case H, since you just said it isn't, your proof is invalid.
>

Linz_Hat <is> Linz_H that takes one param and copies it instead of
two params and has an infinite loop at its accept state.

> Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
> truth values, only behavior. You are just showing that you don't
> understand the basics of the requirements, and seem to think that
> "close" is good enough for proofs.

Linz_H_Hat(Linz_H_Hat) returns 0.

[olcott]

Not unless the guy that wrote the decider also wrote its input.
Until then the input you refer to is only imaginary.

[olcott]

H correctly accepts every language specified by the pair: {H, *}
(where the first element is the machine description of H and the
second element is any other machine description) or rejects this
pair as undecidable.

[Richard Damon]

Why do you say that? As I said, it actually exist when we run the
decider on it.

There is NO requirement that the creater of the decider to have "seen"
all the inputs that it might have to handle.

Or don't you understand the requirement to handle *ALL* inputs?

Remember, that ALL inputs represents an INFINITE number of possible
inputs, so they CAN'T all be listed, or "exist" yet.

[Richard Damon]

So, you are admitting you don't understand what you are saying.

D isn't "undecidable" but always has definite behavior based on the
behavior of the definite machine H that it was based on (and thus you
are being INTENTIONALLY dupicious by now calling H to be a some sort of
other decider).

Since you claim that Halt-Decider-H "Correctly" returned false for
H(D,D) we know that D(D) Halts, so D the problem of D has an answer so
hard to call "undecidable"

Again, what is the definition of your "Language", and why do you call
{H,D} as UNDECIDABLE, since H will be a FIXED DEFINED decider that is
just WRONG about its input, that isn't "undecidable".

[Richard Damon]

Only because you aren't interpreting the input properly, but in a
non-Turing Complete manner.

As I said, the input description should be a chunck of code in a virtual
address space with a header that tells where that code is supposed to be
considered to be located at.

>
>> as the input should be a representation that packages a full program
>> in its own virtual environment, so a simple bit by bit copy to empty
>> ram will work. Your problem is that you don't put the input into its
>> own virtual address space, so you have pathological interactions.
>>
>> Linz_H_Hat must be built on the exact code base that is deciding on
>> it, in this case H, since you just said it isn't, your proof is invalid.
>>
>
> Linz_Hat <is> Linz_H that takes one param  and copies it instead of
> two params and has an infinite loop at its accept state.

So, Two things that are different are exactly the same?

You don't seem to understand what you are doing.

Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined behavior.
That behavior is a function of its input, but hasn't been assigned any
"meaning".

Linz_H is a Turing Machine (if it actually can exist) that has a defined
meaning/requirement for its final states. Linz_H, to meet its
requirements, MUST go to Qy if the input represents a Halting
Computation, and MUST go to Qn if the input represents a non-halting
computation.

Since Linz_H has actual requirements, a claimed implementation of it can
be checked to see if it actually meets the requirements, and perhaps we
can determine if it is possible to meet them.

>
>> Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
>> truth values, only behavior. You are just showing that you don't
>> understand the basics of the requirements, and seem to think that
>> "close" is good enough for proofs.
>
> Linz_H_Hat(Linz_H_Hat) returns 0.
>

Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
defined meaning for Linz_H_Hat as it isn't defined to be a decider.
Linz_H_Hat USES decider to determine its behavior, but its behavior
doesn't have any defined "meaning" about anything.

Note, since H has requirements, we can check if it meet them.

Since you say that Linz_H applied to Linz_H_Hat Linz_H_Hat will
"correctly" go to Qn to say that its input is non-halting, and we know
that Linz_H_Hat ends with a copy of Linz_H and a tape that has
Linz_H_Hat Linz_H_Hat we know that this copy will ALSO go to Qn, which
is still a final state of Linz_H_Hat, so Linz_H_Hat applied to
Linz_H_Hat will halt, which is the meaning of the input applied to
Linz_H. This means that Linz_H applied to Linz_H_Hat Linz_H_Hat, to meet
its requirement MUST go to Qy to say its input represents a Halting
Computation, thus we show that your Linz_H just FAILS to meet its
requirements.

Linz_H_Hat, on the other hand, had no "requirements" it needed to meet,
except to act like it was programmed (to act contrary to the answer it
gets from H) which it did, so there is nothing wrong with Linz_H_Hat.

Note, you can't get a "Contradiction" when the behavior has no meaning.
You seem to want to embed into H_Hat some meaning, but it just doesn't
have it. The only behavior with meaning is the behavior of H (including
the copy with H_Hat, but that isn't transfered to maining of H_Hat itself).

[olcott]

It only exists in the imagination until someone actually creates the
finite string.

[olcott]

{H,D} undecidable means that D is undecidable for H, which is an
verified fact. The set of {H,*} finite string pairs do define a
language. Decidability <is> a semantic property because it
can only be correctly decided on the basis of behavior.

[olcott]

It exactly matches the Linz spec.

> You don't seem to understand what you are doing.
>
> Linz_H_Hat (not Linz_Hat) is a Turing Machine with a defined behavior.
> That behavior is a function of its input, but hasn't been assigned any
> "meaning".
>
> Linz_H is a Turing Machine (if it actually can exist) that has a defined
> meaning/requirement for its final states. Linz_H, to meet its
> requirements, MUST go to Qy if the input represents a Halting
> Computation, and MUST go to Qn if the input represents a non-halting
> computation.
>
> Since Linz_H has actual requirements, a claimed implementation of it can
> be checked to see if it actually meets the requirements, and perhaps we
> can determine if it is possible to meet them.
>
>>
>>> Note, Linz_H_Hat CAN'T "Contradict" itself, as doesn't generate any
>>> truth values, only behavior. You are just showing that you don't
>>> understand the basics of the requirements, and seem to think that
>>> "close" is good enough for proofs.
>>
>> Linz_H_Hat(Linz_H_Hat) returns 0.
>>
> > Actually no. Linz_H_Hat(Linz_H_Hat) halts at state Qn, which has NO
> defined meaning for Linz_H_Hat as it isn't defined to be a decider.

Linz_H and Linz_H_Hat are C functions.
Linz:H and Linz:Ĥ are Turing machines.

Linz_H and Linz:H are both directly embedded within a copy of
Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
to Ĥ.qn still means not halting.

This allows Linz_H and Linz:H correctly report on the actual
behavior of their input.

[olcott]

Using Rogers' characterization of acceptable programming systems, Rice's
theorem may essentially be generalized from Turing machines to most
computer programming languages: there exists no automatic method that
decides with generality non-trivial questions on the behavior of
computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

H correctly divides inputs into
(a) Halting
(b) Not halting
(c) Cannot be decided by H

[Richard Damon]

So?

We CAN create it to give to H to ask it the question.

Thus, what is the problem with doing that?


The fact that you can imagine ways to do it wrong doesn't mean you can't
do it right.

This is just more of your backwards logic, showing you have been just
slinging more Red Herring because you can't handle the actual issue,
that your H will ALWAYS get the wrong answer when asked this question
(if it answers at all, which just shows another way to be wrong).

[Richard Damon]

What do you mean by "Undecidable by H?"

A given input has a fixed answer about if it has a specific property,
and a given program has a fixed answer that it will give with that input
that might be either correct or incorrect (or the program might just not
answer, and thus be incorrect for another reason). Thus a given
program-input pair either shows a CORRECT or INCORRECT answer for a problem.

The fact that a given H is WRONG about an input doesn't make that input
"Undecidable"

You are just showing you dopn't understand the meaning of the word.

Decidability isn't a property of an individual decider, or an individual
input, it is a property of a PROBLEM.

A given input will either have or not have any specific property, so
there isn't a "Decidability" issue. It may be true that we can't build a
program to determine this for all inputs, and then that PROPERTY is
given the ATTRIBUTE of being "Undecidable".

[Richard Damon]

And where do you see anything that allows H to be "correct" in giving
answer (c)?

The specific input either represents a machine that does (a) or does
(b), so in no case is the results of "it can not be decided" be correct.

You are just showing that you fundamentally don't understand what you
are talking about.

The question follows the rule of the excluded middle, so there is no
valid answer (c).

[Richard Damon]

So, inventing new terminology without introduction, thus showing you are
being intentionally deceptive.

>
> Linz_H and Linz:H are both directly embedded within a copy of
> Linz_H_Hat and Linz:Ĥ thus a return value of 0 or a transition
> to Ĥ.qn still means not halting.

No, because Linz_H_Hat / Linz:Ĥ are not "Halt Deciders" so there return
value has no meaning.

Ĥ has no meaning, so it can't be "incorrect" or contradicted.

>
> This allows Linz_H and Linz:H correctly report on the actual
> behavior of their input.
>
>

No, since BOTH have an input that when run will HALT, and both report
that it will not, both are just wrong.

Linz_H(Linz_H_Hat, Linz_H_Hat) is claimed to "correctly" return 0,
indicating non=-halting. But when Linz_H_Hat calls Linz_H(Linz_H_Hat,
Linz_H_Hat) and gets that returned 0, it Halts, so Linz_H is just wrong.

You like to clai that Linz_H won't return that answer but it MUST as is
needs to be a computation that only depends on its input, so it MUST
always do the same thing.

You have been asked before, show the first step in the direct execution
of Linz_H(Linz_H_Hat, Linz_H_Hat) and the same call from within
Linz_H_Hat that have different behavior, even though everything before
them has been identical since the call to Linz_H.

Until you provide this, you are just showing you are just a stupid
pathological liar that claims impossible things must be true.

[olcott]

H is a correct halting decidability decider for itself.
Rice says that is impossible, thus Rice is wrong.

[olcott]

H correctly determines that it cannot provide a halt status
consistent with the behavior of the directly executed D(D).

H is a decidability decider for itself, thus determining the
semantic property of finite string pairs: {H,*}.
0==Undecidable
1==Decidable
2==Decidable

[Richard Damon]

What you do mean by a "Decidability Decider"? As I have pointed out,
Decidability isn't a property of an input, but of a whole problem.


And How is it a "correct" decider when it gives the wrong answer to the
problem about D(D)?

This is NOT a "Undecidable" question, it has a correct answer, H is just
wrong about it.

You are just proving you don't understand the meaning of CORRECT and
INCORRECT.

You just don't know enough of what Rice is talking about to see how
stupid your comments are.

A perfect example of the Dunning-Kruger effect.

[Richard Damon]

So? If it REALLY could detect that, it just needs to give the opposite
answer.

Or, in other words, you are just admitting that H is wrong.

>
> H is a decidability decider for itself, thus determining the
> semantic property of finite string pairs: {H,*}.
> 0==Undecidable
> 1==Decidable
> 2==Decidable
>
>

Which is just more nonsense words.

[olcott]

*I never said that you are confused*
Linz_H_Hat(Linz_H_Hat) returns 0 permitting
Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.

[olcott]

H correctly divides finite string pairs {H,*} into decidable by H and
undecidable by H, a semantic property of these finite string pairs.

[olcott]

Try and show how D could do that.
D can loop if H says it will halt.
D can halt when H says it will loop.

How does D make itself decidable by H to contradict
H determining that it is undecidable?

[Richard Damon]

You always claim that your H by its various names is "Correct" to return
0 as the input is non-halting because its "correct simulation" will
never reach a final state.

I think your brain is turning into mush, or is your pathology
overloading and trying to reverse the argument.

> Linz_H_Hat(Linz_H_Hat) returns 0 permitting
> Linz_H(Linz_H_Hat, Linz_H_Hat) to correctly return 1.
>

But if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, which means Halting, it
means that Linz_H_Hat will go into the infinte loop on the Qy leg.

Did you miss that parto of the design in Linz's proof. H^ has modified
the end of H so that Qy becomes a non-terminal state.

Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and
halt or never halts.

[Richard Damon]

It doesn't need to, and the fact you are asking the question jkust shows
you don't understand what you are talking about.

You clearly don't understnad what "Decidability" means.

Decidability isn't a property of an input or of an decider-input pair.

If the value of the property isn't defined for the input, the property
is improperrly defined. For D from your H, the Halting Property is fully
defined, D(D) Halts (since H(D,D) returns 0).

If a decider doesn't give the right answer for a given input, it is just
wrong. There is no "could haves" as the decider is exactly what it is
programmmed to be, so always does exactly what it is programmed to do,
and the behavior of some other decider, even just slightly different
than it is irrelevent to it.

Thus, your claimed property isn't actually a valid property to try to
decide.

[Richard Damon]

No such property. Inputs are not "Decidable", problems are.

You are just showing your stupidity.

And that you just don't know what Truth means, as you are just a
pathological liar.

[olcott]

*Computable set*
In computability theory, a set of natural numbers is called computable,
recursive, or decidable if there is an algorithm which takes a number as
input, terminates after a finite amount of time (possibly depending on
the given number) and correctly decides whether the number belongs to
the set or not. https://en.wikipedia.org/wiki/Computable_set

Because A finite string can be construed as a very large integer the
above must equally apply to finite strings. That you are trying to
get away with disavowing this doesn't seem quite right. Since you only
have an EE degree we could chalk this up to ignorance.

It does seem that you acknowledge that there is no way to make
decidability undecidable.

[olcott]

Linz_H_Hat has its own embedded_H that returns 0.
Linz_H_Hat has no access to Linz_H, only to its own embedded copy.
Linz_H simply simulates Linz_H_Hat until it terminates.

> it
> means that Linz_H_Hat will go into the infinte loop on the Qy leg.
>
> Did you miss that parto of the design in Linz's proof. H^ has modified
> the end of H so that Qy becomes a non-terminal state.
>
> Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and

Linz_H_Hat is a C function Linz:Ĥ is a Turing machine.
They use the exact same algorithm.

> halt or never halts.

[olcott]

I didn't say that quite right. H is a halting decidability decider.
That really seems to be a semantic property of finite strings.

>
> You are just showing your stupidity.
>

Neither one of us are anywhere near stupid, yet calling me
stupid makes you look very immature and unprofessional.

> And that you just don't know what Truth means, as you are just a
> pathological liar.

[Richard Damon]

But embedded_H is an identical copy to Linz_H, so if embedded_H returns
0, so does Lin

> Linz_H simply simulates Linz_H_Hat until it terminates.

Then so must embedded_H, since it is an identical copy, and as you have
shown before, if H is defined that way, the H_Hat will never halt, and
thus H, since for this case you said it doesn't abort, will also never
halt and fail to be a decider.

Now, since you are claiming that the embedded_H and Linz_H are IDENTICAL
machines, but the also produce DIFFERENT results when given identical
inputs, you have just proven that you are a LIAR. A totally Pathologica
LIAR, that must believe in Faery Dust Powered Unicorn with Magic Wands
to make these two identical machines do different things.

This PROVES that you are just STUPID if you think people will beleive
your blatant lies.

>
>> it means that Linz_H_Hat will go into the infinte loop on the Qy leg.
>>
>> Did you miss that parto of the design in Linz's proof. H^ has modified
>> the end of H so that Qy becomes a non-terminal state.
>>
>> Linz_H_Hat doesn't actually "return" a value, it just goes to Qn and
>
> Linz_H_Hat is a C function Linz:Ĥ is a Turing machine.
> They use the exact same algorithm.

So. Linz_H_Hat doesn't return a value that has semantic value.

You are just off serving more Red Herring.

>
>> halt or never halts.
>>
>

[Richard Damon]

Except. as I have explained, but you can't see to understand, that
"Decidabilty" isn't a property of the the inputs, but of the problems,
so there isn't a "Decidability Decider" like you are trying to create.

All inputs to the decider have a correct answer, and if H gives an
answer in finite time, that answer is finitely computable, and thus
decidable. H just can't give the right answer because the problem is
"smarter" than it.

There is a reason there isn't a name for what you want, because it isn't
a thing but you making a category error.

>
>>
>> You are just showing your stupidity.
>>
>
> Neither one of us are anywhere near stupid, yet calling me
> stupid makes you look very immature and unprofessional.
>

No, you are showing that you are incapable of understanding the basic
facts of what you are talking about. That just shows STUPIDITY.

>> And that you just don't know what Truth means, as you are just a
>> pathological liar.
>

No, YOU don't know what Truth means, because YOU are the one that keeps
on insisting on things that are definitionally incorrect.

[Richard Damon]

Except that "Decidability" isn't a property of an "input"/Machine, but
of a PROBLEM, or one of the sets you are talking about. (not MEMBERS of
the set, which are the machines, but the set as a whole)>

So, you are confusing a property of the SET with a property of the members.

Decidability is about the ability for there to exist a machine that can
decide if its input is a member of the set. If there exist such a
machine, then the SET is computable/decidable. If not, the SET isn't
computable/decidable.

Nothing he talks about the possible members themselves being in the set
or not being a property like "decidable", it just isn't a property of
the members.

Your question is like asking if 2 is Purple.

[olcott]

Since I just quoted that to you it is reasonable that you accept it.

> Nothing he talks about the possible members themselves being in the set
> or not being a property like "decidable", it just isn't a property of
> the members.
>

Using Rogers' characterization of acceptable programming systems, Rice's
theorem may essentially be generalized from Turing machines to most
computer programming languages: there exists no automatic method that
decides with generality non-trivial questions on the behavior of
computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

H correctly determines whether or not it can correctly determine the
halting status for all of the members of the set of conventional halting
problem proof counter-examples and an infinite set of other elements.

H is deciding the semantic property of its own behavior on a set of
finite strings. The above says this can be done in C.

> Your question is like asking if 2 is Purple.

Mere empty rhetoric utterly bereft of any supporting reasoning.

[olcott]

We have gone through this many hundreds of times.
It is the exact same H(D,D) versus H1(D,D) thing.

Linz_H_Hat now has a pathological relationship to itself
this frees Linz_H from such a pathological relationship.
So Linz_H becomes H1, and Linz_H_Hat becomes H.

> Now, since you are claiming that the embedded_H and Linz_H are IDENTICAL
> machines, but the also produce DIFFERENT results when given identical
> inputs, you have just proven that you are a LIAR.

*So you are back to rejecting verified facts out-of-hand*
It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
1 and the only difference is that H1 does not have a pathological
relationship to H and it is otherwise identical to H.

[Richard Damon]

Nope, just shows you are not working in a Turing Equivalent system, and
thus NOTHING you say matters.

>
>> Now, since you are claiming that the embedded_H and Linz_H are
>> IDENTICAL machines, but the also produce DIFFERENT results when given
>> identical inputs, you have just proven that you are a LIAR.
>
> *So you are back to rejecting verified facts out-of-hand*
> It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
> 1 and the only difference is that H1 does not have a pathological
> relationship to H and it is otherwise identical to H.
>

Since youy refuse to provide the verification fact about where the paths
of H(D,D) and D(D) differ, you don't HAVE a "verified fact".

You are just proving that you are just a LIAR and an IDIOT.

What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
DEFINITION WRONG and you claim tha tit is right is a verified LIE.

[Richard Damon]

Nope, Decidability is a property of PROBLEMS or SETS, not INPUTS.

You can't seem to tell the diffence bcause of your ignorance.

>
>> Nothing he talks about the possible members themselves being in the
>> set or not being a property like "decidable", it just isn't a property
>> of the members.
>>
>
> Using Rogers' characterization of acceptable programming systems, Rice's
> theorem may essentially be generalized from Turing machines to most
> computer programming languages: there exists no automatic method that
> decides with generality non-trivial questions on the behavior of
> computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem

Yes, it doesn't need to be about Turning Machines, but it is still about
the ability to create a "program" to compute a Function / Decider for a
Language/Set.

>
> H correctly determines whether or not it can correctly determine the
> halting status for all of the members of the set of conventional halting
> problem proof counter-examples and an infinite set of other elements.

But that isn't a proper property.

You don't have "Decidability" on individual inputs, so it isn't a
Property of the input that can be decided on.

>
> H is deciding the semantic property of its own behavior on a set of
> finite strings. The above says this can be done in C.

Nope, just shows you don't understand a thing about what you are saying.

>
>> Your question is like asking if 2 is Purple.
>
> Mere empty rhetoric utterly bereft of any supporting reasoning.
>
>

Nope, since "Decidability" isn't a property of a given input, trying to
ask if a given input is Decidable is a simple category error.

Your inability to understand that just highlights how ignorant you are
of the whole field.

[olcott]

H divides inputs into halting decidable and halting undecidable.

>>
>> H is deciding the semantic property of its own behavior on a set of
>> finite strings. The above says this can be done in C.
>
> Nope, just shows you don't understand a thing about what you are saying.

Any idiot can say that. Provide both reasoning and sources.

>>
>>> Your question is like asking if 2 is Purple.
>>
>> Mere empty rhetoric utterly bereft of any supporting reasoning.
>>
>>
>
> Nope, since "Decidability" isn't a property of a given input, trying to
> ask if a given input is Decidable is a simple category error.
>

Decidability is about the ability for there to exist a machine
that can decide if its input is a member of the set.

H decides an infinite set of elements that are halting decidable for H
and another set that are halting undecidable for H.

> Your inability to understand that just highlights how ignorant you are
> of the whole field.

I suspect that you might not have more than bluster and a penchant for
rebuttal.

[olcott]

You can make such claims with bluster finding a source that actually
supports them is a whole different matter.

It is the case that when embedded_H is a simulating termination analyzer
applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
normally and must have its simulation aborted.

It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
have its simulation terminated.

>>
>>> Now, since you are claiming that the embedded_H and Linz_H are
>>> IDENTICAL machines, but the also produce DIFFERENT results when given
>>> identical inputs, you have just proven that you are a LIAR.
>>
>> *So you are back to rejecting verified facts out-of-hand*
>> It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
>> 1 and the only difference is that H1 does not have a pathological
>> relationship to H and it is otherwise identical to H.
>>
>
> Since youy refuse to provide the verification fact about where the paths
> of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
>

The source code and execution trace have been available for a year.
I have explained this many times the problem seems to be that you simply
don't believe the facts. You say that a simulation is incorrect yet
cannot point to the instruction that was simulated incorrectly only
because the simulation is actually correct.

> You are just proving that you are just a LIAR and an IDIOT.
>
> What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
> DEFINITION WRONG and you claim tha tit is right is a verified LIE.
>

It depends on how you frame the problem.
If you frame the problem in that a halt decider must divide up finite
strings pairs into those that halt when directly executed and those that
do not, then no single program can do this. A pair of programs might do
this.

If you frame the problem in that a halt decider must divide up finite
stings into those that must have their simulation aborted to prevent
their infinite execution, then from H's point of view D does not halt.

[Richard Damon]

Which means?

After all, *ALL* inputs have a definite halting state, so there is a
correct answer to them, so there always exists a decider that will get
the right answer.

It seems by your attempt at a definition, a "Decider" that just decides
all machines are non-ha;ting would have all halting machines defined as

undecidable.

>
>>>
>>> H is deciding the semantic property of its own behavior on a set of
>>> finite strings. The above says this can be done in C.
>>
>> Nope, just shows you don't understand a thing about what you are saying.
>
> Any idiot can say that. Provide both reasoning and sources.



>
>>>
>>>> Your question is like asking if 2 is Purple.
>>>
>>> Mere empty rhetoric utterly bereft of any supporting reasoning.
>>>
>>>
>>
>> Nope, since "Decidability" isn't a property of a given input, trying
>> to ask if a given input is Decidable is a simple category error.
>>
>
>    Decidability is about the ability for there to exist a machine
>    that can decide if its input is a member of the set.
>
> H decides an infinite set of elements that are halting decidable for H
> and another set that are halting undecidable for H.

Again, "Halting Decidable" is an improper term, as ALL machines are
"Decidable" to halt by some machine. So there does exist a machine that
will give the right answer. It is sometimes a different machine for
different inputs.

Read that definition again, and perhaps find a better source, as
decidability is the ability for there to exist a machine that can
decider FOR ANY INPUT, if that input is a member of the set.

There ALWAYS exist a machine that will correctly indicate if a SPECIFIC
input is a member of the set. Trivially, it can be one of two possible
machines, Machine 1 always answers YES, Machine 2 always answers no. One
of those machines is right. The key point is that you need to determine
the answer for ALL inputs, thus it isn't a property of one of the
inputs, but of the SET.

As it is a property of the SET and not an input, there can't be
'decider' to determine if an 'input' has that property, since inputs
don't have that property, the set they are being tested for does.

>
>> Your inability to understand that just highlights how ignorant you are
>> of the whole field.
>
> I suspect that you might not have more than bluster and a penchant for
> rebuttal.
>

Really, I guess that is just you projecting, because you describe
yourself to the tee.

[Richard Damon]

No, you are just showing that you believe Russell's Teapot actually
exists. YOU are the one making claims, so YOU are the one that needs to
make a actual proof of correctness, and show the error in the counter
claims.

It is a PROVEN fact that two computation machines with the exact same
algorithm and the exact same input will always produce the same result.

You are claiming differently, WITHOUT PROOF, so you are shown to be a LIAR.

Either H and H1 are claimed to be the same machine, or they are not. If
they are the same machine, they need to give the same answer, or they
are not, and thus H1 getting the right answer to the H^ built on H
doesn't matter.

> It is the case that when embedded_H is a simulating termination analyzer
> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
> normally and must have its simulation aborted.

So?

>
> It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
> have its simulation terminated.

Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
showing that you hav just been LYING for decades.

>
>>>
>>>> Now, since you are claiming that the embedded_H and Linz_H are
>>>> IDENTICAL machines, but the also produce DIFFERENT results when
>>>> given identical inputs, you have just proven that you are a LIAR.
>>>
>>> *So you are back to rejecting verified facts out-of-hand*
>>> It is a verified fact that H(D,D) returns 0 and H1(D,D) returns
>>> 1 and the only difference is that H1 does not have a pathological
>>> relationship to H and it is otherwise identical to H.
>>>
>>
>> Since youy refuse to provide the verification fact about where the
>> paths of H(D,D) and D(D) differ, you don't HAVE a "verified fact".
>>
>
> The source code and execution trace have been available for a year.
> I have explained this many times the problem seems to be that you simply
> don't believe the facts. You say that a simulation is incorrect yet
> cannot point to the instruction that was simulated incorrectly only
> because the simulation is actually correct.

No, YOU LIE. The "Call H" instruction has been simulated incorrectly (or
not simulated at all an false presumptions about what it does used).

>
>> You are just proving that you are just a LIAR and an IDIOT.
>>
>> What IS verified is that D(D) Halts, so H(D,D) returning 0 is BY
>> DEFINITION WRONG and you claim tha tit is right is a verified LIE.
>>
>
> It depends on how you frame the problem.
> If you frame the problem in that a halt decider must divide up finite
> strings pairs into those that halt when directly executed and those that
> do not, then no single program can do this. A pair of programs might do
> this.

So, you agree with the Halting Theorem, as that it is the precise
problem being asked about.

>
> If you frame the problem in that a halt decider must divide up finite
> stings into those that must have their simulation aborted to prevent
> their infinite execution, then from H's point of view D does not halt.

So, you are admitting to using a Strawman, and nothing you say applies
to the ACTUAL Halting Problem.

You have maybe shown that POOP might be decidable, it at least can't use
the simple pathological example to show it, but POOP isn't about Halting
but partial simulation, so who cares about it.

This shows your mental instability as we don't care about what H sees,
which is just something of its imagination, we care about the reality of
what D actually does. Just like we care about what is ACTUALLY true,
verses what you think must be true without actually trying to prove it
logically.

[olcott]

I never said anything like that.
(Here is what I already said)
H returns three values:

0=halting is undecidable by H
1=halting
2=not halting

The human user runs H(D,D) and H returns 0. This tells the human
user to run H1(D,D) to get the correct halt status decision for H.
Because D could not have reconfigured itself this must work correctly.

>>
>>>>
>>>> H is deciding the semantic property of its own behavior on a set of
>>>> finite strings. The above says this can be done in C.
>>>
>>> Nope, just shows you don't understand a thing about what you are saying.
>>
>> Any idiot can say that. Provide both reasoning and sources.
>
>
>
>>
>>>>
>>>>> Your question is like asking if 2 is Purple.
>>>>
>>>> Mere empty rhetoric utterly bereft of any supporting reasoning.
>>>>
>>>>
>>>
>>> Nope, since "Decidability" isn't a property of a given input, trying
>>> to ask if a given input is Decidable is a simple category error.
>>>
>>
>>     Decidability is about the ability for there to exist a machine
>>     that can decide if its input is a member of the set.
>>
>> H decides an infinite set of elements that are halting decidable for H
>> and another set that are halting undecidable for H.
>
> Again, "Halting Decidable" is an improper term,

It is a brand new concept that was never relevant before because
everyone incorrectly assumed that deciding halting decidability
was blocked by Rice.

H correctly divides its inputs into those having the pathological
relationship to H of the conventional halting problem proofs and
inputs that do not have this relationship.

> as ALL machines are
> "Decidable" to halt by some machine. So there does exist a machine that
> will give the right answer. It is sometimes a different machine for
> different inputs.
>
> Read that definition again, and perhaps find a better source, as
> decidability is the ability for there to exist a machine that can
> decider FOR ANY INPUT, if that input is a member of the set.
>

My current code can already do that for every member of the set.

> There ALWAYS exist a machine that will correctly indicate if a SPECIFIC
> input is a member of the set. Trivially, it can be one of two possible
> machines, Machine 1 always answers YES, Machine 2 always answers no. One
> of those machines is right. The key point is that you need to determine
> the answer for ALL inputs, thus it isn't a property of one of the
> inputs, but of the SET.
>

My code also rejects inputs that are not members of this set.

> As it is a property of the SET and not an input, there can't be
> 'decider' to determine if an 'input' has that property, since inputs
> don't have that property, the set they are being tested for does.
>

I had very recent very long discussions with a PhD computer scientist
and he seemed to believe that the halting problem is about dividing
finite string pairs into those that halt on their input and those that
do not.

My case is analogous. H divides finite strings into those that have a
pathological relationship to H and those that do not on the basis of the
behavior that this finite string specifies.

>>
>>> Your inability to understand that just highlights how ignorant you
>>> are of the whole field.
>>
>> I suspect that you might not have more than bluster and a penchant for
>> rebuttal.
>>
>
> Really, I guess that is just you projecting, because you describe
> yourself to the tee.
>

[olcott]

If you believe that I am incorrect you need much more than your own
presumption as a basis for an actual rebuttal. You might not have
much more than this mere presumption.

> It is a PROVEN fact that two computation machines with the exact same
> algorithm and the exact same input will always produce the same result.
>
> You are claiming differently, WITHOUT PROOF, so you are shown to be a LIAR.
>

H1(D,D) and H(D,D) have different execution traces because D calls H and
D does not call H1. A not very bright software engineer could understand
this.

> Either H and H1 are claimed to be the same machine, or they are not. If
> they are the same machine, they need to give the same answer, or they
> are not, and thus H1 getting the right answer to the H^ built on H
> doesn't matter.
>
>
>> It is the case that when embedded_H is a simulating termination analyzer
>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
>> normally and must have its simulation aborted.
>
> So?
>
>>
>> It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
>> have its simulation terminated.
>
> Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
> showing that you hav just been LYING for decades.

It is a simple execution trace that even a bright high school student
can understand now that I have shown it at the C source code level.

It turns out that Linz_H(Linz_H_Hat, Linz_H_Hat) == 1
because Linz_H_Hat(Linz_H_Hat) == 0

This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩
transitions to Linz:Ĥ.qn

So I have overcome the issue of H(D,D) reporting non-halting and
the directly executed D(D) then halting in two different ways:

(1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and
Linz_H_Hat(Linz_H_Hat) halts.

(2) With the three value return of H(D,D) H only reports halting
when its directly executed input actually halts and seems to
defeat Rice by separately reporting all conventional halting
problem proof pathological inputs.

[Richard Damon]

Answering WHAT question?
The answers seem to be to two different questions.
Since the input IS either Halting or Not Halting, if H is supposed to be
a Halt Decider, your 0 below is NEVER a correct answer/

>
> 0=halting is undecidable by H
> 1=halting
> 2=not halting
>
> The human user runs H(D,D) and H returns 0. This tells the human
> user to run H1(D,D) to get the correct halt status decision for H.
> Because D could not have reconfigured itself this must work correctly.

But H can't know who is running it. That is part of the definition of a
Computation.

Also, by definition, the "Halt Decider" is the FULL PROCEDURE" used to
decide halting, thus H^/P/D does EXACTLY the same steps as "The User" to
get the answer.

That is call H(D,D), and if it returns 0, call H1(D,D) and then do the
opposite, if not, do the opposite of what H returned.

THAT is the definition of D, and if you can't code that, then your input
set isn't Turing Complete, so your decider fails there. If you can write
that, the final answer you got from above will be wrong.

The fact that you still seem to think that D is built just on H means
you don't understand the rules of the problem.

"H" in the proof, is the COMPLETE Halt Decider, not your function H
which no longer fills that role. Then H^/P/D is built to use that
decider, and does the opposite.

>
>>>
>>>>>
>>>>> H is deciding the semantic property of its own behavior on a set of
>>>>> finite strings. The above says this can be done in C.
>>>>
>>>> Nope, just shows you don't understand a thing about what you are
>>>> saying.
>>>
>>> Any idiot can say that. Provide both reasoning and sources.
>>
>>
>>
>>>
>>>>>
>>>>>> Your question is like asking if 2 is Purple.
>>>>>
>>>>> Mere empty rhetoric utterly bereft of any supporting reasoning.
>>>>>
>>>>>
>>>>
>>>> Nope, since "Decidability" isn't a property of a given input, trying
>>>> to ask if a given input is Decidable is a simple category error.
>>>>
>>>
>>>     Decidability is about the ability for there to exist a machine
>>>     that can decide if its input is a member of the set.
>>>
>>> H decides an infinite set of elements that are halting decidable for H
>>> and another set that are halting undecidable for H.
>>
>> Again, "Halting Decidable" is an improper term,
>
> It is a brand new concept that was never relevant before because
> everyone incorrectly assumed that deciding halting decidability
> was blocked by Rice.
>

And shows how deceptive you are acting, and how ignorant, as what you
are trying to call "Decidable" has no actual relation to the word as use.

> H correctly divides its inputs into those having the pathological
> relationship to H of the conventional halting problem proofs and
> inputs that do not have this relationship.

Except that it can only do that to the not-Turing-Complete subset that
it can accept (since you define that D can't have its own copy of H, and
that D can't actually make a proper copy of its input to something that
would be writable).

Then, it also has no bearing on the actual problem, since it doesn't use
the correct definition of Halting, so just is making a claim that POOP
deciders might be possible, but says nothing about actual Halt Deciders.

>
>> as ALL machines are "Decidable" to halt by some machine. So there does
>> exist a machine that will give the right answer. It is sometimes a
>> different machine for different inputs.
>>
>> Read that definition again, and perhaps find a better source, as
>> decidability is the ability for there to exist a machine that can
>> decider FOR ANY INPUT, if that input is a member of the set.
>>
>
> My current code can already do that for every member of the set.

But the set it is deciding on isn't Turing Complete, and doesn't
actually align to the actual definition of "Decidable".

>
>> There ALWAYS exist a machine that will correctly indicate if a
>> SPECIFIC input is a member of the set. Trivially, it can be one of two
>> possible machines, Machine 1 always answers YES, Machine 2 always
>> answers no. One of those machines is right. The key point is that you
>> need to determine the answer for ALL inputs, thus it isn't a property
>> of one of the inputs, but of the SET.
>>
>
> My code also rejects inputs that are not members of this set.

But the set it is deciding on isn't Turing Complete, and doesn't
actually align to the actual definition of "Decidable".

>
>> As it is a property of the SET and not an input, there can't be
>> 'decider' to determine if an 'input' has that property, since inputs
>> don't have that property, the set they are being tested for does.
>>
>
> I had very recent very long discussions with a PhD computer scientist
> and he seemed to believe that the halting problem is about dividing
> finite string pairs into those that halt on their input and those that
> do not.

It is about those strings that represent machines that Halt and those
that don't. It can also be expressed a whose CORRECT simulation Halts or
not. Note, "Correct Simulation" in this context implies a simulation
that matches the FULL .behavior of the machine described, and thus not
one that is aborted

>
> My case is analogous. H divides finite strings into those that have a
> pathological relationship to H and those that do not on the basis of the
> behavior that this finite string specifies.
>

But the set it is deciding on isn't Turing Complete, and doesn't
actually align to the actual definition of "Decidable".

[Richard Damon]

I have given MANY details that you have not even tried to refute.

YOU are the one with the burden of Proof.

The Ultimate proof you are wrong is that H, which you claim to be a
correct Halt decider, will return 0 when called as H(D,D), but D(D)
Halts, as you admit, which is contrary to the requirements of a Halt
Decider.

Thus, you claim is just a LIE.

>
>> It is a PROVEN fact that two computation machines with the exact same
>> algorithm and the exact same input will always produce the same result.
>>
>> You are claiming differently, WITHOUT PROOF, so you are shown to be a
>> LIAR.
>>
>
> H1(D,D) and H(D,D) have different execution traces because D calls H and
> D does not call H1. A not very bright software engineer could understand
> this.

Then they aren't the same algorithm, and can't be considered the same
machine.

PERIOD.

You are caught in your lie.

When you try to show where the traces differ, it shows that the machines
are NOT exact copies of the same algorthm that uses only its defined
inputs to control itself.

Therefore, H1 is a DIFFERENT machine the H, so it giving the correct
answer is irrelevent, and you claims are shown to be a LIE.

>
>> Either H and H1 are claimed to be the same machine, or they are not.
>> If they are the same machine, they need to give the same answer, or
>> they are not, and thus H1 getting the right answer to the H^ built on
>> H doesn't matter.
>>
>>
>>> It is the case that when embedded_H is a simulating termination analyzer
>>> applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that the simulated input cannot possibly terminate
>>> normally and must have its simulation aborted.
>>
>> So?
>>
>>>
>>> It is not the case the Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ that its input must
>>> have its simulation terminated.
>>
>> Thus Linz:H and embedded_H aren't the same machine, as REQUIRED, thus
>> showing that you hav just been LYING for decades.
>
> It is a simple execution trace that even a bright high school student
> can understand now that I have shown it at the C source code level.

Which shows that your claims are a lie, as shown above.

?? Linz_H isn't defined to "call" Linz_H_Hat, in fact it CAN'T because
Linz_H_Hat doesn't exist when Linz_H is defined. it might "Simulate" or
"Debug Step" the description it gets. Also Linz_H_Hat doesn't actually
returh anything of meaning, as has been previously told to you.

Also, if Linz_H(Linz_H_Hat, Linz_H_Hat) returns 1, then so must the
embedded_H(Linz_H_Hat, Linz_H_Hat) that Linz_H_Hat uses, or it is proven
that you claim that you built Linz_H_Hat per the requirements is a LIE.

Linz_H_Hat is DEFINED to use a computationally equivalent copy of Linz_H
within it, and as such that copy must return the same value for the same
inputs. That you embedded_H doesn't just proves you failed to perform
this step correctly.

And you traces just confirm this fact, there will either be a differing
effect instruction/data in embedded_H or it uses a value not part of its
input (like its PC address), thus invalidating your claims.

Remember, you are claiming Turing Equivalence to the Turing Machine
description, so you need to be an ACTUAL equivalent, and

>
> This translates into Linz:H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
> transitions to Linz:H.qy because Linz:Ĥ applied to ⟨Ĥ⟩
> transitions to Linz:Ĥ.qn

But Linz:Ĥ uses its copy of embedded_H (Ĥ) (Ĥ) which will behave
IDENTIALLY to Linz:H (Ĥ) (Ĥ) which by your claim above goes to Qy, so
Linz:Ĥ will go to Qy and then on to the infinite loop, so Linz:H going
to Qy is incorrect.

>
> So I have overcome the issue of H(D,D) reporting non-halting and
> the directly executed D(D) then halting in two different ways:
>
> (1) Linz_H(Linz_H_Hat, Linz_H_Hat) reports halting and
> Linz_H_Hat(Linz_H_Hat) halts.

But only because you didn't build Ĥ correctly, and thus you are caught
in your LIE.

>
> (2) With the three value return of H(D,D) H only reports halting
> when its directly executed input actually halts and seems to
> defeat Rice by separately reporting all conventional halting
> problem proof pathological inputs.
>
>

Nope. You have just shown that you whole proof is built on LIES and your
own ignorance.

The claims you make just prove you don't understand the words you are
sayimg.