On 7/3/2023 2:58 PM, Richard Damon wrote:
> 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.
>
> 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?
>

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

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

--
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 4:03 PM, olcott wrote:
> 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.
>

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

On 7/3/23 4:08 PM, olcott wrote:
> 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.
>

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

On 7/3/23 4:45 PM, olcott wrote:
> 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".
>
>
> 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
>

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

On 7/3/23 4:22 PM, olcott wrote:
> On 7/3/2023 2:58 PM, Richard Damon wrote:
>> 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.
>>
>> 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?
>>
>
> 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.

On 7/3/2023 4:07 PM, Richard Damon wrote:
> On 7/3/23 4:45 PM, olcott wrote:
>> 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".
>>
>>
>> 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
>>
>
> 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).

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

--
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 4:07 PM, Richard Damon wrote:
> On 7/3/23 4:08 PM, olcott wrote:
>> 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.
>>
>
> What do you mean by "Undecidable by H?"
>

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

--
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 5:19 PM, olcott wrote:
> On 7/3/2023 4:07 PM, Richard Damon wrote:
>> On 7/3/23 4:45 PM, olcott wrote:
>>> 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".
>>>
>>>
>>> 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
>>>
>>
>> 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).
>
> H is a correct halting decidability decider for itself.
> Rice says that is impossible, thus Rice is wrong.
>

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.

On 7/3/23 5:30 PM, olcott wrote:
> On 7/3/2023 4:07 PM, Richard Damon wrote:
>> On 7/3/23 4:08 PM, olcott wrote:
>>> 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.
>>>
>>
>> What do you mean by "Undecidable by H?"
>>
>
> H correctly determines that it cannot provide a halt status
> consistent with the behavior of the directly executed D(D).

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.

On 7/3/2023 4:17 PM, Richard Damon wrote:
> On 7/3/23 4:22 PM, olcott wrote:
>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>> 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.
>>>
>>> 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?
>>>
>>
>> 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.
>
> 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,
*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.

On 7/3/2023 4:31 PM, Richard Damon wrote:
> On 7/3/23 5:19 PM, olcott wrote:
>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>> On 7/3/23 4:45 PM, olcott wrote:
>>>> 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".
>>>>
>>>>
>>>> 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
>>>>
>>>
>>> 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).
>>
>> H is a correct halting decidability decider for itself.
>> Rice says that is impossible, thus Rice is wrong.
>>
>
> 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.
>
H correctly divides finite string pairs {H,*} into decidable by H and
undecidable by H, a semantic property of these finite string pairs.

--
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 4:34 PM, Richard Damon wrote:
> On 7/3/23 5:30 PM, olcott wrote:
>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>> On 7/3/23 4:08 PM, olcott wrote:
>>>> 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.
>>>>
>>>
>>> What do you mean by "Undecidable by H?"
>>>
>>
>> H correctly determines that it cannot provide a halt status
>> consistent with the behavior of the directly executed D(D).
>
> 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.

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?

--
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 5:34 PM, olcott wrote:
> On 7/3/2023 4:17 PM, Richard Damon wrote:
>> On 7/3/23 4:22 PM, olcott wrote:
>>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>
>>> 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.
>>
>> 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,
> *I never said that you are confused*

On 7/3/23 5:40 PM, olcott wrote:
> On 7/3/2023 4:34 PM, Richard Damon wrote:
>> On 7/3/23 5:30 PM, olcott wrote:
>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>> On 7/3/23 4:08 PM, olcott wrote:
>>>>> 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.
>>>>>
>>>>
>>>> What do you mean by "Undecidable by H?"
>>>>
>>>
>>> H correctly determines that it cannot provide a halt status
>>> consistent with the behavior of the directly executed D(D).
>>
>> 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.
>
> 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?
>
>

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.

On 7/3/23 5:36 PM, olcott wrote:
> On 7/3/2023 4:31 PM, Richard Damon wrote:
>> On 7/3/23 5:19 PM, olcott wrote:
>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>> On 7/3/23 4:45 PM, olcott wrote:
>>>>> 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".
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>
>>>> 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).
>>>
>>> H is a correct halting decidability decider for itself.
>>> Rice says that is impossible, thus Rice is wrong.
>>>
>>
>> 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.
>>
> H correctly divides finite string pairs {H,*} into decidable by H and
> undecidable by H, a semantic property of these finite string pairs.
>

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.

On 7/3/2023 4:55 PM, Richard Damon wrote:
> On 7/3/23 5:40 PM, olcott wrote:
>> On 7/3/2023 4:34 PM, Richard Damon wrote:
>>> On 7/3/23 5:30 PM, olcott wrote:
>>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>>> On 7/3/23 4:08 PM, olcott wrote:
>>>>>> 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.
>>>>>>
>>>>>
>>>>> What do you mean by "Undecidable by H?"
>>>>>
>>>>
>>>> H correctly determines that it cannot provide a halt status
>>>> consistent with the behavior of the directly executed D(D).
>>>
>>> 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.
>>
>> 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?
>>
>>
>
> 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.
>

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

--
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 4:55 PM, Richard Damon wrote:
> On 7/3/23 5:34 PM, olcott wrote:
>> On 7/3/2023 4:17 PM, Richard Damon wrote:
>>> On 7/3/23 4:22 PM, olcott wrote:
>>>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>>>> 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.
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> 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.
>>>
>>> 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,
>> *I never said that you are confused*
>
> 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,

