On 7/3/23 11:47 PM, olcott wrote:
> 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.
>>
>
> Since I just quoted that to you it is reasonable that you accept it.

On 7/3/2023 11:06 PM, Richard Damon wrote:
> On 7/3/23 11:47 PM, olcott wrote:
>> 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.
>>>
>>
>> Since I just quoted that to you it is reasonable that you accept it.
>
> Nope, Decidability is a property of PROBLEMS or SETS, not INPUTS.
>
> You can't seem to tell the diffence bcause of your ignorance.
>
>>
>>> Nothing he talks about the possible members themselves being in the
>>> set or not being a property like "decidable", it just isn't a
>>> property of the members.
>>>
>>
>> Using Rogers' characterization of acceptable programming systems, Rice's
>> theorem may essentially be generalized from Turing machines to most
>> computer programming languages: there exists no automatic method that
>> decides with generality non-trivial questions on the behavior of
>> computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
>
> Yes, it doesn't need to be about Turning Machines, but it is still about
> the ability to create a "program" to compute a Function / Decider for a
> Language/Set.
>
>>
>> H correctly determines whether or not it can correctly determine the
>> halting status for all of the members of the set of conventional halting
>> problem proof counter-examples and an infinite set of other elements.
>
> But that isn't a proper property.
>
> You don't have "Decidability" on individual inputs, so it isn't a
> Property of the input that can be decided on.

On 7/3/2023 11:06 PM, Richard Damon wrote:
> 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.
>
> Nope, just shows you are not working in a Turing Equivalent system, and
> thus NOTHING you say matters.
>

On 7/4/23 12:35 AM, olcott wrote:
> On 7/3/2023 11:06 PM, Richard Damon wrote:
>> On 7/3/23 11:47 PM, olcott wrote:
>>> 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.
>>>>
>>>
>>> Since I just quoted that to you it is reasonable that you accept it.
>>
>> Nope, Decidability is a property of PROBLEMS or SETS, not INPUTS.
>>
>> You can't seem to tell the diffence bcause of your ignorance.
>>
>>>
>>>> Nothing he talks about the possible members themselves being in the
>>>> set or not being a property like "decidable", it just isn't a
>>>> property of the members.
>>>>
>>>
>>> Using Rogers' characterization of acceptable programming systems, Rice's
>>> theorem may essentially be generalized from Turing machines to most
>>> computer programming languages: there exists no automatic method that
>>> decides with generality non-trivial questions on the behavior of
>>> computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
>>
>> Yes, it doesn't need to be about Turning Machines, but it is still
>> about the ability to create a "program" to compute a Function /
>> Decider for a Language/Set.
>>
>>>
>>> H correctly determines whether or not it can correctly determine the
>>> halting status for all of the members of the set of conventional halting
>>> problem proof counter-examples and an infinite set of other elements.
>>
>> But that isn't a proper property.
>>
>> You don't have "Decidability" on individual inputs, so it isn't a
>> Property of the input that can be decided on.
>
> H divides inputs into halting decidable and halting undecidable.

On 7/4/23 12:57 AM, olcott wrote:
> On 7/3/2023 11:06 PM, Richard Damon wrote:
>> 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.
>>
>> Nope, just shows you are not working in a Turing Equivalent system,
>> and thus NOTHING you say matters.
>>
>
> You can make such claims with bluster finding a source that actually
> supports them is a whole different matter.

On 7/4/2023 8:27 AM, Richard Damon wrote:
> On 7/4/23 12:35 AM, olcott wrote:
>> On 7/3/2023 11:06 PM, Richard Damon wrote:
>>> On 7/3/23 11:47 PM, olcott wrote:
>>>> 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.
>>>>>
>>>>
>>>> Since I just quoted that to you it is reasonable that you accept it.
>>>
>>> Nope, Decidability is a property of PROBLEMS or SETS, not INPUTS.
>>>
>>> You can't seem to tell the diffence bcause of your ignorance.
>>>
>>>>
>>>>> Nothing he talks about the possible members themselves being in the
>>>>> set or not being a property like "decidable", it just isn't a
>>>>> property of the members.
>>>>>
>>>>
>>>> Using Rogers' characterization of acceptable programming systems,
>>>> Rice's
>>>> theorem may essentially be generalized from Turing machines to most
>>>> computer programming languages: there exists no automatic method that
>>>> decides with generality non-trivial questions on the behavior of
>>>> computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>
>>> Yes, it doesn't need to be about Turning Machines, but it is still
>>> about the ability to create a "program" to compute a Function /
>>> Decider for a Language/Set.
>>>
>>>>
>>>> H correctly determines whether or not it can correctly determine the
>>>> halting status for all of the members of the set of conventional
>>>> halting
>>>> problem proof counter-examples and an infinite set of other elements.
>>>
>>> But that isn't a proper property.
>>>
>>> You don't have "Decidability" on individual inputs, so it isn't a
>>> Property of the input that can be decided on.
>>
>> H divides inputs into halting decidable and halting undecidable.
>
> Which means?
>
> After all, *ALL* inputs have a definite halting state, so there is a
> correct answer to them, so there always exists a decider that will get
> the right answer.
>
> It seems by your attempt at a definition, a "Decider" that just decides
> all machines are non-ha;ting would have all halting machines defined as
> undecidable.

