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.

>
>> 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.
>

On 7/3/23 11: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.
>
> 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.

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.

On 7/3/23 11:41 AM, olcott wrote:
> On 7/3/2023 10:35 AM, Richard Damon wrote:
>> On 7/3/23 11:10 AM, olcott wrote:
>>> 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.
>>>
>>>
>>
>> So, you don't understand the problem.
>>
>> D doesn't even exist as an input until you define the H
>
> So you want a TM to decide halting for an imaginary input?
> That is not the way that computation actually works.

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.

On 7/3/23 11:56 AM, olcott wrote:
> On 7/3/2023 10:35 AM, Richard Damon wrote:
>> On 7/3/23 10:45 AM, olcott wrote:
>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>> It never sees New_H.
>>>>>>>
>>>>>>
>>>>>> Why not? Since New_H is the thing that is considered the "Correct
>>>>>> Halt Decider", New_D needs to be built on it.
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> So, how is New_H a halt decider then?
>>>
>>> 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
>>>
>>>
>>
>> But New_D needs to call New_H,
>
> 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.
>
>

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.

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.
>>
>

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

On 7/3/2023 10:58 AM, Richard Damon wrote:
> On 7/3/23 11:41 AM, olcott wrote:
>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>> On 7/3/23 11:10 AM, olcott wrote:
>>>> 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.
>>>>
>>>>
>>>
>>> So, you don't understand the problem.
>>>
>>> D doesn't even exist as an input until you define the H
>>
>> So you want a TM to decide halting for an imaginary input?
>> That is not the way that computation actually works.
>
> 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,

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

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

On 7/3/2023 11:01 AM, Richard Damon wrote:
> On 7/3/23 11:56 AM, olcott wrote:
>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>> On 7/3/23 10:45 AM, olcott wrote:
>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>>> It never sees New_H.
>>>>>>>>
>>>>>>>
>>>>>>> Why not? Since New_H is the thing that is considered the "Correct
>>>>>>> Halt Decider", New_D needs to be built on it.
>>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> So, how is New_H a halt decider then?
>>>>
>>>> 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
>>>>
>>>>
>>>
>>> But New_D needs to call New_H,
>>
>> 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.
>>
>>
>
> 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.

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

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

On 7/3/23 12:11 PM, olcott wrote:
> On 7/3/2023 11:01 AM, Richard Damon wrote:
>> On 7/3/23 11:56 AM, olcott wrote:
>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>> On 7/3/23 10:45 AM, olcott wrote:
>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>>>> It never sees New_H.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why not? Since New_H is the thing that is considered the
>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.
>>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> So, how is New_H a halt decider then?
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>> But New_D needs to call New_H,
>>>
>>> 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.
>>>
>>>
>>
>> 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.
>
> You are using double-talk in a lame attempt to show that
> Linz H cannot correctly determine the halt status of Linz Ĥ.
>

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.

On 7/3/23 12:09 PM, olcott wrote:
> On 7/3/2023 10:58 AM, Richard Damon wrote:
>> On 7/3/23 11:41 AM, olcott wrote:
>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>> On 7/3/23 11:10 AM, olcott wrote:
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>> So, you don't understand the problem.
>>>>
>>>> D doesn't even exist as an input until you define the H
>>>
>>> So you want a TM to decide halting for an imaginary input?
>>> That is not the way that computation actually works.
>>
>> 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,
>
> None-the-less you continue to assert that it must take ideas as inputs.
> It just doesn't work that way.
>

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".

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.

>
>>>
>>>> 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.
>>>
>>
>

On 7/3/2023 11:26 AM, Richard Damon wrote:
> On 7/3/23 12:11 PM, olcott wrote:
>> On 7/3/2023 11:01 AM, Richard Damon wrote:
>>> On 7/3/23 11:56 AM, olcott wrote:
>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>> On 7/3/23 10:45 AM, olcott wrote:
>>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>>>>> It never sees New_H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why not? Since New_H is the thing that is considered the
>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> So, how is New_H a halt decider then?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> But New_D needs to call New_H,
>>>>
>>>> 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.
>>>>
>>>>
>>>
>>> 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.
>>
>> You are using double-talk in a lame attempt to show that
>> Linz H cannot correctly determine the halt status of Linz Ĥ.
>>
>
> 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.

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.

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

On 7/3/2023 11:26 AM, Richard Damon wrote:
> On 7/3/23 12:09 PM, olcott wrote:
>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>> On 7/3/23 11:41 AM, olcott wrote:
>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>> On 7/3/23 11:10 AM, olcott wrote:
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>> So, you don't understand the problem.
>>>>>
>>>>> D doesn't even exist as an input until you define the H
>>>>
>>>> So you want a TM to decide halting for an imaginary input?
>>>> That is not the way that computation actually works.
>>>
>>> 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,
>>
>> None-the-less you continue to assert that it must take ideas as inputs.
>> It just doesn't work that way.
>>
>
> Nope, Where did I say THAT.