On 7/3/2023 4:55 PM, Richard Damon wrote:
> On 7/3/23 5:36 PM, olcott wrote:
>> On 7/3/2023 4:31 PM, Richard Damon wrote:
>>> On 7/3/23 5:19 PM, olcott wrote:
>>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>>> On 7/3/23 4:45 PM, olcott wrote:
>>>>>> 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".
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>> 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).
>>>>
>>>> H is a correct halting decidability decider for itself.
>>>> Rice says that is impossible, thus Rice is wrong.
>>>>
>>>
>>> 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.
>>>
>> H correctly divides finite string pairs {H,*} into decidable by H and
>> undecidable by H, a semantic property of these finite string pairs.
>>
>
> No such property. Inputs are not "Decidable", problems are.

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.

On 7/3/23 10:20 PM, olcott wrote:
> On 7/3/2023 4:55 PM, Richard Damon wrote:
>> On 7/3/23 5:34 PM, olcott wrote:
>>> On 7/3/2023 4:17 PM, Richard Damon wrote:
>>>> On 7/3/23 4:22 PM, olcott wrote:
>>>>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>>>>> 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.
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> 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,
>>> *I never said that you are confused*
>>
>> 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,
>
> 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.

On 7/3/23 10:28 PM, olcott wrote:
> On 7/3/2023 4:55 PM, Richard Damon wrote:
>> On 7/3/23 5:36 PM, olcott wrote:
>>> On 7/3/2023 4:31 PM, Richard Damon wrote:
>>>> On 7/3/23 5:19 PM, olcott wrote:
>>>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>>>> On 7/3/23 4:45 PM, olcott wrote:
>>>>>>> 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".
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> 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).
>>>>>
>>>>> H is a correct halting decidability decider for itself.
>>>>> Rice says that is impossible, thus Rice is wrong.
>>>>>
>>>>
>>>> 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.
>>>>
>>> H correctly divides finite string pairs {H,*} into decidable by H and
>>> undecidable by H, a semantic property of these finite string pairs.
>>>
>>
>> No such property. Inputs are not "Decidable", problems are.
>
> I didn't say that quite right. H is a halting decidability decider.
> That really seems to be a semantic property of finite strings.

On 7/3/23 9:51 PM, olcott wrote:
> On 7/3/2023 4:55 PM, Richard Damon wrote:
>> On 7/3/23 5:40 PM, olcott wrote:
>>> On 7/3/2023 4:34 PM, Richard Damon wrote:
>>>> On 7/3/23 5:30 PM, olcott wrote:
>>>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>>>> On 7/3/23 4:08 PM, olcott wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> What do you mean by "Undecidable by H?"
>>>>>>
>>>>>
>>>>> H correctly determines that it cannot provide a halt status
>>>>> consistent with the behavior of the directly executed D(D).
>>>>
>>>> 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.
>>>
>>> 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?
>>>
>>>
>>
>> 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.
>>
>
>
> *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.
>
>

On 7/3/2023 10:22 PM, Richard Damon wrote:
> On 7/3/23 9:51 PM, olcott wrote:
>> On 7/3/2023 4:55 PM, Richard Damon wrote:
>>> On 7/3/23 5:40 PM, olcott wrote:
>>>> On 7/3/2023 4:34 PM, Richard Damon wrote:
>>>>> On 7/3/23 5:30 PM, olcott wrote:
>>>>>> On 7/3/2023 4:07 PM, Richard Damon wrote:
>>>>>>> On 7/3/23 4:08 PM, olcott wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> What do you mean by "Undecidable by H?"
>>>>>>>
>>>>>>
>>>>>> H correctly determines that it cannot provide a halt status
>>>>>> consistent with the behavior of the directly executed D(D).
>>>>>
>>>>> 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.
>>>>
>>>> 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?
>>>>
>>>>
>>>
>>> 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.
>>>
>>
>>
>> *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.
>>
>>
>
> 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.
>

On 7/3/2023 10:22 PM, Richard Damon wrote:
> On 7/3/23 10:20 PM, olcott wrote:
>> On 7/3/2023 4:55 PM, Richard Damon wrote:
>>> On 7/3/23 5:34 PM, olcott wrote:
>>>> On 7/3/2023 4:17 PM, Richard Damon wrote:
>>>>> On 7/3/23 4:22 PM, olcott wrote:
>>>>>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>>>>>> 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.
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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,
>>>> *I never said that you are confused*
>>>
>>> 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,
>>
>> 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.
>
> 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.
>

On 7/3/23 11:56 PM, olcott wrote:
> On 7/3/2023 10:22 PM, Richard Damon wrote:
>> On 7/3/23 10:20 PM, olcott wrote:
>>> On 7/3/2023 4:55 PM, Richard Damon wrote:
>>>> On 7/3/23 5:34 PM, olcott wrote:
>>>>> On 7/3/2023 4:17 PM, Richard Damon wrote:
>>>>>> On 7/3/23 4:22 PM, olcott wrote:
>>>>>>> On 7/3/2023 2:58 PM, Richard Damon wrote:
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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?
>>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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,
>>>>> *I never said that you are confused*
>>>>
>>>> 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,
>>>
>>> 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.
>>
>> 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.
>>
>
> 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.