On 7/4/2023 8:27 AM, Richard Damon wrote:
> On 7/4/23 12:57 AM, olcott wrote:
>> On 7/3/2023 11:06 PM, Richard Damon wrote:
>>> 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.
>>>
>>> Nope, just shows you are not working in a Turing Equivalent system,
>>> and thus NOTHING you say matters.
>>>
>>
>> You can make such claims with bluster finding a source that actually
>> supports them is a whole different matter.
>
> No, you are just showing that you believe Russell's Teapot actually
> exists. YOU are the one making claims, so YOU are the one that needs to
> make a actual proof of correctness, and show the error in the counter
> claims.
>

On 7/4/23 5:32 PM, olcott wrote:
> On 7/4/2023 8:27 AM, Richard Damon wrote:
>> On 7/4/23 12:35 AM, olcott wrote:
>>> On 7/3/2023 11:06 PM, Richard Damon wrote:
>>>> On 7/3/23 11:47 PM, olcott wrote:
>>>>> 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.
>>>>>>
>>>>>
>>>>> Since I just quoted that to you it is reasonable that you accept it.
>>>>
>>>> Nope, Decidability is a property of PROBLEMS or SETS, not INPUTS.
>>>>
>>>> You can't seem to tell the diffence bcause of your ignorance.
>>>>
>>>>>
>>>>>> Nothing he talks about the possible members themselves being in
>>>>>> the set or not being a property like "decidable", it just isn't a
>>>>>> property of the members.
>>>>>>
>>>>>
>>>>> Using Rogers' characterization of acceptable programming systems,
>>>>> Rice's
>>>>> theorem may essentially be generalized from Turing machines to most
>>>>> computer programming languages: there exists no automatic method that
>>>>> decides with generality non-trivial questions on the behavior of
>>>>> computer programs. https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>
>>>> Yes, it doesn't need to be about Turning Machines, but it is still
>>>> about the ability to create a "program" to compute a Function /
>>>> Decider for a Language/Set.
>>>>
>>>>>
>>>>> H correctly determines whether or not it can correctly determine the
>>>>> halting status for all of the members of the set of conventional
>>>>> halting
>>>>> problem proof counter-examples and an infinite set of other elements.
>>>>
>>>> But that isn't a proper property.
>>>>
>>>> You don't have "Decidability" on individual inputs, so it isn't a
>>>> Property of the input that can be decided on.
>>>
>>> H divides inputs into halting decidable and halting undecidable.
>>
>> Which means?
>>
>> After all, *ALL* inputs have a definite halting state, so there is a
>> correct answer to them, so there always exists a decider that will get
>> the right answer.
>>
>> It seems by your attempt at a definition, a "Decider" that just
>> decides all machines are non-ha;ting would have all halting machines
>> defined as undecidable.
>
> I never said anything like that.
> (Here is what I already said)
> H returns three values:

On 7/4/23 5:52 PM, olcott wrote:
> On 7/4/2023 8:27 AM, Richard Damon wrote:
>> On 7/4/23 12:57 AM, olcott wrote:
>>> On 7/3/2023 11:06 PM, Richard Damon wrote:
>>>> 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.
>>>>
>>>> Nope, just shows you are not working in a Turing Equivalent system,
>>>> and thus NOTHING you say matters.
>>>>
>>>
>>> You can make such claims with bluster finding a source that actually
>>> supports them is a whole different matter.
>>
>> No, you are just showing that you believe Russell's Teapot actually
>> exists. YOU are the one making claims, so YOU are the one that needs
>> to make a actual proof of correctness, and show the error in the
>> counter claims.
>>
>
> If you believe that I am incorrect you need much more than your own
> presumption as a basis for an actual rebuttal. You might not have
> much more than this mere presumption.