On 7/3/2023 10:58 AM, Richard Damon wrote:
> Nope, it must decide for ALL inputs, even those that haven't been
> 'created' yet.

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

On 7/3/2023 11:26 AM, Richard Damon wrote:
> 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.

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}.

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

On 7/3/23 1:57 PM, olcott wrote:
> On 7/3/2023 11:26 AM, Richard Damon wrote:
>> On 7/3/23 12:11 PM, olcott wrote:
>>> On 7/3/2023 11:01 AM, Richard Damon wrote:
>>>> On 7/3/23 11:56 AM, olcott wrote:
>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>> On 7/3/23 10:45 AM, olcott wrote:
>>>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>>>>>> It never sees New_H.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why not? Since New_H is the thing that is considered the
>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> So, how is New_H a halt decider then?
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> But New_D needs to call New_H,
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>> 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.
>>>
>>> You are using double-talk in a lame attempt to show that
>>> Linz H cannot correctly determine the halt status of Linz Ĥ.
>>>
>>
>> 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.
>
> 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.
>

On 7/3/23 2:00 PM, olcott wrote:
> On 7/3/2023 11:26 AM, Richard Damon wrote:
>> On 7/3/23 12:09 PM, olcott wrote:
>>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>>> On 7/3/23 11:41 AM, olcott wrote:
>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>> On 7/3/23 11:10 AM, olcott wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, you don't understand the problem.
>>>>>>
>>>>>> D doesn't even exist as an input until you define the H
>>>>>
>>>>> So you want a TM to decide halting for an imaginary input?
>>>>> That is not the way that computation actually works.
>>>>
>>>> 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,
>>>
>>> None-the-less you continue to assert that it must take ideas as inputs.
>>> It just doesn't work that way.
>>>
>>
>> Nope, Where did I say THAT.
>
> On 7/3/2023 10:58 AM, Richard Damon wrote:
> > Nope, it must decide for ALL inputs, even those that haven't been
> > 'created' yet.
>

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.

On 7/3/23 2:03 PM, olcott wrote:
> On 7/3/2023 11:26 AM, Richard Damon wrote:
>> 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.
>
> 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}.
>

On 7/3/23 2:03 PM, olcott wrote:
> On 7/3/2023 11:26 AM, Richard Damon wrote:
>> 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.
>
> 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}.
>

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.

On 7/3/2023 1:25 PM, Richard Damon wrote:
> On 7/3/23 1:57 PM, olcott wrote:
>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>> On 7/3/23 12:11 PM, olcott wrote:
>>>> On 7/3/2023 11:01 AM, Richard Damon wrote:
>>>>> On 7/3/23 11:56 AM, olcott wrote:
>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
>>>>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>>>>>>> It never sees New_H.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why not? Since New_H is the thing that is considered the
>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> So, how is New_H a halt decider then?
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> But New_D needs to call New_H,
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> You are using double-talk in a lame attempt to show that
>>>> Linz H cannot correctly determine the halt status of Linz Ĥ.
>>>>
>>>
>>> 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.
>>
>> 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.
>>
>
> So, you are admitting that you actually can't do what is required?
>
> Copying the input should be trivial,

On 7/3/2023 1:25 PM, Richard Damon wrote:
> On 7/3/23 2:00 PM, olcott wrote:
>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>> On 7/3/23 12:09 PM, olcott wrote:
>>>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>>>> On 7/3/23 11:41 AM, olcott wrote:
>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>>> On 7/3/23 11:10 AM, olcott wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So, you don't understand the problem.
>>>>>>>
>>>>>>> D doesn't even exist as an input until you define the H
>>>>>>
>>>>>> So you want a TM to decide halting for an imaginary input?
>>>>>> That is not the way that computation actually works.
>>>>>
>>>>> 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,
>>>>
>>>> None-the-less you continue to assert that it must take ideas as inputs.
>>>> It just doesn't work that way.
>>>>
>>>
>>> Nope, Where did I say THAT.
>>
>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>  > Nope, it must decide for ALL inputs, even those that haven't been
>>  > 'created' yet.
>>
>
> Right, haven't been created at the time the decider is created, but will
> have been when it is run.
>

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

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

On 7/3/2023 1:25 PM, Richard Damon wrote:
> On 7/3/23 2:03 PM, olcott wrote:
>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>> 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.
>>
>> 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}.
>>
>
> 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.
>

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.

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

On 7/3/23 2:49 PM, olcott wrote:
> On 7/3/2023 1:25 PM, Richard Damon wrote:
>> On 7/3/23 2:00 PM, olcott wrote:
>>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>>> On 7/3/23 12:09 PM, olcott wrote:
>>>>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>>>>> On 7/3/23 11:41 AM, olcott wrote:
>>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>>>> On 7/3/23 11:10 AM, olcott wrote:
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, you don't understand the problem.
>>>>>>>>
>>>>>>>> D doesn't even exist as an input until you define the H
>>>>>>>
>>>>>>> So you want a TM to decide halting for an imaginary input?
>>>>>>> That is not the way that computation actually works.
>>>>>>
>>>>>> 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,
>>>>>
>>>>> None-the-less you continue to assert that it must take ideas as
>>>>> inputs.
>>>>> It just doesn't work that way.
>>>>>
>>>>
>>>> Nope, Where did I say THAT.
>>>
>>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>>  > Nope, it must decide for ALL inputs, even those that haven't been
>>>  > 'created' yet.
>>>
>>
>> Right, haven't been created at the time the decider is created, but
>> will have been when it is run.
>>
>
> Not unless the guy that wrote the decider also wrote its input.
> Until then the input you refer to is only imaginary.
>

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.

On 7/3/23 2:56 PM, olcott wrote:
> On 7/3/2023 1:25 PM, Richard Damon wrote:
>> On 7/3/23 2:03 PM, olcott wrote:
>>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>>> 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.
>>>
>>> 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}.
>>>
>>
>> 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.
>>
>
> 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.
>
>

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".

On 7/3/23 2:48 PM, olcott wrote:
> On 7/3/2023 1:25 PM, Richard Damon wrote:
>> On 7/3/23 1:57 PM, olcott wrote:
>>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>>> On 7/3/23 12:11 PM, olcott wrote:
>>>>> On 7/3/2023 11:01 AM, Richard Damon wrote:
>>>>>> On 7/3/23 11:56 AM, olcott wrote:
>>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>>>> On 7/3/23 10:45 AM, olcott wrote:
>>>>>>>>> On 7/3/2023 9:24 AM, Richard Damon wrote:
>>>>>>>>>> On 7/3/23 9:47 AM, olcott wrote:
>>>>>>>>>>> On 7/3/2023 8:14 AM, Richard Damon wrote:
>>>>>>>>>>>> On 7/2/23 10:48 PM, olcott wrote:
>>>>>>>>>>>>> On 7/2/2023 9:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 7/2/23 10:01 PM, olcott wrote:
>>>>>>>>>>>>>>> On 7/2/2023 8:40 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> New_D copies its input and simulates its input with its input.
>>>>>>>>>>>>> It never sees New_H.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Why not? Since New_H is the thing that is considered the
>>>>>>>>>>>> "Correct Halt Decider", New_D needs to be built on it.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> So, how is New_H a halt decider then?
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> But New_D needs to call New_H,
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> You are using double-talk in a lame attempt to show that
>>>>> Linz H cannot correctly determine the halt status of Linz Ĥ.
>>>>>
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>>
>> So, you are admitting that you actually can't do what is required?
>>
>> Copying the input should be trivial,
>
> The relative addressing of the x86 language causes all function
> calls to call the wrong address.

On 7/3/2023 2:58 PM, Richard Damon wrote:
> On 7/3/23 2:49 PM, olcott wrote:
>> On 7/3/2023 1:25 PM, Richard Damon wrote:
>>> On 7/3/23 2:00 PM, olcott wrote:
>>>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>>>> On 7/3/23 12:09 PM, olcott wrote:
>>>>>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>>>>>> On 7/3/23 11:41 AM, olcott wrote:
>>>>>>>> On 7/3/2023 10:35 AM, Richard Damon wrote:
>>>>>>>>> On 7/3/23 11:10 AM, olcott wrote:
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, you don't understand the problem.
>>>>>>>>>
>>>>>>>>> D doesn't even exist as an input until you define the H
>>>>>>>>
>>>>>>>> So you want a TM to decide halting for an imaginary input?
>>>>>>>> That is not the way that computation actually works.
>>>>>>>
>>>>>>> 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,
>>>>>>
>>>>>> None-the-less you continue to assert that it must take ideas as
>>>>>> inputs.
>>>>>> It just doesn't work that way.
>>>>>>
>>>>>
>>>>> Nope, Where did I say THAT.
>>>>
>>>> On 7/3/2023 10:58 AM, Richard Damon wrote:
>>>>  > Nope, it must decide for ALL inputs, even those that haven't been
>>>>  > 'created' yet.
>>>>
>>>
>>> Right, haven't been created at the time the decider is created, but
>>> will have been when it is run.
>>>
>>
>> Not unless the guy that wrote the decider also wrote its input.
>> Until then the input you refer to is only imaginary.
>>
>
> Why do you say that? As I said, it actually exist when we run the
> decider on it.
>

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

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

On 7/3/2023 2:58 PM, Richard Damon wrote:
> On 7/3/23 2:56 PM, olcott wrote:
>> On 7/3/2023 1:25 PM, Richard Damon wrote:
>>> On 7/3/23 2:03 PM, olcott wrote:
>>>> On 7/3/2023 11:26 AM, Richard Damon wrote:
>>>>> 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.
>>>>
>>>> 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}.
>>>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>
> 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".

{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.

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